Back to Details

work

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Work

工作内容

Orchestrate end-to-end task implementation: understand the task, assess complexity, implement directly or distribute across a team, then polish the result.
编排端到端任务实现：理解任务、评估复杂度，直接实现或分配给团队完成，之后打磨结果。

Pre-flight

前置检查

Verify prerequisites before starting any work.
  1. Check 
    code-polish
    availability    : Confirm the 
    code-polish
    skill exists. If missing, stop immediately with: "The 
    code-polish
    skill is required but not installed."
  2. Verify repository context: Run 
    git rev-parse --is-inside-work-tree
    . If not inside a git worktree, stop with a clear error.
开始任何工作前先验证先决条件。
  1. 检查
    code-polish
    技能可用性    ：确认
    code-polish
    技能已存在。若缺失，立即停止并提示：“
    code-polish
    技能为必需项，但未安装。”
  2. 验证仓库上下文：执行
    git rev-parse --is-inside-work-tree
    命令。若不在git工作目录内，立即停止并给出明确错误提示。

Workflow

工作流程

1) Parse Task

1) 解析任务

Read the task description from 
$ARGUMENTS
.
  • If 
    $ARGUMENTS
    is empty, ask the user for a task description and stop.
  • Extract key signals: scope (files, modules, components mentioned), action type (new feature, bug fix, refactor, migration), and any constraints.
  • Note any referenced issues, PRs, or URLs for later context gathering.
从
$ARGUMENTS
中读取任务描述。
  • 若
    $ARGUMENTS
    为空，询问用户获取任务描述并停止操作。
  • 提取关键信息：范围（提及的文件、模块、组件）、操作类型（新功能开发、Bug修复、重构、迁移）及任何约束条件。
  • 记录任何关联的Issue、PR或URL，用于后续上下文收集。

2) Assess Complexity

2) 评估复杂度

Classify the task as simple or complex using these heuristics:
SignalSimpleComplex
File count1-3 files4+ files
Module spanSingle module or packageCross-module or cross-package
Dependency chainNo new dependenciesNew packages or service integrations
Risk surfaceLow (UI, docs, config)High (auth, payments, data, infra)
ParallelismSequential steps onlyIndependent subtasks benefit from concurrency
A task is complex when 3 or more signals fall in the complex column. When in doubt, prefer the simple path — team overhead is only justified when parallelism provides a real speedup.
  • Simple — proceed to Step 3.
  • Complex — proceed to Step 4.
使用以下规则将任务划分为简单或复杂：
信号指标简单任务复杂任务
文件数量1-3个文件4个及以上文件
模块范围单个模块或包跨模块或跨包
依赖链无新增依赖新增包或服务集成
风险面低风险（UI、文档、配置）高风险（认证、支付、数据、基础设施）
并行性仅支持顺序步骤独立子任务可从并行执行中获益
当3项及以上信号符合复杂任务特征时，判定为复杂任务。若存在疑问，优先按简单任务处理——仅当并行执行能切实提升效率时，才值得引入团队协作的额外开销。
  • 简单任务 —— 进入步骤3。
  • 复杂任务 —— 进入步骤4。

3) Implement (Simple Path)

3) 任务实现（简单路径）

Execute the task directly without spawning subagents.
  1. Gather context: Read all relevant files. Understand existing code, tests, and conventions.
  2. Implement: Make the changes. Follow project conventions inferred from existing code, linters, and formatters.
  3. Verify: Run the narrowest useful checks:
    • Formatter/linter on touched files.
    • Targeted tests for touched modules.
    • Type check when relevant.
    • If fast checks pass, run broader checks only when risk warrants it.
  4. Proceed to Step 5 (Polish).
无需生成子Agent，直接完成任务。
  1. 收集上下文：读取所有相关文件，理解现有代码、测试及约定。
  2. 实现开发：进行代码修改，遵循从现有代码、代码检查工具及格式化工具中推断出的项目约定。
  3. 验证检查：执行最必要的验证操作：
    • 对修改的文件运行格式化工具/代码检查工具。
    • 针对修改的模块执行定向测试。
    • 若相关，执行类型检查。
    • 若快速检查通过，仅当风险较高时才执行更全面的检查。
  4. 进入步骤5（代码打磨）。

4) Implement (Complex Path)

4) 任务实现（复杂路径）

Distribute work across a team of subagents.
将工作分配给子Agent团队完成。

4a) Decompose

4a) 任务拆分

