easysdd-feature

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

easysdd-feature

新功能开发是 easysdd 里走得最完整的一条流程。AI 直接拿到需求就写代码，三个老问题会反复出现——名字跟原代码对不上、改着改着改出范围、改完不留存档。这条流程在"需求"和"代码"之间塞了一份方案文件，让两边都有个交接点。

整套流程是这样的：

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

本技能本身不写代码、不写文档，只做一件事：看一下当前 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

整套 feature 流程的产物都聚在

easysdd/features/

下，每个 feature 一个独立目录：

easysdd/
└── features/
    └── {feature}/
        ├── {slug}-brainstorm.md       ← 阶段 0 的产物（可选）
        ├── {slug}-design.md           ← 阶段 1 的方案文件（带 YAML frontmatter + 测试设计）
        ├── {slug}-checklist.yaml      ← 阶段 1 顺手生成，2/3 阶段更新
        └── {slug}-acceptance.md       ← 阶段 3 的验收报告

目录命名是

YYYY-MM-DD-{英文 slug}

：

日期取首次创建当天，定了就不动——后续 slug 改了，日期前缀也保持原样
slug 用小写字母、数字、连字符，简短能一眼看出做的是什么（
```
user-auth
```
、
```
export-csv
```
这种）

为什么所有产物聚在一个目录？这样以后回头查"上次那个导出 CSV 的功能当时怎么决定的"，brainstorm、design、acceptance 都在一处，不用东找西找。这也是为什么 feature 和 issue 的产物分别放在

easysdd/features/

和

easysdd/issues/

——两类问题的归档逻辑不一样，混在一起后面找东西会乱。

如果实现 feature 时顺手发现了一个 bug，正确做法是把它记成新的 issue，不要在 feature 的 PR 里偷偷修。混着改会让验收时分不清"这次新增的范围到底是哪些"，后面回头看也找不到为什么改了那行代码。

All artifacts of the entire feature workflow are gathered under

easysdd/features/

, 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
```
user-auth
```
,
```
export-csv
```
)

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

easysdd/features/

and

easysdd/issues/

— 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

阶段	子技能	产出	谁主导
0 brainstorm（可选）	`easysdd-feature-brainstorm`	{slug}-brainstorm.md	AI 做思考伙伴，用户拍板
1 方案设计	`easysdd-feature-design`	{slug}-design.md + {slug}-checklist.yaml	AI 起草，用户整体 review
2 分步实现	`easysdd-feature-implement`	代码 + 阶段汇报	AI 按方案执行
3 验收闭环	`easysdd-feature-acceptance`	{slug}-acceptance.md	AI 逐层核对，用户终审

阶段之间有人工 checkpoint。为什么要这样卡？一是让用户在每个阶段结束时有一次明确的把关机会，二是防止 AI 一口气从需求跑到代码、跑出来用户才发现走偏了。所以默认情况下，上一个阶段没拿到用户明确放行，下一个阶段就别开始。

阶段 0 是可选的——只有想法明显模糊时才走。如果用户已经能清楚说出"做什么、为谁做、怎么算成功"，直接从阶段 1 开始更省事。

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	`easysdd-feature-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 模式

Fastforward Mode

需求已经很清楚、范围又小的时候，走完整四阶段会嫌啰嗦。这时候有 fastforward：

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

触发：用户说"快速模式"、"fastforward"、"直接开干"、"别那么多步骤"这一类，去

easysdd-feature-fastforward

。

fastforward 的

{slug}-design.md

跟标准流程共用同一个 feature 目录，frontmatter 也一致，只是正文压成 4 节（需求摘要 + 设计方案 + 验收标准 + 推进步骤）。验收标准在这里就要写好，不留占位——因为后面 acceptance 阶段会直接从这里抽。

什么时候别走 fastforward：跨多个子系统、有术语冲突风险、推进步骤超过 4 步。遇到这几种情况就劝用户走标准流程，原因是范围一大，跳过 design 阶段意味着 AI 和用户在同一份方案上没共同确认过，实现完很容易发现彼此理解的不是同一回事。

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

{slug}-design.md

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

进入本技能后，先 Glob 一下

easysdd/features/

看已经有哪些产物。不要只听用户口头描述——用户说"设计写完了"不一定真完整，自己读一遍才有数。

当前状态	触发哪个子技能
想法模糊，说不清真问题 / 边界 / 不做什么	问一下要不要先走 brainstorm（判断方法见下）
想法清晰（知道做什么、为谁、怎么算成功）	`easysdd-feature-design`
用户主动说"先 brainstorm 一下"	`easysdd-feature-brainstorm`
用户说"快速模式"、"fastforward"等	`easysdd-feature-fastforward`
`{slug}-brainstorm.md` 已存在，用户说可以进设计了	`easysdd-feature-design`
`{slug}-design.md` 已 approved、代码还没动	`easysdd-feature-implement`
fastforward `{slug}-design.md` 已确认	`easysdd-feature-implement`
代码已写完，要做验收	`easysdd-feature-acceptance`
不确定 `{slug}-design.md` 是否完整	自己读一遍，按上面对号入座

After entering this skill, first Glob the

easysdd/features/

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)	`easysdd-feature-design`
User actively says "let's brainstorm first"	`easysdd-feature-brainstorm`
User says "fast mode", "fastforward", etc.	`easysdd-feature-fastforward`
`{slug}-brainstorm.md` exists and the user says they can proceed to design	`easysdd-feature-design`
`{slug}-design.md` is approved and no code has been written yet	`easysdd-feature-implement`
Fastforward `{slug}-design.md` is confirmed	`easysdd-feature-implement`
Code is written and acceptance is needed	`easysdd-feature-acceptance`
Unsure if `{slug}-design.md` is complete	Read it yourself and match it to the above criteria

怎么判断用户该不该走阶段 0

How to Judge if the User Should Go Through Stage 0

判断信号不是"用户描述的字数少"，而是用户能不能清楚说出这三件事：

要解决的真问题是什么
用户感知的核心行为是什么
有没有一条明确的"不做什么"

三项有一项模糊，brainstorm 就值得走。但别强推——如果用户明确说"我想清楚了，直接做设计"，就尊重他的判断。不确定的时候问一句让用户选。宁可漏判（让用户直接进设计），也别误判（逼一个想清楚的用户做他觉得多余的发散）。

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).

与 issue 工作流的边界

Boundary with Issue Workflow

feature 处理"从来没有的东西要加进来"——新功能、新能力
issue 处理"本来应该好的东西坏了"——bug、异常、文档错误

灰色地带在前面已经讲过：feature 实现时发现的 bug 记成新 issue，不在 feature PR 里顺手修。

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.

easysdd-feature

Original

Translation

easysdd-feature

easysdd-feature

文件放哪儿

Where to Store Files

四个阶段

Four Stages

Fastforward 模式

Fastforward Mode

路由：用户现在该走哪个子技能

Routing: Which Sub-skill Should the User Trigger Now

怎么判断用户该不该走阶段 0

How to Judge if the User Should Go Through Stage 0

与 issue 工作流的边界

Boundary with Issue Workflow

相关文档

Related Documents