القائمة
SDD step 4. Read plan.md and implement the feature step by step, then verify all acceptance criteria are met. Use after /sdd-plan has produced plan.md.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | sdd-implement |
| description | SDD step 4. Read plan.md and implement the feature step by step, then verify all acceptance criteria are met. Use after /sdd-plan has produced plan.md. |
You are a senior software engineer executing the implementation plan precisely.
Verify these files exist:
plan.md — the implementation planfeature.md — the feature spec (for acceptance criteria)docs/project.md — project contextRead plan.md, feature.md, and docs/project.md before writing a single line of code.
Work through each step in plan.md sequentially. For each step:
docs/project.md strictlyplan.md by changing - [ ] to - [x] on that step's line (or prepending ✅ if the plan does not use checkboxes)After completing each step, run the relevant build/test command from docs/project.md:
Once all steps are complete, go through every acceptance criterion in feature.md:
feature.mdWrite a file named impl-summary.md in the project root with the following content:
## Implementation Complete
### Files Created
- ...
### Files Modified
- ...
### Acceptance Criteria
- [x] AC-01: Passed — `FooServiceTest#test_something`
- [x] AC-02: Passed — `FooControllerTest#test_endpoint`
### Notes
Any deviations from the plan and why.
Keep each entry a single concise bullet — this file is a quick reference, not prose.
After writing the file, tell the user: "impl-summary.md created." Then prompt them to run /sdd-review before archiving.
SDD step 1. Analyse a feature request and produce a detailed feature.md spec. Use when the user describes a new feature they want to build. Asks for missing details before writing the spec.
SDD step 0. Analyse the project codebase and create docs/project.md with tech stack, architecture, and conventions. Run once before starting SDD in a new project. If docs/project.md already exists, asks whether to regenerate it.
SDD step 3. Read feature.md and produce a detailed implementation plan.md tailored to the project's tech stack and architecture. Use after /sdd-feature has produced feature.md.
SDD step 2 (optional, repeatable). Read an existing feature.md and refine it by updating or enhancing requirements based on user input. Use when requirements have changed, new edge cases are discovered, or the spec needs clarification before planning or re-planning. Run before /sdd-plan if plan.md already exists.
SDD fast path. Runs the full pipeline — analyse → plan → implement → review → archive — with a single confirmation gate before implementation begins. Stops automatically if Critical or Major issues are found in review. Use when you want to ship a well-understood feature with minimal interruptions.
SDD step 7. Archive feature.md and plan.md into docs/specs-archive/<yyyymmddHHMM>-<feature-name>/ directory, then update docs/project.md with the new feature, and any architecture decisions made. Use after /sdd-review is complete and the feature is ready to merge.