easysdd-feature

easysdd-feature

New feature development is the most complete process in easysdd. When the AI gets a requirement and directly writes code, three old problems keep recurring—names don't match the original code, changes drift out of scope as you go, and after the changes are done no archive is left. This process inserts a design document between the "requirement" and the "code", giving both sides a handoff point.

The whole process goes like this:

(想法还模糊时先 brainstorm) → 方案设计（含测试设计）→ 分步实现 → 验收闭环

This skill itself does not write code or documents; it does only one thing: look at what step the current feature has reached and tell the user which sub-skill to trigger.

Where the files go

The artifacts of the entire feature process are all gathered under easysdd/features/ , with one independent directory per feature:

easysdd/
└── features/
    └── {feature}/
        ├── {slug}-brainstorm.md       ← 阶段 0 的产物（可选，AI 引导对话沉淀）
        ├── {slug}-intent.md           ← 阶段 1 的可选前置草稿（用户自己写的半成品方案）
        ├── {slug}-design.md           ← 阶段 1 的方案文件（带 YAML frontmatter + 测试设计）
        ├── {slug}-checklist.yaml      ← 阶段 1 顺手生成，2/3 阶段更新
        └── {slug}-acceptance.md       ← 阶段 3 的验收报告

Directory naming is YYYY-MM-DD-{英文 slug}：

The date isthe day it was first created, and once set it does not change—if the slug is changed later, the date prefix also stays as it was
The slug uses lowercase letters, numbers, and hyphens, and is short enough to see at a glance what is being done (user-auth、export-csv like this)

Why are all artifacts gathered in one directory? This way, when later looking back at "how was that CSV export feature decided last time?", the brainstorm, design, and acceptance are all in one place, with no need to search all over. This is also why feature and issue artifacts are placed respectively in easysdd/features/ and easysdd/issues/—the archiving logic for the two types of problems is different, and mixing them together will make things messy to find later.

If while implementing a feature you happen to discover a bug, the correct approach is to record it as a new issue,do not secretly fix it in the feature's PR. Mixing in changes will make it impossible at acceptance time to tell "exactly what the scope of this addition is", and when looking back later you also won't find why that line of code was changed.

Four stages

Stage	Sub-skill	Output	Who leads
0 brainstorm (optional)	`easysdd-feature-brainstorm`	{slug}-brainstorm.md	AI acts as thinking partner, user makes the call
1 Design	`easysdd-feature-design`	{slug}-design.md + {slug}-checklist.yaml	AI drafts, user reviews as a whole
2 Step-by-step implementation	`easysdd-feature-implement`	Code + stage report	AI executes according to the design
3 Acceptance closed loop	`easysdd-feature-acceptance`	{slug}-acceptance.md	AI checks layer by layer, user gives final approval

There are human checkpoints between stages. Why block it this way? First, to give the user a clear chance to check at the end of each stage; second, to prevent the AI from running all the way from requirement to code in one breath and the user only discovering it went off track after it has already run. So by default, if the previous stage has not received explicit user approval, the next stage should not start.

Stage 0 is optional—it is only used when the idea is obviously vague. If the user can already clearly state "what to do, for whom, and how success is measured", starting directly from stage 1 is more efficient.

Fastforward mode

When the requirement is already very clear and the scope is small, going through the full four stages feels verbose. In this case there is fastforward:

用户说需求 → AI 写一份精简 {slug}-design.md（包含验收标准）→ 用户一次确认 → 直接实现

Trigger: the user says things like "quick mode", "fastforward", "just start doing it", "skip all those steps" — go to easysdd-feature-fastforward。

fastforward's {slug}-design.md shares the same feature directory as the standard process, and the frontmatter is also the same; only the body is compressed into 4 sections (requirements summary + design plan + acceptance criteria + steps forward). Acceptance criteria must be written here, with no placeholders left — because the later acceptance stage will extract directly from here.

When tonotuse fastforward: spanning multiple subsystems, risk of terminology conflicts, or more than 4 steps forward. In these cases, persuade the user to use the standard process, because once the scope is large, skipping the design stage means the AI and the user have not jointly confirmed the same plan, and after implementation it is easy to find that what each understood was not the same thing.

Routing: which sub-skill the user should use now

After entering this skill, first Glob easysdd/features/ to see what artifacts already exist.Do not just rely on the user's verbal description— the user saying "the design is finished" does not necessarily mean it is really complete; read it yourself to know.

Current state	Which sub-skill is triggered
The idea is vague; cannot clearly state the real problem / boundaries / what not to do	Ask whether to do brainstorm first (judgment method see below)
The idea is clear (know what to do, for whom, and how success is measured)	`easysdd-feature-design`
The user says "start a new requirement / make a draft / create a new feature" and wants to write a half-finished plan themselves	`easysdd-feature-design` 's "initialization mode" (create directory + empty `{slug}-intent.md`, let the user fill it in and come back)
The user proactively says "brainstorm first"	`easysdd-feature-brainstorm`
`{slug}-intent.md` already exists and is filled in, and the user says it can move to design	`easysdd-feature-design`(read intent as input)
The user says "quick mode", "fastforward", etc.	`easysdd-feature-fastforward`
`{slug}-brainstorm.md` already exists, and the user says it can move to design	`easysdd-feature-design`
`{slug}-design.md` is already approved, and the code has not been touched yet	`easysdd-feature-implement`
fastforward `{slug}-design.md` already confirmed	`easysdd-feature-implement`
The code has been written and acceptance is needed	`easysdd-feature-acceptance`
Not sure whether `{slug}-design.md` is complete	Read it yourself and match it to the above

How to judge whether 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 the real problem to solve is
What the core behavior perceived by the user is
Whether there is a clear "what not to do"

If any one of the three is vague, brainstorm is worth doing. But do not force it — if the user clearly says "I have thought it through, go straight to design", respect their judgment. When unsure, ask and let the user choose. Better to miss a judgment (let the user go straight to design) than to misjudge (force a user who has thought it through to do divergence they consider unnecessary).

How to choose between brainstorm and intent

Both are prerequisites for design; the difference iswho is leading the convergence：

brainstorm: the user's mind is still vague and they want to clarify through dialogue; the AI asks and the user answers; the output is the {slug}-brainstorm.md
intent: the user has already thought out the general approach themselves (for example, a 100-word description + related data structures), but is too lazy to dictate it, so they directly write {slug}-intent.md for the AI to read

When the user says something vague like "start a new requirement," by default ask "Do you want to talk it through first (brainstorm) or write a draft yourself (intent)?" Don't pick one yourself and push it forward.

Boundary with the issue workflow

A feature handles "something that never existed needs to be added" — new functionality, new capabilities
An issue handles "something that should have worked is broken" — bugs, anomalies, documentation errors

The gray area was covered earlier: a bug discovered while implementing a feature is recorded as a new issue, not fixed on the side in the feature PR.

About this skill