feature-dev-workflow

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Feature Development Workflow

功能开发工作流

Overview

概述

A structured development cycle that ensures every code change goes through planning, validation, implementation, and verification before being committed. Prevents wasted effort by getting alignment early and catching issues before they reach the codebase.

这是一个结构化的开发周期，确保所有代码变更在提交前都经过规划、验证、实现和确认环节。通过尽早达成共识并在问题进入代码库前发现它们，避免无效工作。

When to Use

适用场景

Adding a new feature or module
Fixing a non-trivial bug
Refactoring existing code
Any change touching more than 2-3 files
Any change where the approach isn't immediately obvious

When NOT to use: Single-line fixes, typo corrections, trivial changes with obvious implementation.

添加新功能或模块
修复非简单Bug
重构现有代码
涉及2-3个以上文件的变更
实现方案不明确的任何变更

不适用场景： 单行代码修复、拼写错误修正、实现方案明确的微小变更。

The Cycle

工作流周期

dot

digraph feature_dev {
    rankdir=TB;
    node [shape=box];

    plan [label="Phase 1: Plan"];
    validate [label="Phase 2: Validate"];
    implement [label="Phase 3: Implement"];
    verify [label="Phase 4: Verify & Commit"];
    done [label="Done" shape=doublecircle];

    plan -> validate;
    validate -> plan [label="feedback"];
    validate -> implement [label="approved"];
    implement -> verify;
    verify -> implement [label="issues found"];
    verify -> done [label="all green"];
}

dot

digraph feature_dev {
    rankdir=TB;
    node [shape=box];

    plan [label="Phase 1: Plan"];
    validate [label="Phase 2: Validate"];
    implement [label="Phase 3: Implement"];
    verify [label="Phase 4: Verify & Commit"];
    done [label="Done" shape=doublecircle];

    plan -> validate;
    validate -> plan [label="feedback"];
    validate -> implement [label="approved"];
    implement -> verify;
    verify -> implement [label="issues found"];
    verify -> done [label="all green"];
}

Phase 1 - Plan

第一阶段 - 规划

Before writing any code, understand the problem and design the solution.

Discover relevant skills - List available skills and invoke any that match the stack or task type (e.g.,
```
swiftui-expert-skill
```
,
```
nitro-backend
```
,
```
frontend-design
```
)
Clarify scope - If requirements are ambiguous, invoke
```
superpowers:brainstorming
```
to explore intent. Use
```
AskUserQuestion
```
to resolve open questions
Enter plan mode - Use
```
EnterPlanMode
```
to draft a detailed plan including:
- Context and motivation
- Files to create, modify, or delete
- Step-by-step implementation order
- Verification strategy (build commands, tests to run)
Track work - Use
```
TaskCreate
```
to create a task list from the plan

在编写任何代码之前，先理解问题并设计解决方案。

梳理相关技能 - 列出可用技能，调用任何与技术栈或任务类型匹配的技能（如
```
swiftui-expert-skill
```
、
```
nitro-backend
```
、
```
frontend-design
```
）
明确范围 - 如果需求模糊，调用
```
superpowers:brainstorming
```
探索意图。使用
```
AskUserQuestion
```
解决未明确的问题
进入规划模式 - 使用
```
EnterPlanMode
```
起草详细规划，包括：
- 背景和动机
- 需要创建、修改或删除的文件
- 分步实现顺序
- 验证策略（构建命令、要运行的测试）
跟踪工作 - 使用
```
TaskCreate
```
根据规划创建任务列表

Phase 2 - Validate

第二阶段 - 验证

Never start implementation without explicit approval.

Present the plan - Use
```
ExitPlanMode
```
to submit the plan for review
Integrate feedback - If the user requests changes, update the plan and re-submit
Wait for approval - Do not proceed until the user explicitly approves

未经明确批准，不得开始实现。

提交规划 - 使用
```
ExitPlanMode
```
提交规划以供评审
整合反馈 - 如果用户要求变更，更新规划并重新提交
等待批准 - 在用户明确批准前，不得继续推进

Phase 3 - Implement

第三阶段 - 实现

Follow the validated plan step by step.

Work through tasks in order - Use
```
TaskUpdate
```
to mark tasks
```
in_progress
```
then
```
completed
```
Invoke relevant skills - Use stack-specific skills for each part of the implementation
Stay focused - Implement exactly what was planned. If you discover something new is needed, discuss with the user before deviating
One commit per logical unit - Group related changes together. One feature = one commit

