code-development

Code Development

When to Use

• Phase 7 of the full-stack workflow: after unit test design is complete.
• When the user requests implementing functionality according to tests or design documents.

Communicate with the user (required)

This phase is executed inthe main conversation, and when scope or solution trade-offs are involved during development, confirm with the user first.

Interaction Principles

• When user decisions are needed, present them asstructured optionsso the user can choose quickly.
• After completing each Batch, usestructured confirmationto ask about the next action.
• When encountering design conflicts or solution changes, explain the reasons first before letting the user choose.

Structured Confirmation Points

After each Batch is completed, confirm with the user:

• A. Continue to the next Batch
• B. Look at the current code first, continue later
• C. Have modification suggestions (please explain)

When encountering design conflicts, confirm with the user:

• A. Strictly follow the design document (even if there are doubts)
• B. Adjust according to the suggested alternative (list the alternatives)
• C. Pause, discuss first before deciding

When tests fail, confirm with the user:

• A. Fix the code to make the tests pass
• B. Adjust the test cases (if the expectations have changed)
• C. Skip this case and record it as a known issue

Input

Read from the current iteration directory:

• Program design document (program-design-{id}.md) — structure, flow, directory
• Task breakdown document (task-breakdown-{id}.md) — development order and batches
• Unit test case document (unit-testing-{id}.md) — cases and expectations

Execution Points

1. Follow task order: Follow the batches and dependency order of the task breakdown, implementing dependent layers first.
2. Test-driven: Each time a task is completed, run the corresponding test cases, and continue to the next task only after they pass.
3. Consistent style: Follow the project's chosen conventions (such as Java 21 syntax, ESLint rules, naming conventions).
4. Commit rhythm: After completing each Batch, it is recommended to commit once with a brief description.
5. Issue recording: During development, record any inconsistencies with the design document or adjustments needed in the output document.

Self-check Checklist

See templates/development-checklist.md。

Output

• Runnable code and tests that pass the cases.
• In docs/{current_iteration_id}/code-development-{code_development_id}.md record the implementation summary, deviation notes, and self-check results.

Documentation and Status

• Write output to docs/{current_iteration_id}/code-development-{code_development_id}.md。
• Before starting: call the history-manager skill's get-phase code_development and check-file to confirm whether it has already been completed.
• After completion: call the history-manager skill's set-phase code_development {code_development_id} to record and advance the status.