easysdd-feature
New feature development is the most complete workflow in easysdd. When AI directly writes code upon receiving requirements, three old problems repeatedly arise — inconsistent naming with the original code, scope creep during modification, and no archiving after changes. This workflow inserts a solution file between "requirements" and "code" to create a handoff point for both sides.
The entire workflow is as follows:
(Start with brainstorm when the idea is still vague) → Solution Design (including test design) → Phased Implementation → Closed-loop Acceptance
This skill itself does not write code or documents; it only does one thing: check which stage the current feature has reached and tell the user which sub-skill to trigger next.
Where to Store Files
All artifacts of the entire feature workflow are gathered under
, with an independent directory for each feature:
easysdd/
└── features/
└── {feature}/
├── {slug}-brainstorm.md ← Artifact of Stage 0 (optional)
├── {slug}-design.md ← Solution file for Stage 1 (with YAML frontmatter + test design)
├── {slug}-checklist.yaml ← Generated in Stage 1, updated in Stages 2/3
└── {slug}-acceptance.md ← Acceptance report for Stage 3
Directory naming follows the format
YYYY-MM-DD-{English slug}
:
- The date is taken from the first creation day and remains unchanged afterward — even if the slug is modified later, the date prefix stays the same
- Slugs use lowercase letters, numbers, and hyphens, and are short enough to clearly indicate what the feature does (such as , )
Why gather all artifacts in one directory? This way, when looking back later to check "how the decision was made for that CSV export feature last time", the brainstorm, design, and acceptance documents are all in one place, eliminating the need to search around. This is also why artifacts for features and issues are stored separately in
and
— the archiving logic for the two types of issues is different, and mixing them will make it messy to find things later.
If a bug is found while implementing a feature, the correct approach is to log it as a new issue, do not secretly fix it in the feature's PR. Mixing changes will make it unclear "what the scope of this new addition is exactly" during acceptance, and later it will be impossible to find out why that line of code was modified.
Four Stages
| Stage | Sub-skill | Output | Lead |
|---|
| 0 brainstorm (optional) | easysdd-feature-brainstorm
| {slug}-brainstorm.md | AI as a thinking partner, user makes final decisions |
| 1 Solution Design | | {slug}-design.md + {slug}-checklist.yaml | AI drafts, user conducts overall review |
| 2 Phased Implementation | easysdd-feature-implement
| Code + phase reports | AI executes according to the solution |
| 3 Closed-loop Acceptance | easysdd-feature-acceptance
| {slug}-acceptance.md | AI checks layer by layer, user makes final approval |
There are manual checkpoints between stages. Why is this necessary? First, it gives the user a clear opportunity to review at the end of each stage; second, it prevents AI from going straight from requirements to code, only for the user to find out it has deviated after completion. Therefore, by default, the next stage should not start until the user explicitly approves the previous stage.
Stage 0 is optional — only go through it when the idea is clearly vague. If the user can already clearly state "what to do, who it's for, and what counts as success", starting directly from Stage 1 is more efficient.
Fastforward Mode
When requirements are already clear and the scope is small, going through the full four stages can be cumbersome. In such cases, use fastforward:
User states requirements → AI writes a streamlined {slug}-design.md (including acceptance criteria) → User confirms once → Direct implementation
Trigger: When the user says phrases like "fast mode", "fastforward", "start directly", "skip the steps", trigger
easysdd-feature-fastforward
.
The
for fastforward shares the same feature directory as the standard workflow, and the frontmatter is consistent, but the body is compressed into 4 sections (requirement summary + design solution + acceptance criteria + implementation steps). Acceptance criteria must be fully written here, with no placeholders — because the acceptance stage will directly extract them from here.
When not to use fastforward: when involving multiple subsystems, there is a risk of terminology conflicts, or the implementation steps exceed 4. In these cases, advise the user to follow the standard workflow. The reason is that when the scope is large, skipping the design stage means AI and the user have not jointly confirmed the same solution, and it is easy to find that they had different understandings after implementation.
Routing: Which Sub-skill Should the User Trigger Now
After entering this skill, first Glob the
directory to see which artifacts already exist.
Do not rely solely on the user's verbal description — the user saying "the design is done" does not necessarily mean it is complete; you must read it yourself to be sure.
| Current Status | Which Sub-skill to Trigger |
|---|
| Vague idea, unable to clearly state the real problem / boundaries / what not to do | Ask the user if they want to start with brainstorm (see below for judgment criteria) |
| Clear idea (knows what to do, who it's for, what counts as success) | |
| User actively says "let's brainstorm first" | easysdd-feature-brainstorm
|
| User says "fast mode", "fastforward", etc. | easysdd-feature-fastforward
|
| exists and the user says they can proceed to design | |
| is approved and no code has been written yet | easysdd-feature-implement
|
| Fastforward is confirmed | easysdd-feature-implement
|
| Code is written and acceptance is needed | easysdd-feature-acceptance
|
| Unsure if is complete | Read it yourself and match it to the above criteria |
How to Judge if the User Should Go Through Stage 0
The judgment signal is not "the user's description is short", but whether the user can clearly state these three things:
- What is the real problem to solve
- What is the core behavior perceived by users
- Is there a clear "what not to do"
If any of the three is vague, brainstorm is worthwhile. But do not force it — if the user clearly says "I've thought it through, proceed directly to design", respect their judgment. Ask the user to choose if you are unsure. It is better to miss a judgment (let the user proceed directly to design) than to make a wrong judgment (force a user who has thought it through to do what they consider unnecessary divergence).
Boundary with Issue Workflow
- Features handle "adding something that never existed before" — new functions, new capabilities
- Issues handle "something that should work but is broken" — bugs, exceptions, documentation errors
The gray area has already been mentioned: bugs found during feature implementation should be logged as new issues, not fixed in the feature PR.
Related Documents
- — Root skill of the easysdd family, scenario routing is located there
easysdd/reference/shared-conventions.md
- — Code specifications for the entire project, which also apply to feature implementation
- Project architecture entry point — Needed during the solution design stage