严格按照已验证的规划逐步执行。

按顺序完成任务 - 使用
```
TaskUpdate
```
将任务标记为
```
in_progress
```
（进行中），然后标记为
```
completed
```
（已完成）
调用相关技能 - 针对实现的每个部分使用特定技术栈的技能
保持专注 - 严格按照规划实现。如果发现需要新增内容，先与用户讨论再调整
每个逻辑单元对应一次提交 - 将相关变更分组。一个功能对应一次提交

Phase 4 - Verify & Commit

第四阶段 - 验证与提交

Every change must be verified before it's committed.

所有变更在提交前必须经过验证。

Code Review

代码评审

Invoke

superpowers:requesting-code-review

to have expert agents review the changes for:

Correctness and edge cases
Security vulnerabilities
Adherence to project conventions
Performance concerns

调用

superpowers:requesting-code-review

让专家Agent评审变更，检查：

正确性和边界情况
安全漏洞
是否符合项目规范
性能问题

Build Verification

构建验证

Run the project's build and type-check commands. These are typically defined in

CLAUDE.md

or discoverable from the project config:

TypeScript:
```
tsc --noEmit
```
,
```
npm run build
```
Swift/iOS:
```
xcodebuild build
```
Tests: project-specific test runner

Do not commit if the build fails. Fix issues and re-verify.

运行项目的构建和类型检查命令。这些命令通常在

CLAUDE.md

中定义，或可从项目配置中找到：

TypeScript：
```
tsc --noEmit
```
、
```
npm run build
```
Swift/iOS：
```
xcodebuild build
```
测试：项目特定的测试运行器

如果构建失败，请勿提交。 修复问题后重新验证。

Commit Convention

提交规范

Use conventional commits:

<type>(<scope>): <description>

Type	Usage
`feat`	New feature
`fix`	Bug fix
`chore`	Maintenance, cleanup, dependency updates
`refactor`	Code restructuring without behavior change
`docs`	Documentation only
`test`	Adding or updating tests

```
scope
```
: module or feature name in parentheses
```
description
```
: imperative mood, lowercase, no period
Add
```
Co-Authored-By
```
footer when assisted by AI

Examples:

feat(auth): add login page
fix(cellar): correct grid layout overflow
chore(deps): update nitro to 2.13
refactor(api): extract shared validation middleware

使用约定式提交（conventional commits）：

<type>(<scope>): <description>

类型	用途
`feat`	新功能
`fix`	Bug修复
`chore`	维护、清理、依赖更新
`refactor`	代码重构（无行为变更）
`docs`	仅文档变更
`test`	添加或更新测试

```
scope
```
：括号内填写模块或功能名称
```
description
```
：使用祈使语气、小写、无句号
当有AI协助时，添加
```
Co-Authored-By
```
脚注

示例：

feat(auth): add login page
fix(cellar): correct grid layout overflow
chore(deps): update nitro to 2.13
refactor(api): extract shared validation middleware

Red Flags

警示信号

Situation	Action
Starting to code without a plan	STOP - go to Phase 1
Plan not yet approved	STOP - go to Phase 2
Deviating from the plan	STOP - discuss with user first
Build fails before commit	STOP - fix and re-verify
Skipping code review	STOP - invoke review agents
Committing unrelated changes together	STOP - split into separate commits

场景	行动
未做规划就开始编码	停止 - 回到第一阶段
规划尚未获批	停止 - 回到第二阶段
偏离规划	停止 - 先与用户讨论
提交前构建失败	停止 - 修复后重新验证
跳过代码评审	停止 - 调用评审Agent
将不相关变更合并提交	停止 - 拆分为独立提交

Common Mistakes

常见错误

Skipping the plan for "simple" changes - Simple changes have a way of becoming complex. Plan anyway if it touches multiple files.
Not running the build before committing - Compilation errors caught after commit waste time and create noise in git history.
Scope creep during implementation - Stick to the plan. Improvements noticed along the way go into a separate task.
Giant commits mixing multiple concerns - Each logical change gets its own commit with a clear message.

为“简单”变更跳过规划 - 简单变更往往会变得复杂。如果涉及多个文件，无论如何都要做规划。
提交前不运行构建 - 提交后才发现编译错误会浪费时间，还会在Git历史中产生冗余信息。
实现过程中范围蔓延 - 严格遵循规划。实现过程中发现的改进点应放入单独任务。
提交包含多个无关内容的大变更 - 每个逻辑变更都应单独提交，并附上清晰的提交信息。