add-feat

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Add Feature Workflow

添加功能工作流

Follow this exact sequence. Do NOT skip steps.

请严格遵循以下步骤序列，不要跳过任何步骤。

1. Sync main

1. 同步主分支

git checkout main && git pull

git checkout main && git pull

2. Requirements Discovery (questionnaire)

2. 需求调研（问卷）

Before designing, understand what the user actually needs. Ask questions one at a time — wait for the answer before asking the next.

Q1: Intent — "What problem does this feature solve? Who needs it and why?"

Push if vague: "Can you describe a concrete scenario where someone would use this?"

Q2: Scope — "What's the smallest version of this that would be useful?"

Present options if applicable: A) minimal, B) standard, C) full
Recommend one with a brief reason

Q3: Existing patterns — Review the codebase for related code, then ask: "I found [related code/patterns]. Should this feature follow the same approach, or is there a reason to diverge?"

Q4: Edge cases & conflicts — Based on Q1-Q3, identify potential issues: "I see these potential concerns: [list]. Which matter? Any others I'm missing?"

Q5: Success criteria — "How will we know this works? What should the tests verify?"

Skip rule: If the user says "skip" or the feature is trivially simple (< 20 lines of change), jump to step 3. But always ask Q1 at minimum.

After the questionnaire, summarize what you understood and get explicit confirmation before proceeding.

在进行设计之前，先明确用户的实际需求。一次只问一个问题——得到答案后再问下一个。

问题1：意图 —— "这个功能解决什么问题？谁需要它，为什么？"

如果描述模糊，进一步追问："你能描述一个人们会使用这个功能的具体场景吗？"

问题2：范围 —— "这个功能最简化的可用版本是什么样的？"

如有必要，提供选项：A) 极简版，B) 标准版，C) 完整版
推荐一个版本并给出简短理由

问题3：现有模式 —— 查看代码库中的相关代码，然后询问： "我发现了[相关代码/模式]。这个功能应该遵循同样的方法，还是有理由采用不同的方式？"

问题4：边缘情况与冲突 —— 根据问题1-3，识别潜在问题： "我注意到这些潜在问题：[列表]。哪些是需要关注的？还有其他我没考虑到的吗？"

问题5：成功标准 —— "我们如何判断这个功能有效？测试需要验证哪些内容？"

跳过规则： 如果用户说“跳过”，或者功能非常简单（修改量少于20行），则直接跳到步骤3。但至少要询问问题1。

完成问卷后，总结你的理解并获得用户明确确认，再继续下一步。

3. Design

3. 设计

Based on the requirements discovery, explore the design space: options, tradeoffs, edge cases
Present design to the user for approval before writing any code

根据需求调研结果，探索设计空间：选项、权衡、边缘情况
在编写任何代码之前，将设计方案提交给用户审批

4. Create worktree and branch

4. 创建工作树和分支

git worktree add .claude/worktrees/feat-<name> -b feat/<feature-name>
cd .claude/worktrees/feat-<name>

All work happens in the worktree — main stays clean.

git worktree add .claude/worktrees/feat-<name> -b feat/<feature-name>
cd .claude/worktrees/feat-<name>

所有工作都在工作树中进行——主分支保持干净。

5. TDD Implementation

5. TDD实现

Write tests FIRST, then implement
For each unit of work:
1. Write a failing test
2. Implement the minimum code to pass
3. Refactor if needed
Run the full test suite after each change

先编写测试，再实现功能
对于每个工作单元：
1. 编写一个会失败的测试
2. 编写最少的代码使测试通过
3. 如有需要进行重构
每次修改后运行完整测试套件

6. Verify

6. 验证

Run full test suite
Verify compilation / import checks where applicable
Check no silent excepts, no debug prints left behind

运行完整测试套件
验证编译/导入检查（如适用）
检查是否有无声异常、残留的调试打印语句

7. Code Review

7. 代码审查

Self-review via
```
git diff main...HEAD
```
Or dispatch a code-review subagent if available
Fix all issues found before proceeding

通过
```
git diff main...HEAD
```
进行自我审查
如有可用，可调用代码审查子Agent
在继续下一步之前修复所有发现的问题

8. Create PR

8. 创建PR

Commit with descriptive message
Push branch and create PR via
```
gh pr create
```
Wait for CI/CD checks to complete:
```
gh pr checks <number> --watch
```
If checks fail, fix the issues and push again — do not notify the user until all checks are green
Once all checks pass, return the PR URL and ask the user to review
DO NOT merge — wait for explicit approval

提交带有描述性信息的commit
推送分支并通过
```
gh pr create
```
创建PR
等待CI/CD检查完成：
```
gh pr checks <number> --watch
```
如果检查失败，修复问题后重新推送——直到所有检查通过再通知用户
所有检查通过后，返回PR链接并请用户审核
不要合并——等待用户明确批准

9. Merge (only when approved)

9. 合并（仅在获批后）

```
gh pr merge <number> --merge
```

Clean up worktree:

cd <project-root> && git worktree remove .claude/worktrees/feat-<name>

git checkout main && git pull && git branch -d feat/<feature-name>

```
gh pr merge <number> --merge
```

清理工作树：

cd <project-root> && git worktree remove .claude/worktrees/feat-<name>

git checkout main && git pull && git branch -d feat/<feature-name>

Rules

规则

Never merge without explicit approval
Never push directly to main
Always TDD — tests before implementation
Always run full test suite before committing
No dead code, no silent excepts, no string literals for constants
No duplicate systems — same data via two paths is a critical defect

未经明确批准绝不要合并
绝不要直接推送到主分支
始终采用TDD——先测试后实现
提交前始终运行完整测试套件
不要有死代码、无声异常、用字符串字面量代替常量
不要有重复系统——同一数据通过两条路径传递是严重缺陷

Quality Checklist

质量检查表

Before every PR, answer each item and present as a markdown table:

#	Check	Answer
1	What changed — what was built and how	[brief]
2	Systematic design — is the design systematic, or patch-by-patch?	[yes/no + evidence]
3	Single source of truth — no duplicate data paths or redundant caches introduced?	[yes/no + evidence]
4	Test regression — do all existing tests pass?	[pass count / fail count]
5	Reuse — did you reuse existing patterns/functions, or reinvent something?	[yes/no + evidence]

If any answer is unsatisfactory, fix it before creating the PR
Be honest — don't beautify answers

在创建每个PR之前，回答以下每个问题并以Markdown表格形式呈现：

#	检查项	回答
1	变更内容 —— 开发了什么以及如何实现	[简要说明]
2	系统化设计 —— 设计是系统化的，还是零散拼凑的？	[是/否 + 依据]
3	单一数据源 —— 未引入重复的数据路径或冗余缓存？	[是/否 + 依据]
4	测试回归 —— 所有现有测试是否通过？	[通过数量 / 失败数量]
5	复用性 —— 是否复用了现有模式/函数，还是重新开发了新的？	[是/否 + 依据]

如果任何回答不达标，在创建PR之前修复问题
请诚实作答——不要美化答案