workbench-sdd

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Workbench SDD

Use this skill when a task needs to move from a fuzzy request into executable work.

This is the default workbench planning protocol unless the issue explicitly says the task is a quick fix, emergency repair, or direct verification run.

当任务需要从模糊的需求转化为可执行工作时，使用此Skill。

除非问题明确说明任务是快速修复、紧急修复或直接验证运行，否则这是默认的工作台规划协议。

Pipeline

流程阶段

Move work through these stages:

Raw Requirement
- Capture the user's literal request.
- Separate confirmed facts from assumptions.
- Name the owner, expected output, and known constraints.
Product Design
- Define the user-facing behavior, success criteria, non-goals, and edge cases.
- Keep the scope narrow unless the user asks for expansion.
Technical Design
- Identify the runtime owner, data path, files, commands, integrations, and risk surface.
- Prefer existing stable routes over new infrastructure.
Task List
- Convert the design into bounded tasks with owner, evidence, and verification criteria.
- Keep tasks executable by one agent unless the issue explicitly asks for parallel work.
- Mark
```
GOAL_MODE: yes
```
  when the owner must keep the objective alive across turns until verified.
Execution And Verification
- Execute only the assigned slice.
- Verify on the real path.
- Report evidence before claiming done.

按以下阶段推进工作：

原始需求
- 捕获用户的字面请求。
- 区分已确认事实与假设。
- 明确负责人、预期输出及已知约束。
产品设计
- 定义面向用户的行为、成功标准、非目标及边缘案例。
- 除非用户要求扩展，否则保持范围狭窄。
技术设计
- 确定运行时负责人、数据路径、文件、命令、集成点及风险面。
- 优先使用现有稳定路径，而非新建基础设施。
任务列表
- 将设计转化为有明确负责人、验证依据及验证标准的独立任务。
- 除非问题明确要求并行工作，否则任务需由单个Agent可执行。
- 当负责人必须在多轮交互中持续推进目标直至验证通过时，标记
```
GOAL_MODE: yes
```
  。
执行与验证
- 仅执行分配的任务部分。
- 在实际路径上进行验证。
- 报告验证依据后再宣告完成。

Stage Gate Rules

阶段门规则

Do not jump from an ambiguous raw request directly to implementation.
Do not expand blast radius just because more agents or tokens are available.
If a stage is already answered by issue text or prior comments, cite that evidence and move forward.
If the task is blocked by a missing decision, state the smallest decision needed.
If the task is low-risk and obvious, compress the stages into a short SDD card instead of creating ceremony.
If the user says "go", "continue", or an equivalent approval after a reviewed stage, record that as the gate approval context before proceeding.
When a stage has both proxy and agent-authored artifacts, use the complete agent-authored artifact as primary and keep the proxy comment as trace evidence.
If an issue is marked
```
GOAL_MODE: yes
```
, the Task List must include
```
GOAL_LOCK
```
, closeout gates, and operator-call conditions before execution starts.

不得从模糊的原始需求直接跳转到实现环节。
不得因可用Agent或令牌数量增加而扩大影响范围。
如果某阶段的内容已在问题文本或过往评论中给出，需引用相关依据并推进到下一阶段。
如果任务因缺少决策而受阻，说明所需的最小决策内容。
如果任务低风险且明确，可将阶段压缩为简短的SDD卡片，无需繁琐流程。
如果用户在某阶段审核后表示“开始”“继续”或类似批准，需记录该批准上下文后再推进。
当某阶段同时存在代理生成和Agent生成的工件时，以完整的Agent生成工件为主体，保留代理评论作为追溯依据。
如果问题标记为
```
GOAL_MODE: yes
```
，任务列表必须包含
```
GOAL_LOCK
```
、收尾门限及操作员呼叫条件，之后才能开始执行。

Comment Structure

评论结构

Each SDD stage is a structured issue comment, not an issue status. Use this header for every stage artifact:

text

SDD_STAGE: [Raw Requirement / Product Design / Technical Design / Task List / Execution And Verification]
OWNER: [one agent or human owner]
STATUS: READY_FOR_REVIEW / APPROVED / BLOCKED
REVIEWER: Workbench Supervisor or designated reviewer
EVIDENCE: [files, commands, issue/comment IDs, or artifacts checked]
HANDOFF_SUMMARY: [five lines or fewer: what the next agent needs without rereading full history]
SCOPED_EVIDENCE: [exact comment IDs, run IDs, commit hashes, files, or artifact paths to inspect]
ANTI_OVER_READ: [sources to skip unless needed, such as full issue lists or full comment history]

Put the stage-specific artifact after the header. Keep discussion replies separate from stage artifacts so the comment history remains scannable.

Every SDD stage comment must literally include the exact uppercase field names

HANDOFF_SUMMARY

SCOPED_EVIDENCE

, and

ANTI_OVER_READ

in the header. Do not substitute semantic equivalents such as "Evidence", "Skipped", "Context", or prose bullets. Every SDD review comment must literally include

VERDICT_SUMMARY

. The next agent should be able to start from the handoff summary alone and deep-read only the listed

SCOPED_EVIDENCE

每个SDD阶段都是结构化的问题评论，而非问题状态。为每个阶段工件使用以下头部：

text

