ce-work

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Work Execution Command

工作执行命令

Execute work efficiently while maintaining quality and finishing features.

在保证质量并完成功能的同时高效执行工作。

Introduction

简介

This command takes a work document (plan, specification, or todo file) or a bare prompt describing the work, and executes it systematically. The focus is on shipping complete features by understanding requirements quickly, following existing patterns, and maintaining quality throughout.

本命令接收工作文档（计划、规范或待办文件）或描述工作的纯提示，并系统地执行工作。核心是通过快速理解需求、遵循现有模式并全程保证质量，交付完整功能。

Input Document

输入文档

<input_document> #$ARGUMENTS </input_document>

Execution Workflow

执行工作流

Phase 0: Input Triage

阶段0：输入分类

Determine how to proceed based on what was provided in

<input_document>

Plan document (input is a file path to an existing plan, specification, or todo file) → skip to Phase 1.

Bare prompt (input is a description of work, not a file path):

Scan the work area
- Identify files likely to change based on the prompt
- Find existing test files for those areas (search for test/spec files that import, reference, or share names with the implementation files)
- Note local patterns and conventions in the affected areas

Assess complexity and route

Complexity	Signals	Action
Trivial	1-2 files, no behavioral change (typo, config, rename)	Proceed to Phase 1 step 2 (environment setup), then implement directly — no task list, no execution loop. Apply Test Discovery if the change touches behavior-bearing code
Small / Medium	Clear scope, under ~10 files	Build a task list from discovery. Proceed to Phase 1 step 2
Large	Cross-cutting, architectural decisions, 10+ files, touches auth/payments/migrations	Inform the user this would benefit from `/ce-brainstorm` or `/ce-plan` to surface edge cases and scope boundaries. Honor their choice. If proceeding, build a task list and continue to Phase 1 step 2

根据

<input_document>

中提供的内容确定执行方式。

计划文档（输入为现有计划、规范或待办文件的文件路径）→ 直接进入阶段1。

纯提示（输入为工作描述，而非文件路径）：

扫描工作区域
- 根据提示识别可能需要修改的文件
- 查找这些区域的现有测试文件（搜索导入、引用或与实现文件共享命名模式的测试/规格文件）
- 记录受影响区域的本地模式和约定

评估复杂度并选择执行路径

复杂度	信号	操作
trivial（微小）	仅1-2个文件，无行为变更（拼写错误、配置修改、重命名）	直接进入阶段1第2步（环境设置），然后直接实现——无需任务列表，无需执行循环。如果变更涉及影响行为的代码，应用Test Discovery（测试发现）
小/中型	范围明确，涉及文件少于10个	根据扫描结果构建任务列表，进入阶段1第2步
大型	跨模块、涉及架构决策、10个以上文件、触及认证/支付/迁移模块	告知用户此类工作更适合使用 `/ce-brainstorm` 或 `/ce-plan` 来梳理边缘情况和范围边界，尊重用户选择。若继续执行，构建任务列表并进入阶段1第2步

Phase 1: Quick Start

阶段1：快速启动

Read Plan and Clarify (skip if arriving from Phase 0 with a bare prompt)
- Read the work document completely
- Treat the plan as a decision artifact, not an execution script
- If the plan includes sections such as
```
Implementation Units
```
  ,
```
Work Breakdown
```
  ,
```
Requirements Trace
```
  ,
```
Files
```
  ,
```
Test Scenarios
```
  , or
```
Verification
```
  , use those as the primary source material for execution
- Check for
```
Execution note
```
  on each implementation unit — these carry the plan's execution posture signal for that unit (for example, test-first or characterization-first). Note them when creating tasks.
- Check for a
```
Deferred to Implementation
```
  or
```
Implementation-Time Unknowns
```
  section — these are questions the planner intentionally left for you to resolve during execution. Note them before starting so they inform your approach rather than surprising you mid-task
- Check for a
```
Scope Boundaries
```
  section — these are explicit non-goals. Refer back to them if implementation starts pulling you toward adjacent work
- Review any references or links provided in the plan
- If the user explicitly asks for TDD, test-first, or characterization-first execution in this session, honor that request even if the plan has no
```
Execution note
```
- If anything is unclear or ambiguous, ask clarifying questions now
- If clarifying questions were needed above, get user approval on the resolved answers. If no clarifications were needed, proceed without a separate approval step — plan scope is the plan's authority, not something to renegotiate
- Do not skip this - better to ask questions now than build the wrong thing
Setup Environment

