lightweight-ai-workflow

Lightweight AI Workflow

Applicable scenarios

The user requests formulating, executing, or checking an AI coding workflow
Before requirements begin, it is necessary to determine whether to use the lightweight workflow, OpenSpec, or multi-Agent
Before code implementation, impact analysis is needed
After code implementation, a minimal verification conclusion and remaining risks need to be provided

It is already clear that this is an ordinary implementation of a certain business module; prioritize reading that module's skill
There is already openspec/changes/<change>/, prioritize compliance with openspec-first
The user only asks about concepts, code explanations, or questions that do not involve the delivery workflow

First follow skill-context-first to identify the main module; by default only read 1 module main skills.
For single-module, low-risk tasks with clear boundaries, you may choose direct implementation based on complexity, or first enter Plan Mode to sort out the solution; do not directly escalate to OpenSpec or multi-Agent.
For multi-module tasks, tasks with unclear impact, or tasks prone to missing linkage points, first complete the impact checklist, then decide whether to implement.
When OpenSpec trigger conditions are met, supplement the documentation first, then modify the code.
Only escalate to multi-Agent when the requirements are large, the scope is vague, or there is cross-end or continuous rework.
After implementation is complete, output a verification checklist, explaining verified items, unverified items, and remaining risks.

Lightweight workflow: single module, small scope, low risk, clear acceptance; after reading the target module skill, you may choose direct implementation based on complexity, or first enter Plan Mode to sort out the scope, impact surface, and solution.
Impact surface first: cross-module, unclear call chain, configuration/permissions/data/i18n may be affected; first write the impact checklist.
OpenSpec: Add or modify APIs, data structures, database scripts, stable external contracts; span more than 2 microservices or core modules; involve permissions, compatibility, migration, canary release, rollback; or unclear acceptance criteria.
Multi-Agent: The requirement scope is large and module ownership is unclear; phased handoff is needed across requirements, solution, implementation, and quality gates; a single Agent still cannot converge after two consecutive rounds; or the user explicitly requests multi-Agent collaboration.

Which module skill does this mainly fall under? Is it necessary to additionally read 1 cross-cutting skills?
Which layers are affected: Resource, Service, DAO, Model, configuration, scripts, frontend, Worker, Agent?
Does it affect APIs, data contracts, databases, permissions, i18n, events, caches, or scheduled tasks?
Are there callers, callees, historical compatibility, canary release, or rollback requirements?
Is OpenSpec or multi-Agent escalation needed?

Are all requirement points covered item by item this time?
Have the affected modules run at least one of compilation, unit tests, lint, or key scripts?
What verification was not run, and why?
Are there any new warnings, failures, or rule violations?
Are there still unverified risks, legacy issues, or points requiring manual confirmation?

The lightweight entry point is only responsible for triage and checklists, and does not carry module knowledge.
Do not expand the workflow "just to be safe"; for small tasks, prioritize spending tokens on code and verification.
When discovering duplicate missed changes or process misjudgments, first record them in ai/evals/, and after confirming stability, adjust the rule or skill.