SDD_STAGE: [Raw Requirement / Product Design / Technical Design / Task List / Execution And Verification]
OWNER: [one agent or human owner]
STATUS: READY_FOR_REVIEW / APPROVED / BLOCKED
REVIEWER: Workbench Supervisor or designated reviewer
EVIDENCE: [files, commands, issue/comment IDs, or artifacts checked]
HANDOFF_SUMMARY: [five lines or fewer: what the next agent needs without rereading full history]
SCOPED_EVIDENCE: [exact comment IDs, run IDs, commit hashes, files, or artifact paths to inspect]
ANTI_OVER_READ: [sources to skip unless needed, such as full issue lists or full comment history]

将阶段特定的工件放在头部之后。将讨论回复与阶段工件分开，以便评论历史保持易读性。

每个SDD阶段评论必须在头部中严格包含大写字段名

HANDOFF_SUMMARY

、

SCOPED_EVIDENCE

和

ANTI_OVER_READ

。不得使用语义等价的替代词，如“Evidence”“Skipped”“Context”或项目符号列表。每个SDD审核评论必须严格包含

VERDICT_SUMMARY

。下一个Agent应仅能从交接摘要入手，仅深入阅读列出的

SCOPED_EVIDENCE

内容。

Stage Gate Mechanics

阶段门机制

Supervisor review happens between stages with
```
VERDICT: PASS / FLAG / BLOCK
```
.
```
PASS
```
allows the next stage to start.
```
FLAG
```
means the current stage needs a targeted correction before handoff.
```
BLOCK
```
means the stage cannot proceed until the smallest blocking decision or missing input is resolved.
Issue statuses stay coarse:
```
todo
```
before work starts,
```
in_progress
```
while any SDD stage is active,
```
in_review
```
after execution is ready for final review, and
```
done
```
only after accepted evidence.

阶段之间由主管进行审核，给出
```
VERDICT: PASS / FLAG / BLOCK
```
。
```
PASS
```
允许启动下一阶段。
```
FLAG
```
表示当前阶段在交接前需要针对性修正。
```
BLOCK
```
表示在解决最小阻塞决策或缺失输入前，该阶段无法推进。
问题状态保持粗略分类：工作开始前为
```
todo
```
，任何SDD阶段进行中为
```
in_progress
```
，执行完成等待最终审核为
```
in_review
```
，仅在接受验证依据后标记为
```
done
```
。

Bypass Rules

绕过规则

Workbench Admin may use
```
SDD_BYPASS: quick-fix
```
for low-risk, obvious changes where a full SDD sequence would add noise.
Workbench Admin may use
```
SDD_BYPASS: emergency
```
for time-critical repair work.
Bypass is not allowed for high-risk, ambiguous, multi-system, or public/private boundary changes.
A bypassed issue still needs one clear owner, explicit scope, verification evidence, and Supervisor review before closure.

工作台管理员可对低风险、明确的变更使用
```
SDD_BYPASS: quick-fix
```
，完整SDD流程会增加冗余。
工作台管理员可对时间紧迫的修复工作使用
```
SDD_BYPASS: emergency
```
。
高风险、模糊、多系统或跨公私边界的变更不允许绕过流程。
绕过流程的问题仍需明确负责人、清晰范围、验证依据，并在关闭前经主管审核。

Execution Handoff

执行交接

The Task List stage names the execution owner, exact files/resources, non-goals, approval gates, and verification commands.
For
```
GOAL_MODE: yes
```
, the Task List also names required build/test/help-smoke/docs-or-report/git-status gates and the conditions for calling the operator.
Execution owners implement only their assigned slice and do not create follow-on work unless explicitly requested.
T8 or smoke-test work remains separate when the task list says it depends on a committed repo batch.
Completion reports include changed files, verification output, residual risks, commit hash or artifact link, work directory, and branch.
Live skill or agent-binding changes must have a backup and post-change verification before final PASS.
If a run reaches evidence-ready state but does not post a stage artifact, the conductor may post a proxy artifact using run-message evidence and mark it as proxy/recovery evidence.

任务列表阶段需指定执行负责人、确切文件/资源、非目标、批准门限及验证命令。
对于
```
GOAL_MODE: yes
```
的任务，任务列表还需指定必要的构建/测试/冒烟测试/文档或报告/git状态门限，以及呼叫操作员的条件。
执行负责人仅实现分配的任务部分，除非明确要求，否则不得创建后续工作。
当任务列表显示依赖已提交的仓库批次时，T8或冒烟测试工作需保持独立。
完成报告需包含变更文件、验证输出、剩余风险、提交哈希或工件链接、工作目录及分支。
实时Skill或Agent绑定变更必须有备份，并在变更后进行验证，才能最终获得PASS。
如果运行达到可提交验证依据的状态但未发布阶段工件，指挥者可使用运行消息依据发布代理工件，并标记为代理/恢复依据。

Output Contract

输出约定

For planning or routing, return:

```
SDD_STAGE
```
: current stage.
```
CONFIRMED
```
: facts and constraints.
```
ASSUMPTIONS
```
: assumptions that still matter.
```
NEXT_TASKS
```
: owner-scoped tasks.
```
VERIFICATION
```
: evidence required to close.

For execution, return:

what changed,
what was verified,
what remains risky or blocked.

对于规划或路由，返回：

```
SDD_STAGE
```
: 当前阶段。
```
CONFIRMED
```
: 事实与约束。
```
ASSUMPTIONS
```
: 仍需关注的假设。
```
NEXT_TASKS
```
: 负责人范围的任务。
```
VERIFICATION
```
: 关闭任务所需的验证依据。

对于执行，返回：

变更内容，
验证内容，
仍存在风险或阻塞的内容。