First, check the current branch:
bash
```
current_branch=$(git branch --show-current)
default_branch=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')

# Fallback if remote HEAD isn't set
if [ -z "$default_branch" ]; then
  default_branch=$(git rev-parse --verify origin/main >/dev/null 2>&1 && echo "main" || echo "master")
fi
```
If already on a feature branch (not the default branch):
First, check whether the branch name is meaningful — a name like
```
feat/crowd-sniff
```
or
```
fix/email-validation
```
tells future readers what the work is about. Auto-generated worktree names (e.g.,
```
worktree-jolly-beaming-raven
```
) or other opaque names do not.
If the branch name is meaningless or auto-generated, suggest renaming it before continuing:
bash
```
git branch -m <meaningful-name>
```
Derive the new name from the plan title or work description (e.g.,
```
feat/crowd-sniff
```
). Present the rename as a recommended option alongside continuing as-is.
Then ask: "Continue working on
```
[current_branch]
```
, or create a new branch?"
- If continuing (with or without rename), proceed to step 3
- If creating new, follow Option A or B below
If on the default branch, choose how to proceed:

Option A: Create a new branch
bash
```
git pull origin [default_branch]
git checkout -b feature-branch-name
```
Use a meaningful name based on the work (e.g.,
```
feat/user-authentication
```
,
```
fix/email-validation
```
).
Option B: Use a worktree (recommended for parallel development)
bash
```
skill: ce-worktree
# The skill will create a new branch from the default branch in an isolated worktree
```
Option C: Continue on the default branch
- Requires explicit user confirmation
- Only proceed after user explicitly says "yes, commit to [default_branch]"
- Never commit directly to the default branch without explicit permission
Recommendation: Use worktree if:
- You want to work on multiple features simultaneously
- You want to keep the default branch clean while experimenting
- You plan to switch between branches frequently
Create Todo List (skip if Phase 0 already built one, or if Phase 0 routed as Trivial)
- Use your available task tracking tool (e.g., TodoWrite, task lists) to break the plan into actionable tasks
- Derive tasks from the plan's implementation units, dependencies, files, test targets, and verification criteria
- Carry each unit's
```
Execution note
```
  into the task when present
- For each unit, read the
```
Patterns to follow
```
  field before implementing — these point to specific files or conventions to mirror
- Use each unit's
```
Verification
```
  field as the primary "done" signal for that task
- Do not expect the plan to contain implementation code, micro-step TDD instructions, or exact shell commands
- Include dependencies between tasks
- Prioritize based on what needs to be done first
- Include testing and quality check tasks
- Keep tasks specific and completable

Choose Execution Strategy

After creating the task list, decide how to execute based on the plan's size and dependency structure:

Strategy	When to use
Inline	1-2 small tasks, or tasks needing user interaction mid-flight. Default for bare-prompt work — bare prompts rarely produce enough structured context to justify subagent dispatch
Serial subagents	3+ tasks with dependencies between them. Each subagent gets a fresh context window focused on one unit — prevents context degradation across many tasks. Requires plan-unit metadata (Goal, Files, Approach, Test scenarios)
Parallel subagents	3+ tasks that pass the Parallel Safety Check (below). Dispatch independent units simultaneously, run dependent units after their prerequisites complete. Requires plan-unit metadata

Parallel Safety Check — required before choosing parallel dispatch:

