cs-feat

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

cs-feat

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

整套流程是这样的：

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

brainstorm 本身不在 feature 流程内部——它是讨论层的统一入口，会先分诊：你是 case 1（其实已经够清楚，直接进 design）、case 2（小需求方向定了，在 feature 里继续讨论并落

{slug}-brainstorm.md

）、还是 case 3（大需求装不进一个 feature，移交给

cs-roadmap

拆解）。只有 case 2 才会真的在

codestable/features/{feature}/

里产出 brainstorm note。

本技能本身不写代码、不写文档，只做一件事：看一下当前 feature 走到哪一步了，告诉用户该触发哪个子技能。

New feature development is the most complete workflow in CodeStable. When AI directly writes code upon receiving requirements, three recurring problems arise — inconsistent naming with the original code, scope creep during modification, and no archived records after changes. This workflow inserts a solution document between "requirements" and "code" to create a handoff point for both sides.

The entire workflow is as follows:

(Go to cs-brainstorm for triage when the idea is still vague) → Solution Design (including test design) → Phased Implementation → Acceptance Closure

Brainstorm is not part of the feature workflow itself — it is a unified entry point for the discussion layer, which first performs triage: whether you fall into case 1 (clear enough to directly enter design), case 2 (small requirement with a defined direction, continue discussion within the feature and produce

{slug}-brainstorm.md

), or case 3 (large requirement that cannot fit into a single feature, hand over to

cs-roadmap

for decomposition). Only case 2 will actually produce a brainstorm note in

codestable/features/{feature}/

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 流程的产物都聚在

codestable/features/

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

