dev-workflow

Full-stack development workflow

The user starts via /dev-workflow . Optionally pass iteration-id to resume an existing iteration.

Startup process

1. Call the history-manager skill to execute init(ensure that docs/history.json exists).
2. If $ARGUMENTS is passed and is a valid iteration id, resume that iteration; otherwise call history-manager to execute new-iter to create a new iteration.
3. Call history-manager to execute status to read the current iteration's state, and continue execution from that phase.

Phase execution order

Order	Phase	Skill	Execution method	Description
1	Requirements analysis	requirements-analysis	inline	Converse with the user to sort out functional points
2	Technology selection	technology-selection	inline	Ask full-stack/frontend/backend, select the technology stack
3	Technical review	technical-review	fork/Explore	Review architecture feasibility, API contracts, and risk items
4	Program design	program-design	inline	Design module layering, flow, and project directory
5	Task breakdown	task-breakdown	fork/Plan	Break the design into manageable development units
6	Unit testing	unit-testing	fork	Design test cases by task unit
7	Code development	code-development	inline	Implement code in a test-driven manner
8	Self-verification	self-verification	fork/Explore	Run tests, integration verification, and quality self-check

Execution rules

• Inline phases must involve dialogue with the user: requirements analysis, technology selection, program design, and code development (phases 1, 2, 4, and 7) are all executed in the main conversation. All decision pointsare presented as structured options(numbered options, letting the user choose rather than freely input),wait for the user's choice before producing/advancing, and do not skip the user to directly generate results. No more than 3 questions per round.
• State recovery: before each phase begins, call history-manager 's get-phase and check-file to check whether that phase has already been completed. If it has been completed, skip it and proceed directly to the next phase.
• State writing: after each phase is completed, call history-manager 's set-phase <phase> <phase_id> to update history.
• Phase id generation: use the {阶段缩写}-001 format (e.g., req-001、ts-001). Increment within the same iteration.
• Self-verification failure: if the self-verification report has failed items, roll back to code-development to fix them and then re-verify.
• Output location: all phase documents are written to docs/{current_iteration_id}/。