Break the task into independent subtasks. Each subtask should:
  • Target a distinct set of files with minimal overlap.
  • Be completable without waiting on other subtasks (no circular dependencies).
  • Include clear acceptance criteria.
Avoid over-decomposition. If subtasks cannot run in parallel, prefer the simple path.
将任务拆分为独立的子任务。每个子任务需满足：
  • 针对一组明确区分的文件，重叠最小化。
  • 无需等待其他子任务即可完成（无循环依赖）。
  • 包含清晰的验收标准。
避免过度拆分。若子任务无法并行执行，优先选择简单路径。

4b) Create Team and Assign

4b) 创建团队并分配任务

Create a team with a name derived from the task (e.g., "add-auth", "refactor-api"). Create a task for each subtask. Set up dependencies when ordering matters.
Spawn implementation agents as teammates. Assign each agent one or more tasks.
Recommended team sizing:
  • 1 agent per module when modules are independent.
  • Separate agent for shared utilities when consumers depend on them (utility blocks consumers).
  • Dedicated agent for tests if test volume is high.
根据任务名称创建团队（例如“add-auth”、“refactor-api”）。为每个子任务创建独立任务项，若有顺序要求则设置依赖关系。
生成实现型Agent作为团队成员，为每个Agent分配一个或多个任务。
推荐团队规模：
  • 若模块相互独立，每个模块分配1个Agent。
  • 当多个消费者依赖共享工具库时，为共享工具库分配独立Agent（工具库的开发会阻塞消费者）。
  • 若测试量较大，分配专门的测试Agent。

4c) Coordinate

4c) 协调管理

Monitor progress. As agents complete tasks:
  • Review output for integration issues.
  • Resolve cross-agent conflicts (merge overlaps, API mismatches).
  • Assign follow-up tasks if gaps emerge.
After all tasks complete:
  • Run integration verification: full test suite, type check, lint.
  • Fix any integration issues directly — do not re-spawn agents for small fixes.
  • Shut down teammates.
  • Proceed to Step 5 (Polish).
监控任务进度。当Agent完成任务后：
  • 检查输出是否存在集成问题。
  • 解决跨Agent冲突（合并重叠代码、修复API不匹配问题）。
  • 若发现遗漏，分配后续补充任务。
所有任务完成后：
  • 执行集成验证：完整测试套件、类型检查、代码检查。
  • 直接修复任何集成问题——小问题无需重新生成Agent。
  • 终止团队成员Agent。
  • 进入步骤5（代码打磨）。

5) Polish

5) 代码打磨

Invoke 
/code-polish
to simplify and review all session-modified files.
Wait for completion. If it reports residual risks or stop conditions, relay them to the user.
This step is mandatory — always run it, even if the implementation seems clean.
调用
/code-polish
对本次会话中修改的所有文件进行简化和审查。
等待操作完成。若工具报告残留风险或停止条件，将相关信息反馈给用户。
此步骤为强制性操作——即使实现看起来无问题，也必须执行。

Error Handling

错误处理

ErrorResponse
Empty 
$ARGUMENTS
Ask for a task description and stop
code-polish
skill missing		Stop immediately with installation instructions
Not in a git repositoryStop with clear error
Verification failures after implAttempt to fix; if unfixable, report to user before polishing
Team agent fails or times outReclaim the task and complete it directly
code-polish
reports stop condition		Relay to user with context
错误类型响应方式
$ARGUMENTS
为空		询问用户获取任务描述并停止操作
code-polish
技能缺失		立即停止并提供安装指引
不在git仓库内停止操作并给出明确错误提示
实现后验证失败尝试修复；若无法修复，在打磨前向用户报告问题
团队Agent执行失败或超时收回任务并直接完成
code-polish
报告停止条件		结合上下文将信息反馈给用户

Stop Conditions

停止条件

Stop and ask for direction when:
  • The task description is ambiguous and multiple interpretations exist.
  • Implementation requires changing public APIs or breaking contracts not mentioned in the task.
  • The task scope grows beyond the original description during implementation.
  • External dependencies (APIs, services, packages) are unavailable or broken.
  • A CRITICAL security concern is discovered in existing code adjacent to the task.
出现以下情况时，停止操作并向用户请求指导：
  • 任务描述模糊，存在多种解读方式。
  • 实现需要修改任务描述中未提及的公共API或破坏现有契约。
  • 实现过程中任务范围超出原始描述。
  • 外部依赖（API、服务、包）不可用或已损坏。
  • 在任务相关的现有代码中发现严重安全问题。",