use-workflow

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Use Workflow

使用工作流

Route work to the smallest fitting workflow. Honor repo-local instructions and explicit user requests. When they materially conflict, surface the conflict with a recommendation rather than silently choosing. Do not turn a clear low-risk task into a project.

Use the repo Glossary when present; otherwise use workflow-language.md.

将工作分配给最匹配的最小工作流。遵循代码库本地指令和用户明确请求。当两者存在实质性冲突时，需指出冲突并给出建议，而非擅自选择。切勿将明确的低风险任务转化为项目。

若存在代码库术语表则使用该术语表；否则使用workflow-language.md。

Routing

路由规则

Explain a code area or flow ->
```
explain-codebase
```
Diagnose a bug, failure, flake, unexpected output, or regression ->
```
diagnose-issue
```
Explicit planning request, or material ambiguity, coordination, cross-cutting scope, irreversibility, or risk ->
```
plan-work
```
Execute an already-decided scope from a Plan, handoff, findings, brief, docs task, fix, or refactor ->
```
implement-work
```
Write a continuation prompt or file ->
```
write-handoff
```
Review a Plan, change, round of fixes, or non-code artifact ->
```
review-work
```
Discover architecture improvement opportunities ->
```
improve-architecture
```
Simplify an already-bounded area without changing intended behavior ->
```
simplify-work
```
Answer a design question with a disposable mockup or logic prototype ->
```
plan-prototype
```
Write a commit message or commit changes ->
```
commit-work
```
when installed
Open or update a PR, deliver stacked PRs, or run the stack merge loop ->
```
manage-pr
```
when installed
Set up an isolated worktree or clean up stale ones ->
```
manage-worktrees
```
when installed
Answer a coding-standards question or ground a structure/verification decision ->
```
coding-standards
```
when installed

Clear low-risk work may remain direct; use

implement-work

when execution discipline or continuation context materially helps.

Concrete architecture review belongs to

review-work

. Use

simplify-work

for an explicitly chosen behavior-preserving simplification,

implement-work

for other decided changes, and

improve-architecture

when the opportunity or interface shape still needs discovery.

If several skills apply, choose the most specific. If the user names a skill, use it.

解释代码区域或流程 ->
```
explain-codebase
```
诊断 bug、故障、不稳定问题、意外输出或回归问题 ->
```
diagnose-issue
```
明确的规划请求，或存在重大歧义、协调需求、跨领域范围、不可逆性或风险 ->
```
plan-work
```
执行已确定范围的工作，包括来自规划、交接、调查结果、简报、文档任务、修复或重构的内容 ->
```
implement-work
```
编写续期提示或文件 ->
```
write-handoff
```
评审规划、变更、一轮修复或非代码制品 ->
```
review-work
```
发现架构改进机会 ->
```
improve-architecture
```
在不改变预期行为的前提下简化已界定的区域 ->
```
simplify-work
```
通过一次性原型或逻辑原型回答设计问题 ->
```
plan-prototype
```
编写提交信息或提交变更 -> 已安装时使用
```
commit-work
```
打开或更新PR、交付堆叠PR，或运行堆叠合并循环 -> 已安装时使用
```
manage-pr
```
设置独立工作树或清理陈旧工作树 -> 已安装时使用
```
manage-worktrees
```
回答编码标准问题或确定结构/验证决策 -> 已安装时使用
```
coding-standards
```

明确的低风险工作可直接处理；当执行规范或续期上下文对工作有实质性帮助时，使用

implement-work

。

具体的架构评审属于

review-work

范畴。针对明确选定的保留行为的简化工作使用

simplify-work

，其他已确定的变更使用

implement-work

，当改进机会或接口形态仍需探索时使用

improve-architecture

。

若多个技能适用，选择最具体的那个。若用户指定了某个技能，则使用该技能。

Cost and authority

成本与权限

Match questions, research, tools, artifacts, delegation, and verification to actual uncertainty and risk.
Consolidate owner questions and include a recommendation; do not interview for facts the repo can answer.
Research only gaps that can materially change the result, starting with local and first-party evidence.
Review and diagnosis are read-only unless the user explicitly asks for fixes or implementation.
Do not create a Plan, Roadmap, durable doc, handoff file, worktree, commit, PR, or issue unless requested or naturally required by the authorized workflow.
Every implementation Phase ends with an independent fresh-context review of the whole Phase scope. A direct implementation without a Plan is one Phase-equivalent review scope and receives the same review before delivery.
Plans may add review checkpoints after high-impact Tasks or Task groups. Low-impact Tasks do not need individual immediate reviews.
Do not recursively review a review. Verify delegated claims against primary evidence and stop when the requested scope is closed.

Keep workflow state in workflow artifacts. Durable delivery artifacts must not depend on Plan or Roadmap files or workflow-relative identifiers.

使问题调研、工具使用、制品生成、任务委派和验证工作与实际的不确定性和风险相匹配。
整合所有者的问题并给出建议；不要询问代码库可自行解答的事实性问题。
仅调研可能实质性改变结果的信息缺口，优先从本地和第一方证据入手。
评审和诊断工作为只读操作，除非用户明确要求修复或实现。
除非有请求或授权工作流自然要求，否则不得创建规划、路线图、持久文档、交接文件、工作树、提交、PR或问题。
每个实现阶段结束时，需对整个阶段范围进行独立的全新上下文评审。无规划的直接实现等同于一个阶段的评审范围，交付前需进行相同的评审。
规划可在高影响任务或任务组之后添加评审检查点。低影响任务无需单独的即时评审。
不要递归评审评审内容。根据原始证据验证委派的主张，当请求的范围完成时停止。

工作流状态需保存在工作流制品中。持久交付制品不得依赖规划或路线图文件，也不得依赖工作流相关标识符。