Build a file-to-unit mapping from every candidate unit's
```
Files:
```
section (Create, Modify, and Test paths)
Check for intersection — any file path appearing in 2+ units means overlap
If any overlap is found, downgrade to serial subagents. Log the reason (e.g., "Units 2 and 4 share
```
config/routes.rb
```
— using serial dispatch"). Serial subagents still provide context-window isolation without shared-directory risks

Even with no file overlap, parallel subagents sharing a working directory face git index contention (concurrent staging/committing corrupts the index) and test interference (concurrent test runs pick up each other's in-progress changes). The parallel subagent constraints below mitigate these.

Subagent dispatch uses your available subagent or task spawning mechanism. For each unit, give the subagent:

The full plan file path (for overall context)
The specific unit's Goal, Files, Approach, Execution note, Patterns, Test scenarios, and Verification
Any resolved deferred questions relevant to that unit
Instruction to check whether the unit's test scenarios cover all applicable categories (happy paths, edge cases, error paths, integration) and supplement gaps before writing tests

Parallel subagent constraints — when dispatching units in parallel (not serial or inline):

Instruct each subagent: "Do not stage files (
```
git add
```
), create commits, or run the project test suite. The orchestrator handles testing, staging, and committing after all parallel units complete."
These constraints prevent git index contention and test interference between concurrent subagents

Permission mode: Omit the

mode

parameter when dispatching subagents so the user's configured permission settings apply. Do not pass

mode: "auto"

— it overrides user-level settings like

bypassPermissions

After each subagent completes (serial mode):

Review the subagent's diff — verify changes match the unit's scope and
```
Files:
```
list
Run the relevant test suite to confirm the tree is healthy
If tests fail, diagnose and fix before proceeding — do not dispatch dependent units on a broken tree
Update the plan checkboxes and task list
Dispatch the next unit

After all parallel subagents in a batch complete:

Wait for every subagent in the current parallel batch to finish before acting on any of their results
Cross-check for discovered file collisions: compare the actual files modified by all subagents in the batch (not just their declared
```
Files:
```
lists). Subagents may create or modify files not anticipated during planning — this is expected, since plans describe what not how. A collision only matters when 2+ subagents in the same batch modified the same file. In a shared working directory, only the last writer's version survives — the other unit's changes to that file are lost. If a collision is detected: commit all non-colliding files from all units first, then re-run the affected units serially for the shared file so each builds on the other's committed work
For each completed unit, in dependency order: review the diff, run the relevant test suite, stage only that unit's files, and commit with a conventional message derived from the unit's Goal
If tests fail after committing a unit's changes, diagnose and fix before committing the next unit
Update the plan checkboxes and task list
Dispatch the next batch of independent units, or the next dependent unit

阅读计划并澄清疑问 (如果是从阶段0的纯提示进入，可跳过此步)
- 完整阅读工作文档
- 将计划视为决策依据，而非执行脚本
- 如果计划包含
```
Implementation Units
```
  （实现单元）、
```
Work Breakdown
```
  （工作分解）、
```
Requirements Trace
```
  （需求跟踪）、
```
Files
```
  （文件）、
```
Test Scenarios
```
  （测试场景）或
```
Verification
```
  （验证）等部分，将这些作为执行的主要参考资料
- 检查每个实现单元的
```
Execution note
```
  （执行说明）——这些包含了该单元的执行姿态信号（例如test-first或characterization-first）。创建任务时需记录这些说明
- 检查是否有
```
Deferred to Implementation
```
  （延迟到实现阶段）或
```
Implementation-Time Unknowns
```
  （实现阶段未知项）部分——这些是规划者特意留到执行阶段解决的问题。开始执行前需记录这些问题，避免执行过程中出现意外
- 检查是否有
```
Scope Boundaries
```
  （范围边界）部分——这些是明确的非目标。如果实现过程中涉及相邻工作，需参考此部分
- 查看计划中提供的所有参考资料或链接
- 如果用户在本次会话中明确要求TDD、test-first或characterization-first执行方式，即使计划中没有
```
Execution note
```
  ，也需遵循用户要求
- 如果有任何不清楚或模糊的内容，立即提出澄清问题
- 如果上述步骤中需要澄清疑问，需获得用户对解决方案的认可。如果无需澄清，直接继续——计划范围具有权威性，无需重新协商
- 请勿跳过此步骤——现在提出问题总比构建错误的内容好
环境设置

首先，检查当前分支：
bash
```
current_branch=$(git branch --show-current)
default_branch=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')

# Fallback if remote HEAD isn't set
if [ -z "$default_branch" ]; then
  default_branch=$(git rev-parse --verify origin/main >/dev/null 2>&1 && echo "main" || echo "master")
fi
```
如果已在功能分支上（非默认分支）：
首先，检查分支名称是否有意义——像
```
feat/crowd-sniff
```
或
```
fix/email-validation
```
这样的名称能让未来的读者了解工作内容。自动生成的工作树名称（例如
```
worktree-jolly-beaming-raven
```
）或其他模糊名称则不具备此作用。
如果分支名称无意义或为自动生成，建议在继续前重命名：
bash
```
git branch -m <meaningful-name>
```
根据计划标题或工作描述生成新名称（例如
```
feat/crowd-sniff
```
）。将重命名作为推荐选项，同时提供继续使用原名称的选择。
然后询问："继续在
```
[current_branch]
```
上工作，还是创建新分支？"
- 如果选择继续（无论是否重命名），进入第3步
- 如果选择创建新分支，遵循以下选项A或B
如果在默认分支上，选择执行方式：

选项A：创建新分支
bash
```
git pull origin [default_branch]
git checkout -b feature-branch-name
```
根据工作内容使用有意义的名称（例如
```
feat/user-authentication
```
、
```
fix/email-validation
```
）。
选项B：使用worktree（推荐用于并行开发）
bash
```
skill: ce-worktree
# 该skill会在独立的worktree中从默认分支创建新分支
```
选项C：继续在默认分支上工作
- 需要用户明确确认
- 仅在用户明确表示"yes, commit to [default_branch]"后才能继续
- 未经明确许可，绝不能直接提交到默认分支
推荐场景：在以下情况使用worktree：
- 需要同时开发多个功能
- 希望在实验时保持默认分支干净
- 计划频繁切换分支
创建待办列表 (如果阶段0已构建列表，或阶段0判定为trivial，可跳过此步)
- 使用可用的任务跟踪工具（例如TodoWrite、任务列表）将计划分解为可执行的任务
- 根据计划的实现单元、依赖关系、文件、测试目标和验证标准生成任务
- 如果实现单元有
```
Execution note
```
  ，将其纳入对应任务
- 对于每个单元，在实现前阅读
```
Patterns to follow
```
  （遵循模式）字段——这些指向需要参考的特定文件或约定
- 将每个单元的
```
Verification
```
  （验证）字段作为该任务的主要"完成"信号
- 不要期望计划包含实现代码、微步骤TDD指令或精确的shell命令
- 包含任务之间的依赖关系
- 根据优先级排序
- 包含测试和质量检查任务
- 确保任务具体且可完成

选择执行策略

创建任务列表后，根据计划的规模和依赖结构决定执行方式：

策略	使用场景
Inline（内联执行）	1-2个小型任务，或执行过程中需要用户交互的任务。纯提示工作的默认策略——纯提示很少能提供足够的结构化上下文，不足以支撑subagent调度
Serial subagents（串行子代理）	3个以上存在依赖关系的任务。每个subagent获得聚焦于单个单元的全新上下文窗口——避免多任务导致的上下文退化。需要计划单元元数据（目标、文件、方法、测试场景）
Parallel subagents（并行子代理）	3个以上通过Parallel Safety Check（并行安全检查）的任务。同时调度独立单元，依赖单元在其前置任务完成后执行。需要计划单元元数据

并行安全检查——选择并行调度前必须执行：

根据每个候选单元的
```
Files:
```
部分（创建、修改和测试路径）构建文件-单元映射
检查是否存在交集——任何文件路径出现在2个以上单元中即表示存在重叠
如果发现重叠，降级为串行子代理。记录原因（例如"单元2和4共享
```
config/routes.rb
```
——使用串行调度"）。串行子代理仍能提供上下文窗口隔离，且无共享目录风险

即使没有文件重叠，共享工作目录的并行子代理仍会面临git索引冲突（并发暂存/提交会损坏索引）和测试干扰（并发测试会获取彼此的未完成变更）。以下并行子代理约束可缓解这些问题。

Subagent调度使用可用的子代理或任务生成机制。对于每个单元，向subagent提供：

完整计划文件路径（用于全局上下文）
该单元的目标、文件、方法、执行说明、模式、测试场景和验证标准
与该单元相关的已解决延迟问题
指令：检查单元的测试场景是否覆盖所有适用类别（正常路径、边缘情况、错误路径、集成测试），并在编写测试前补充缺失部分

并行子代理约束——当并行调度单元时（非串行或内联）：

指示每个subagent："不要暂存文件（
```
git add
```
）、创建提交或运行项目测试套件。协调器会在所有并行单元完成后处理测试、暂存和提交。"
这些约束可避免并发subagent之间的git索引冲突和测试干扰

权限模式：调度subagent时省略

mode

参数，以便应用用户配置的权限设置。不要传递

mode: "auto"

——这会覆盖用户级设置如

bypassPermissions

。

每个subagent完成后（串行模式）：

审查subagent的diff——验证变更是否符合单元范围和
```
Files:
```
列表
运行相关测试套件以确认代码库健康
如果测试失败，在继续前诊断并修复——不要在损坏的代码库上调度依赖单元
更新计划复选框和任务列表
调度下一个单元

所有并行子agent批次完成后：

等待当前并行批次中的所有subagent完成后，再处理其结果
交叉检查是否存在文件冲突：比较批次中所有subagent实际修改的文件（不仅是其声明的
```
Files:
```
列表）。subagent可能会创建或修改规划阶段未预期的文件——这是正常的，因为计划描述的是做什么而非怎么做。当同一批次中的2个以上subagent修改了同一个文件时，才会产生冲突。在共享工作目录中，只有最后写入的版本会保留——其他单元对该文件的变更会丢失。如果检测到冲突：先提交所有单元的非冲突文件，然后针对共享文件重新串行运行受影响的单元，以便每个单元都基于其他单元的已提交工作进行构建
按依赖顺序处理每个已完成单元：审查diff、运行相关测试套件、仅暂存该单元的文件，并根据单元目标生成符合约定的提交消息
如果提交单元变更后测试失败，在提交下一个单元前诊断并修复
更新计划复选框和任务列表
调度下一批独立单元，或下一个依赖单元

Phase 2: Execute

阶段2：执行

Task Execution Loop

For each task in priority order:

while (tasks remain):
  - Mark task as in-progress
  - Read any referenced files from the plan or discovered during Phase 0
  - Look for similar patterns in codebase
  - Find existing test files for implementation files being changed (Test Discovery — see below)
  - Implement following existing conventions
  - Add, update, or remove tests to match implementation changes (see Test Discovery below)
  - Run System-Wide Test Check (see below)
  - Run tests after changes
  - Assess testing coverage: did this task change behavior? If yes, were tests written or updated? If no tests were added, is the justification deliberate (e.g., pure config, no behavioral change)?
  - Mark task as completed
  - Evaluate for incremental commit (see below)

When a unit carries an

Execution note

, honor it. For test-first units, write the failing test before implementation for that unit. For characterization-first units, capture existing behavior before changing it. For units without an

Execution note

, proceed pragmatically.

Guardrails for execution posture:

Do not write the test and implementation in the same step when working test-first
Do not skip verifying that a new test fails before implementing the fix or feature
Do not over-implement beyond the current behavior slice when working test-first
Skip test-first discipline for trivial renames, pure configuration, and pure styling work

Test Discovery — Before implementing changes to a file, find its existing test files (search for test/spec files that import, reference, or share naming patterns with the implementation file). When a plan specifies test scenarios or test files, start there, then check for additional test coverage the plan may not have enumerated. Changes to implementation files should be accompanied by corresponding test updates — new tests for new behavior, modified tests for changed behavior, removed or updated tests for deleted behavior.

Test Scenario Completeness — Before writing tests for a feature-bearing unit, check whether the plan's

Test scenarios

cover all categories that apply to this unit. If a category is missing or scenarios are vague (e.g., "validates correctly" without naming inputs and expected outcomes), supplement from the unit's own context before writing tests:

Category	When it applies	How to derive if missing
Happy path	Always for feature-bearing units	Read the unit's Goal and Approach for core input/output pairs
Edge cases	When the unit has meaningful boundaries (inputs, state, concurrency)	Identify boundary values, empty/nil inputs, and concurrent access patterns
Error/failure paths	When the unit has failure modes (validation, external calls, permissions)	Enumerate invalid inputs the unit should reject, permission/auth denials it should enforce, and downstream failures it should handle
Integration	When the unit crosses layers (callbacks, middleware, multi-service)	Identify the cross-layer chain and write a scenario that exercises it without mocks

System-Wide Test Check — Before marking a task done, pause and ask:

Question	What to do
What fires when this runs? Callbacks, middleware, observers, event handlers — trace two levels out from your change.	Read the actual code (not docs) for callbacks on models you touch, middleware in the request chain, `after_*` hooks.
Do my tests exercise the real chain? If every dependency is mocked, the test proves your logic works in isolation — it says nothing about the interaction.	Write at least one integration test that uses real objects through the full callback/middleware chain. No mocks for the layers that interact.
Can failure leave orphaned state? If your code persists state (DB row, cache, file) before calling an external service, what happens when the service fails? Does retry create duplicates?	Trace the failure path with real objects. If state is created before the risky call, test that failure cleans up or that retry is idempotent.
What other interfaces expose this? Mixins, DSLs, alternative entry points (Agent vs Chat vs ChatMethods).	Grep for the method/behavior in related classes. If parity is needed, add it now — not as a follow-up.
Do error strategies align across layers? Retry middleware + application fallback + framework error handling — do they conflict or create double execution?	List the specific error classes at each layer. Verify your rescue list matches what the lower layer actually raises.

When to skip: Leaf-node changes with no callbacks, no state persistence, no parallel interfaces. If the change is purely additive (new helper method, new view partial), the check takes 10 seconds and the answer is "nothing fires, skip."

When this matters most: Any change that touches models with callbacks, error handling with fallback/retry, or functionality exposed through multiple interfaces.

Incremental Commits

After completing each task, evaluate whether to create an incremental commit:

Commit when...	Don't commit when...
Logical unit complete (model, service, component)	Small part of a larger unit
Tests pass + meaningful progress	Tests failing
About to switch contexts (backend → frontend)	Purely scaffolding with no behavior
About to attempt risky/uncertain changes	Would need a "WIP" commit message

Heuristic: "Can I write a commit message that describes a complete, valuable change? If yes, commit. If the message would be 'WIP' or 'partial X', wait."

If the plan has Implementation Units, use them as a starting guide for commit boundaries — but adapt based on what you find during implementation. A unit might need multiple commits if it's larger than expected, or small related units might land together. Use each unit's Goal to inform the commit message.

Commit workflow:

bash

# 1. Verify tests pass (use project's test command)
# Examples: bin/rails test, npm test, pytest, go test, etc.

# 2. Stage only files related to this logical unit (not `git add .`)
git add <files related to this logical unit>

# 3. Commit with conventional message
git commit -m "feat(scope): description of this unit"

Handling merge conflicts: If conflicts arise during rebasing or merging, resolve them immediately. Incremental commits make conflict resolution easier since each commit is small and focused.

Note: Incremental commits use clean conventional messages without attribution footers. The final Phase 4 commit/PR includes the full attribution.

Parallel subagent mode: When units run as parallel subagents, the subagents do not commit — the orchestrator handles staging and committing after the entire parallel batch completes (see Parallel subagent constraints in Phase 1 Step 4). The commit guidance in this section applies to inline and serial execution, and to the orchestrator's commit decisions after parallel batch completion.

Follow Existing Patterns
- The plan should reference similar code - read those files first
- Match naming conventions exactly
- Reuse existing components where possible
- Follow project coding standards (see AGENTS.md; use CLAUDE.md only if the repo still keeps a compatibility shim)
- When in doubt, grep for similar implementations
Test Continuously
- Run relevant tests after each significant change
- Don't wait until the end to test
- Fix failures immediately
- Add new tests for new behavior, update tests for changed behavior, remove tests for deleted behavior
- Unit tests with mocks prove logic in isolation. Integration tests with real objects prove the layers work together. If your change touches callbacks, middleware, or error handling — you need both.
Simplify as You Go

After completing a cluster of related implementation units (or every 2-3 units), review recently changed files for simplification opportunities — consolidate duplicated patterns, extract shared helpers, and improve code reuse and efficiency. This is especially valuable when using subagents, since each agent works with isolated context and can't see patterns emerging across units.

Don't simplify after every single unit — early patterns may look duplicated but diverge intentionally in later units. Wait for a natural phase boundary or when you notice accumulated complexity.
If a
```
/simplify
```
skill or equivalent is available, use it. Otherwise, review the changed files yourself for reuse and consolidation opportunities.
Figma Design Sync (if applicable)

For UI work with Figma designs:
- Implement components following design specs
- Use ce-figma-design-sync agent iteratively to compare
- Fix visual differences identified
- Repeat until implementation matches design
Track Progress
- Keep the task list updated as you complete tasks
- Note any blockers or unexpected discoveries
- Create new tasks if scope expands
- Keep user informed of major milestones

任务执行循环

按优先级处理每个任务：

while (tasks remain):
  - 将任务标记为进行中
  - 阅读计划中引用的文件或阶段0中发现的文件
  - 在代码库中查找类似模式
  - 为正在修改的实现文件查找现有测试文件（Test Discovery——见下文）
  - 遵循现有约定进行实现
  - 添加、更新或删除测试以匹配实现变更（见下文Test Discovery）
  - 运行System-Wide Test Check（全局测试检查——见下文）
  - 变更后运行测试
  - 评估测试覆盖率：该任务是否改变了行为？如果是，是否编写或更新了测试？如果未添加测试，是否有合理的理由（例如纯配置变更，无行为变更）？
  - 将任务标记为已完成
  - 评估是否进行增量提交（见下文）

如果单元有

Execution note

，需遵循该说明。对于test-first单元，在实现该单元前先编写失败的测试。对于characterization-first单元，在变更前先捕获现有行为。对于无

Execution note

的单元，采用务实的方式执行。

执行姿态约束：

采用test-first方式时，不要在同一步骤中编写测试和实现
不要跳过验证新测试在修复或功能实现前是否失败的步骤
采用test-first方式时，不要过度实现超出当前行为切片的内容
对于微小的重命名、纯配置变更和纯样式工作，可跳过test-first流程

Test Discovery（测试发现）——在修改文件前，查找其现有测试文件（搜索导入、引用或与实现文件共享命名模式的测试/规格文件）。如果计划指定了测试场景或测试文件，从这些开始，然后检查计划可能未列出的额外测试覆盖范围。实现文件的变更应伴随相应的测试更新——为新行为添加新测试，为变更的行为修改测试，为删除的行为移除或更新测试。

测试场景完整性——为功能单元编写测试前，检查计划的

Test scenarios

是否覆盖了该单元的所有适用类别。如果某类别缺失或场景模糊（例如"正确验证"但未指定输入和预期结果），在编写测试前从单元自身上下文补充：

类别	适用场景	缺失时如何推导
正常路径	所有功能单元	从单元的目标和方法中提取核心输入/输出对
边缘情况	单元有明确边界（输入、状态、并发）时	识别边界值、空/nil输入和并发访问模式
错误/失败路径	单元有失败模式（验证、外部调用、权限）时	列举单元应拒绝的无效输入、应强制执行的权限/认证拒绝，以及应处理的下游失败情况
集成测试	单元跨层（回调、中间件、多服务）时	识别跨层链，并编写无需mock的场景来测试整个链

System-Wide Test Check（全局测试检查）——在标记任务完成前，暂停并思考：

问题	操作
执行此变更时会触发什么？回调、中间件、观察者、事件处理程序——从变更点向外追踪两层。	阅读实际代码（而非文档），查看触及模型的回调、请求链中的中间件、 `after_*` 钩子。
我的测试是否覆盖了真实调用链？如果所有依赖都被mock，测试仅能证明逻辑在隔离环境中有效——无法证明交互是否正常。	至少编写一个集成测试，使用真实对象贯穿整个回调/中间件链。交互层不要使用mock。
失败是否会导致孤立状态？如果代码在调用外部服务前持久化状态（数据库行、缓存、文件），服务失败时会发生什么？重试是否会创建重复项？	使用真实对象追踪失败路径。如果在风险调用前创建了状态，测试失败是否会清理状态，或重试是否具有幂等性。
还有哪些接口暴露了此功能？混合类、DSL、替代入口点（Agent vs Chat vs ChatMethods）。	在相关类中搜索该方法/行为。如果需要保持一致性，立即添加——不要留到后续处理。
各层的错误策略是否一致？重试中间件 + 应用回退 + 框架错误处理——它们是否冲突或导致重复执行？	列出各层的具体错误类。验证你的异常捕获列表是否与下层实际抛出的异常匹配。

可跳过场景：无回调、无状态持久化、无并行接口的叶子节点变更。如果变更是纯添加（新辅助方法、新视图片段），检查仅需10秒，结果为"无触发内容，跳过"。

重点关注场景：任何触及带回调的模型、带回退/重试的错误处理，或通过多个接口暴露的功能的变更。

增量提交

完成每个任务后，评估是否创建增量提交：

提交时机	不提交时机
逻辑单元完成（模型、服务、组件）	大型单元的一小部分
测试通过 + 有意义的进展	测试失败
即将切换上下文（后端 → 前端）	纯脚手架变更，无行为改变
即将尝试有风险/不确定的变更	需要使用"WIP"（进行中）提交消息

启发式规则："我能否写出描述完整、有价值变更的提交消息？如果可以，提交。如果消息是'WIP'或'部分完成X'，等待。"

如果计划有Implementation Units（实现单元），将其作为提交边界的初始指导——但需根据实现过程中的发现进行调整。如果单元比预期大，可能需要多次提交；或者相关的小型单元可以合并提交。使用每个单元的目标来指导提交消息。

提交工作流：

bash

# 1. 验证测试通过（使用项目的测试命令）
# 示例：bin/rails test, npm test, pytest, go test, etc.

# 2. 仅暂存与当前逻辑单元相关的文件（不要使用`git add .`）
git add <files related to this logical unit>

# 3. 使用符合约定的消息提交
git commit -m "feat(scope): description of this unit"

处理合并冲突：如果在变基或合并过程中出现冲突，立即解决。增量提交使冲突解决更容易，因为每个提交都小而聚焦。

注意：增量提交使用清晰的约定消息，无需署名页脚。最终的阶段4提交/PR包含完整署名。

并行子代理模式：当单元以并行子代理运行时，subagent不进行提交——协调器在整个并行批次完成后处理暂存和提交（见阶段1第4步的并行子代理约束）。本节的提交指南适用于内联和串行执行，以及协调器在并行批次完成后的提交决策。

遵循现有模式
- 计划应引用类似代码——先阅读这些文件
- 严格匹配命名约定
- 尽可能重用现有组件
- 遵循项目编码标准（见AGENTS.md；仅当仓库仍保留兼容性垫片时使用CLAUDE.md）
- 如有疑问，搜索类似实现
持续测试
- 每次重大变更后运行相关测试
- 不要等到最后才测试
- 立即修复失败
- 为新行为添加新测试，为变更的行为更新测试，为删除的行为移除测试
- 带mock的单元测试证明逻辑在隔离环境中有效。带真实对象的集成测试证明各层协同工作有效。 如果变更触及回调、中间件或错误处理——你需要同时进行这两种测试。
逐步简化

在完成一组相关实现单元后（或每完成2-3个单元），审查最近修改的文件以寻找简化机会——合并重复模式、提取共享辅助方法、提高代码重用性和效率。当使用subagent时，这一点尤为重要，因为每个agent都在隔离的上下文中工作，无法跨单元识别模式。

不要在每个单元完成后都进行简化——早期的模式可能看似重复，但在后续单元中会有意发散。等待自然的阶段边界，或当你注意到复杂度累积时再进行简化。
如果有
```
/simplify
```
skill或类似工具，可使用它。否则，自行审查变更文件以寻找重用和合并机会。
Figma设计同步（如适用）

对于涉及Figma设计的UI工作：
- 按照设计规范实现组件
- 迭代使用ce-figma-design-sync agent进行对比
- 修复识别出的视觉差异
- 重复此过程直到实现与设计匹配
跟踪进度
- 完成任务后更新任务列表
- 记录任何障碍或意外发现
- 范围扩大时创建新任务
- 向用户通报重大里程碑

Phase 3-4: Quality Check and Ship It

阶段3-4：质量检查与交付

When all Phase 2 tasks are complete and execution transitions to quality check, read

references/shipping-workflow.md

for the full shipping workflow: quality checks, code review, final validation, PR creation, and notification.

当阶段2的所有任务完成，执行流程进入质量检查阶段时，阅读

references/shipping-workflow.md

以获取完整的交付工作流：质量检查、代码审查、最终验证、PR创建和通知。

Key Principles

核心原则

Start Fast, Execute Faster

快速启动，高效执行

Get clarification once at the start, then execute
Don't wait for perfect understanding - ask questions and move
The goal is to finish the feature, not create perfect process

开始时一次性澄清疑问，然后执行
不要等待完美理解——提出问题并推进
目标是完成功能，而非创建完美流程

The Plan is Your Guide

计划是你的指南

Work documents should reference similar code and patterns
Load those references and follow them
Don't reinvent - match what exists

工作文档应引用类似代码和模式
加载这些参考资料并遵循
不要重新发明——匹配现有内容

Test As You Go

逐步测试

Run tests after each change, not at the end
Fix failures immediately
Continuous testing prevents big surprises

每次变更后运行测试，而非等到最后
立即修复失败
持续测试避免后期出现大问题

Quality is Built In

内置质量保障

Follow existing patterns
Write tests for new code
Run linting before pushing
Review every change — inline for simple additive work, full review for everything else

遵循现有模式
为新代码编写测试
推送前运行代码检查
审查每一处变更——简单添加工作可内联审查，其他工作需全面审查

Ship Complete Features

交付完整功能

Mark all tasks completed before moving on
Don't leave features 80% done
A finished feature that ships beats a perfect feature that doesn't

完成所有任务后再推进
不要让功能停留在80%完成状态
交付的完整功能优于未交付的完美功能

Common Pitfalls to Avoid

需避免的常见陷阱

Analysis paralysis - Don't overthink, read the plan and execute
Skipping clarifying questions - Ask now, not after building wrong thing
Ignoring plan references - The plan has links for a reason
Testing at the end - Test continuously or suffer later
Forgetting to track progress - Update task status as you go or lose track of what's done
80% done syndrome - Finish the feature, don't move on early
Skipping review - Every change gets reviewed; only the depth varies
Re-scoping the plan into human-time phases - The plan's Implementation Units define the scope of execution. Do not estimate human-hours per unit, propose multi-day breakdowns, or ask the user to pick a subset of units for "this session". Agents execute at agent speed, and context-window pressure is addressed by subagent dispatch (Phase 1 Step 4), not by phased sessions. If a plan-file input is genuinely too large for a single execution, say so plainly and suggest the user return to
```
/ce-plan
```
to reduce scope — don't invent session phases as a workaround. For bare-prompt input, Phase 0's Large routing already handles oversized work

分析瘫痪 - 不要过度思考，阅读计划并执行
跳过澄清疑问 - 现在提问，不要等到构建错误内容后
忽略计划参考资料 - 计划中的链接存在是有原因的
最后才测试 - 持续测试，否则后期会吃苦头
忘记跟踪进度 - 及时更新任务状态，否则会忘记已完成的工作
80%完成综合征 - 完成功能，不要提前推进到下一项工作
跳过审查 - 每一处变更都要审查；仅审查深度有所不同
将计划重新划分为人工时间阶段 - 计划的Implementation Units定义了执行范围。不要估算每个单元的人工工时，不要提出多日分解方案，也不要让用户选择"本次会话"要执行的单元子集。Agent以Agent的速度执行，上下文窗口压力通过subagent调度（阶段1第4步）解决，而非通过分阶段会话。如果计划文件输入确实太大，无法单次执行，直接告知用户并建议返回
```
/ce-plan
```
缩小范围——不要发明会话阶段作为解决方法。对于纯提示输入，阶段0的大型工作路由已处理超大工作