codestable/
└── features/
    └── {feature}/
        ├── {slug}-brainstorm.md       ← 阶段 0 的产物（可选，仅 brainstorm 判为 case 2 时才落盘）
        ├── {slug}-intent.md           ← 阶段 1 的可选前置草稿（用户自己写的半成品方案）
        ├── {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 的产物分别放在

codestable/features/

和

codestable/issues/

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

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

All artifacts of the entire feature workflow are gathered under

codestable/features/

, with an independent directory for each feature:

codestable/
└── features/
    └── {feature}/
        ├── {slug}-brainstorm.md       ← Artifact of Phase 0 (optional, only saved when brainstorm judges it as case 2)
        ├── {slug}-intent.md           ← Optional draft for Phase 1 (semi-finished solution written by the user)
        ├── {slug}-design.md           ← Solution document for Phase 1 (with YAML frontmatter + test design)
        ├── {slug}-checklist.yaml      ← Generated during Phase 1, updated in Phases 2/3
        └── {slug}-acceptance.md       ← Acceptance report for Phase 3

The directory is named

YYYY-MM-DD-{英文 slug}

The date is taken from the day of first creation and remains unchanged — even if the slug is modified later, the date prefix stays the same
The slug uses lowercase letters, numbers, and hyphens, and is short enough to clearly indicate what the feature is (such as
```
user-auth
```
,
```
export-csv
```
)

Why gather all artifacts in one directory? This way, when you later check "how we decided on 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 feature and issue artifacts are stored separately in

codestable/features/

and

codestable/issues/

— the archiving logic for the two types of issues is different, and mixing them will make it messy to find things later.

If you find a bug while implementing a feature, the correct approach is to record it as a new issue, do not secretly fix it in the feature's PR. Mixing changes will make it unclear "what exactly is the scope of this new addition" during acceptance, and later you won't be able to find why that line of code was modified.

四个阶段

Four Phases

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

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

阶段 0 是可选的，且是 feature 流程的外部入口——

cs-brainstorm

同时服务 feature 和 roadmap。只有想法明显模糊时才走；已经能清楚说出"做什么、为谁做、怎么算成功"时直接从阶段 1 开始。brainstorm 判为 case 3（大需求）时讨论会被移交给

cs-roadmap

，不再回到 feature 流程——等 roadmap 拆出子 feature 之后，每条子 feature 才会从

cs-feat-design

的"从 roadmap 条目起头"入口进来。

Phase	Sub-skill	Output	Lead
0 Brainstorm (optional, independent entry)	`cs-brainstorm`	Produces {slug}-brainstorm.md for case 2; no output for case 1 / 3	AI acts as a thinking partner, user makes the final call
1 Solution Design	`cs-feat-design`	{slug}-design.md + {slug}-checklist.yaml	AI drafts, user conducts overall review
2 Phased Implementation	`cs-feat-impl`	Code + phase reports	AI executes according to the solution
3 Acceptance Closure	`cs-feat-accept`	{slug}-acceptance.md	AI checks layer by layer, user makes the final approval

There are manual checkpoints between phases. Why set these? First, to give the user a clear gatekeeping opportunity at the end of each phase; second, to prevent AI from jumping directly from requirements to code, only for the user to discover deviations after implementation. Therefore, by default, the next phase should not start until the user explicitly approves the previous phase.

Phase 0 is optional and is an external entry point to the feature workflow —

cs-brainstorm

serves both feature and roadmap. Only use it when the idea is clearly vague; start directly from Phase 1 when you can clearly state "what to do, for whom, and how to define success". When brainstorm judges it as case 3 (large requirement), the discussion will be handed over to

cs-roadmap

and will not return to the feature workflow — after the roadmap breaks down into sub-features, each sub-feature will enter through the "start from roadmap item" entry of

cs-feat-design

Fastforward 模式

Fastforward Mode

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

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

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

cs-feat-ff

。

fastforward 的

{slug}-design.md

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

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

When requirements are clear and the scope is small, going through the full four phases can be tedious. In such cases, use fastforward:

User states requirements → AI writes a simplified {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

cs-feat-ff

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). The acceptance criteria must be written here without placeholders — because they will be directly extracted during the acceptance phase later.

When not to use fastforward: When the requirement spans multiple subsystems, has a risk of terminology conflicts, or has more than 4 implementation steps. In these cases, advise the user to follow the standard process. The reason is that as the scope expands, skipping the design phase means AI and the user have not jointly confirmed the same solution, which often leads to discrepancies in understanding after implementation.

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

Routing: Which Sub-skill Should the User Trigger Now

进入本技能后，先 Glob 一下

codestable/features/

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

当前状态	触发哪个子技能
想法模糊，说不清真问题 / 边界 / 不做什么	`cs-brainstorm` （判断方法见下）
想法清晰（知道做什么、为谁、怎么算成功）	`cs-feat-design`
用户说"开一个新需求 / 起个草稿 / 新建一个 feature"，想自己写半成品方案	`cs-feat-design` 的"初始化模式"（建目录 + 空 `{slug}-intent.md` ，让用户填完再回来）
用户主动说"先 brainstorm 一下"、"有个想法没想清楚"	`cs-brainstorm`
`{slug}-intent.md` 已存在且填好，用户说可以进设计了	`cs-feat-design` （读 intent 作输入）
用户说"快速模式"、"fastforward"等	`cs-feat-ff`
`{slug}-brainstorm.md` 已存在，用户说可以进设计了	`cs-feat-design`
`{slug}-design.md` 已 approved、代码还没动	`cs-feat-impl`
fastforward `{slug}-design.md` 已确认	`cs-feat-impl`
代码已写完，要做验收	`cs-feat-accept`
用户说的是"我想要一个 X 系统"这种大需求	转 `cs-brainstorm` 分诊（大概率判为 case 3 → `cs-roadmap` ）
roadmap 里某条子 feature 该启动了	`cs-feat-design` 的"从 roadmap 条目起头"入口
不确定 `{slug}-design.md` 是否完整	自己读一遍，按上面对号入座

After entering this skill, first Glob

codestable/features/

to check existing artifacts. Do not rely solely on the user's verbal description — the user saying "design is completed" does not necessarily mean it is truly complete; you must read it yourself to be sure.

Current Status	Trigger Which Sub-skill
Vague idea, unable to clearly state the real problem / boundaries / what not to do	`cs-brainstorm` (see below for judgment method)
Clear idea (knows what to do, for whom, and how to define success)	`cs-feat-design`
User says "initiate a new requirement / draft a sketch / create a new feature" and wants to write a semi-finished solution themselves	"Initialization mode" of `cs-feat-design` (create directory + empty `{slug}-intent.md` , let the user fill it in before returning)
User actively says "let's brainstorm first" / "have an unclear idea"	`cs-brainstorm`
`{slug}-intent.md` exists and is filled out, user says ready to enter design	`cs-feat-design` (read intent as input)
User says "fast mode", "fastforward", etc.	`cs-feat-ff`
`{slug}-brainstorm.md` exists, user says ready to enter design	`cs-feat-design`
`{slug}-design.md` is approved, code not yet started	`cs-feat-impl`
Fastforward `{slug}-design.md` is confirmed	`cs-feat-impl`
Code is completed, needs acceptance	`cs-feat-accept`
User says something like "I want an X system" (large requirement)	Transfer to `cs-brainstorm` for triage (most likely judged as case 3 → `cs-roadmap` )
A sub-feature in the roadmap is ready to start	"Start from roadmap item" entry of `cs-feat-design`
Unsure if `{slug}-design.md` is complete	Read it yourself and match to the above

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

How to Judge Whether the User Should Go Through Phase 0

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

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

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

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 the user
Is there a clear "what not to do"

If any of the three is vague, brainstorm is worthwhile. But do not force it — respect the user's judgment if they clearly say "I've thought it through, proceed directly to design". Ask the user to choose if unsure. It's better to miss a judgment (let the user enter design directly) than to make a wrong judgment (force a user who has thought it through to do what they consider unnecessary divergence).

brainstorm 和 intent 怎么选

How to Choose Between Brainstorm and Intent

两者都是 design 的前置，区别在谁在主导收敛：

brainstorm：用户脑子里还模糊，希望通过对话想清楚，AI 问用户答。注意：brainstorm 是独立入口，会先分诊；判为 case 3（大需求）时讨论会被移交给
```
cs-roadmap
```
，不会回到 feature 流程。只有 case 2（小需求）才产出
```
{slug}-brainstorm.md
```
intent：用户自己已经想好大致做法（比如一段 100 字的描述 + 相关数据结构），只是懒得口述，直接写成
```
{slug}-intent.md
```
给 AI 读

用户说"开一个新需求"这种模糊触发时，默认问一句"你想先聊清楚（brainstorm）还是自己写草稿（intent）？"，别自己挑一个推进。

Both are prerequisites for design, and the difference lies in who leads the convergence:

Brainstorm: The user's idea is still vague, hoping to clarify through dialogue, with AI asking questions and the user answering. Note: Brainstorm is an independent entry point that first performs triage; when judged as case 3 (large requirement), the discussion will be handed over to
```
cs-roadmap
```
and will not return to the feature workflow. Only case 2 (small requirement) produces
```
{slug}-brainstorm.md
```
Intent: The user has already thought out the general approach (such as a 100-word description + related data structures), but is too lazy to dictate it, so writes it directly into
```
{slug}-intent.md
```
for AI to read

When the user triggers with vague phrases like "initiate a new requirement", default to asking "Do you want to clarify through discussion (brainstorm) or write a draft yourself (intent)?", do not choose one to proceed on your own.

与 issue 工作流的边界

Boundary with Issue Workflow

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

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

Feature handles "adding something that never existed" — new functions, new capabilities
Issue handles "something that should work but is broken" — bugs, exceptions, documentation errors

The gray area has been mentioned earlier: bugs found during feature implementation should be recorded as new issues, not fixed in the feature PR.

cs-feat

Original

Translation

cs-feat

cs-feat

文件放哪儿

Where to Store Files

四个阶段

Four Phases

Fastforward 模式

Fastforward Mode

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

Routing: Which Sub-skill Should the User Trigger Now

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

How to Judge Whether the User Should Go Through Phase 0

brainstorm 和 intent 怎么选

How to Choose Between Brainstorm and Intent

与 issue 工作流的边界

Boundary with Issue Workflow

相关文档

Related Documents