st-full-workflow

st-full-workflow

关键规则

按顺序执行全部三个步骤，中间不要等待用户输入。

输入

用户通过对话提供工作单。

操作流程

步骤 1：创建计划

1. 定位 strikethroo 根目录

从用户的工作目录运行 scripts/find-strikethroo-root.cjs。如果该脚本以非零状态退出，则停止并请用户运行 npx strikethroo init。

将其输出的路径视为后续所有步骤中的 <root>。

委派执行的工作进程跳过此步骤，不发送进度通知。

使用此技能的脚本路径，单独运行 scripts/check-for-updates.cjs "<root>"。保持用户的工作目录不变。读取标准输出中的一行 JSON。如果存在 notice，则在面向用户的最终回复中保留其原文。绝不暂停以征求许可，也绝不运行更新。

2. 加载项目上下文

读取 <root>/config/STRIKETHROO.md，了解此项目的目录约定。 读取 <root>/config/hooks/PRE_PLAN.md，并在继续之前执行其中的指示。读取 <root>/config/templates/PLAN_TEMPLATE.md；计划必须符合该模板。

同时读取 <root>/config/shared/anti-rationalization.md。

3. 分析工作单

识别以下内容：

• 目标。
• 范围和明确的边界。
• 成功标准。
• 依赖项、先决条件、阻碍因素。
• 技术要求和约束。

4. 澄清循环

如果缺少任何关键信息，向用户提出有针对性的问题。持续提问，直到没有其他问题。明确确认是否需要向后兼容性。绝不编造答案；绝不掩盖缺失的答案。

如果用户拒绝澄清阻塞性问题，则停止并报告计划仍需澄清。不要生成不完整的计划。

将 <root>/config/shared/anti-rationalization.md 应用于此合理化表：

你发现自己在想……	必须遵守的规则
“我可以合理地假设答案。”	假设不是答案。提出问题；绝不编造答案。
“再问一次很烦人。”	用户可以拒绝回答问题，这种情况可以补救；默默做出错误假设则不行。要提问。
“用户已经暗示了，所以事情已定。”	暗示不等于确认。将其作为问题提出，并获取明确答复。

5. 分配下一个计划 ID

运行 scripts/get-next-plan-id.cjs，获取下一个可用的计划 ID。计算其补零后的形式，用于目录名称（{padded-id}--{slug}），并在计划 frontmatter 中使用未补零的整数。

6. 输出计划

将计划写入 <root>/plans/{padded-id}--{slug}/plan-{padded-id}--{slug}.md，并确保 frontmatter 和各章节均符合 <root>/config/templates/PLAN_TEMPLATE.md。 不要包含时间估算、任务清单或代码示例；这些内容属于任务生成步骤。

根据计划摘要生成 <slug>：仅使用小写字母、数字和连字符，合并连续连字符，并去除首尾连字符。

7. 运行计划后置钩子

执行 <root>/config/hooks/POST_PLAN.md。

8. 输出步骤 1 的结构化摘要

步骤 1 结束时，必须恰好输出以下代码块（如有保留的更新通知，则在工作流最终摘要之后附上）：

---

Plan Summary:
- Plan ID: [numeric-id]
- Plan File: [absolute-path-to-plan-file]

从此输出中解析 Plan ID 值，并传递给步骤 2。

步骤 2：任务生成

使用步骤 1 中的计划 ID：

1. 解析计划

运行 scripts/validate-plan-blueprint.cjs <plan-id> planFile，获取计划文件的绝对路径。传入其他字段名则输出相应字段。

如果脚本以非零状态退出，将其标准错误内容展示给用户，并停止工作流。 不要猜测其他 ID。

2. 加载项目上下文

按以下顺序读取这些文件：

• <root>/config/STRIKETHROO.md — 项目和目录约定。
• 步骤 1 返回路径中的计划正文 — 规定必须包含哪些任务。
• <root>/config/templates/TASK_TEMPLATE.md — 每个任务文件都必须符合的架构。
• <root>/config/shared/anti-rationalization.md — 在步骤 3 中应用。

3. 分析并拆解计划

通读整个计划。找出所有明确列出的具体交付物。 仅在确有必要时，将每项交付物拆解为原子任务。

任务精简（强制）：

• 只创建必要的最少数量的任务。以相较全面任务清单减少 20–30% 为目标，逐一审视每个候选任务是否必要。
• 每项任务都必须对应一项明确要求，不能是锦上添花、“最佳实践”或计划未提及的未来扩展需求。
• 每项任务的用途必须独特且互不重叠。
• 将错误处理纳入负责其所保护行为的任务中。

将 <root>/config/shared/anti-rationalization.md 中的规则应用于以下合理化对照表：

你发现自己在想……	约束规则
“多加一个任务也没关系。”	这会违反 20–30% 的精简目标。每项任务都必须追溯到一项明确列出的交付物，否则就不能创建。
“这个边界情况值得单独设一个任务。”	将其纳入负责该行为的任务中。不要把非常小的操作拆成独立单元。
“为求稳妥，我会添加一套测试。”	为简单功能编写全面测试属于过度设计。遵循测试原则，只编写有意义的测试。
“为了未来可扩展性，应该创建这个任务。”	YAGNI。计划没有提到，就不属于任务。

4. 应用粒度和技能规则

每项任务必须：

• 单一用途 — 只有一个明确的交付物。
• 原子性 — 无法再有意义地拆分。
• 技能明确 — 可由具备 1–2 项技术技能的 Agent 执行。
• 可验证 — 验收标准必须包含至少一个具体、可运行的验证步骤（带预期输出的命令，或其他可观察信号）。绝不能只写模糊的“正常运行”。

根据任务的技术要求，以 kebab-case 推断技能。单一领域的任务使用一项技能，互补领域的任务使用两项技能，例如 ["api-endpoints", "database"]。需要三项或以上技能的任务必须进一步拆解。

5. 测试原则：“少量测试，以集成为主”

编写以下内容的测试：

• 自定义业务逻辑和算法。
• 关键用户工作流和数据转换。
• 核心功能中的边界情况和错误条件。
• 组件之间的集成点。
• 复杂的验证或计算逻辑。

不要为以下内容编写测试：

• 第三方库和框架的功能。
• 不含自定义逻辑的简单 CRUD。
• 琐碎的 getter/setter 和静态配置。
• 如果不正确就会立即暴露的显而易见功能。

将相关测试场景合并为一个任务（“测试用户身份验证流程”，而不是分别为登录、登出和验证创建任务）。优先覆盖集成场景和关键路径，而不是为每个方法编写单元测试。绝不要为每项 CRUD 操作单独创建测试任务。

将这些规则复制到你创建的每个测试任务的“Implementation Notes”中。

6. 依赖关系分析

当任务 B 需要任务 A 的输出或产物、会修改任务 A 创建的代码，或会测试任务 A 实现的功能时，任务 B 依赖于任务 A。如果任务 B 必须等任务 A 完成后才能开始，则记录为硬依赖；如果任务 B 只是能在任务 A 完成后更顺利地执行，则记录为软依赖。验证最终依赖图无环。

7. 复杂度分析

对于每个候选任务，在写入任何文件前，分配一个 complexity_score（整数，范围为 1–10）。评分前先阅读 references/complexity-rubric.md；该文件定义了各分数段评判的四个维度。然后应用以下规则：

• 分数 ≥ 8 → 进一步拆分；不要原样输出。
• 分数为 6–7 → 明确或拆分；没有明确理由时不要输出。
• 验收标准含糊 → 将其明确为具体、可运行的验证步骤。
• 相邻的琐碎小任务 → 合并。

**回退规则：**拆分、明确或合并后，重新进行依赖关系分析，并为调整后的任务重新评分。最多重复三次。如果三轮后复杂度仍未解决，请停止并向用户说明阻碍。

8. 分配任务 ID

运行一次 scripts/get-next-task-id.cjs <plan-id>，获取第一个可用的任务 ID，然后在进程中递增分配其余 ID。在任务 frontmatter 的 id 字段中使用不带前导零的整数，在文件名中使用带前导零的形式。slug 根据简短的任务标题生成：仅使用小写字母、数字和连字符，合并连续连字符，并去除首尾连字符。

9. 输出任务文件

将每项任务写入：

<root>/plans/<plan-dir-name>/tasks/{padded-id}--{slug}.md

每个文件都必须符合 <root>/config/templates/TASK_TEMPLATE.md。只有在分数需要说明时才添加 complexity_notes。绝不要写入 execution_profile；该字段由路由辅助工具写入。

为正文的每个部分填写针对该任务的内容。在 “Implementation Notes” 下使用 <details> 块提供详细的实现指导，使非思考型大模型仅凭该部分就能执行任务。

10. 验证清单

在宣布任务生成完成前，确认：

• 计划中明确陈述的每项交付内容都由某个任务涵盖。
• 没有两个任务的目的重叠。
• 依赖关系构成无环图，不存在孤立或循环引用。
• 各组在整个计划中保持一致。
• 写入任务文件后，运行 scripts/validate-plan-blueprint.cjs <plan-id> complexityScoresValid。除非输出 yes，否则停止；如果输出 no，运行 scripts/validate-plan-blueprint.cjs <plan-id> invalidComplexityTasks，查看哪些文件缺少分数、分数不是整数或超出范围，修复后重新运行验证。

11. 路由任务执行

阅读 <root>/config/hooks/TASK_EXECUTION_ROUTING.md 并遵循其中的说明，同时遵循以下流程：

1. 运行 scripts/route-task-execution.cjs profiles <plan-id>。如果返回 no-config 或 disabled，则路由已关闭；跳过其余路由步骤并继续。如果返回 invalid-config，则停止并向用户说明错误；不要生成蓝图。
2. 为计划 tasks/ 目录中的每项任务分配一个且仅一个已配置的配置文件名称。根据当前上下文已有的内容，对本次生成的任务进行分类。如果计划中包含早前生成的任务文件，则阅读这些文件并进行分类。
3. 将完整的任务 ID 到配置文件名称映射写入临时文件，例如 {"1": "routine", "2": "demanding"}。
4. 运行 scripts/route-task-execution.cjs apply <plan-id> <mapping-file>。目标选择将在之后的任务派发时进行，绝不能在生成阶段进行。
5. 如果返回 routed，删除临时映射文件并继续。如果返回任何失败结果（invalid-assignments、invalid-tasks、routing-failure、infrastructure-failure），则停止并向用户说明 JSON 错误。绝不要在任务仅部分完成路由时继续生成蓝图。

绝不要在任务 frontmatter 或正文中手动写入具体的执行目标。

12. 运行 POST_TASK_GENERATION_ALL 钩子

阅读 <root>/config/hooks/POST_TASK_GENERATION_ALL.md 并遵循其中的说明，使用 <root>/config/templates/BLUEPRINT_TEMPLATE.md 作为执行蓝图的结构。仅在路由成功或报告路由已关闭后运行该钩子。

步骤 3：蓝图执行

使用步骤 1 中的计划 ID：

1. 解析计划

运行 scripts/validate-plan-blueprint.cjs <plan-id> planFile，其中 planFile 是计划文件的绝对路径。指定其他字段名则会打印该字段。

如果脚本以非零状态码退出，将其 stderr 呈现给用户，并停止工作流。 不要猜测其他 ID。

运行 scripts/validate-plan-blueprint.cjs <plan-id> planDir，并将打印出的路径作为 <plan-dir>。

2. 验证任务和执行蓝图是否存在

运行 scripts/validate-plan-blueprint.cjs <plan-id> taskCount 和 scripts/validate-plan-blueprint.cjs <plan-id> blueprintExists。

3. 缺少任务或执行蓝图时自动生成

如果 taskCount 为 0，或 blueprintExists 为 no：

通知用户：“未找到任务或执行蓝图。正在自动生成任务……”

• 针对此计划 ID，执行第 2 步中的完整任务生成流程。
• 重新运行 planFile、planDir、taskCount 和 blueprintExists 查询，以刷新解析后的路径和数量。

如果计划仍然没有任务或执行蓝图，则停止并报告失败。

4. 可选：创建功能分支

在执行阶段前，运行一次 scripts/create-feature-branch.cjs <plan-id>。跳过不算失败。继续使用当前分支，绝不要手动创建分支。只有仓库根目录下 .ai/strikethroo 子树中的未提交或未跟踪更改才被允许。若返回错误结果，则停止执行并报告。

然后运行一次 scripts/capture-base-commit.cjs <plan-id>，记录审查门禁用于对比的提交。若结果为 skipped，则继续执行，且审查门禁将跳过。只有结果为 error 时才停止。

5. 加载项目上下文和执行蓝图

按顺序读取以下文件：

• <root>/config/STRIKETHROO.md
• 第 1 步中路径所指向的计划文档，包括其中定义阶段分组和任务派发顺序的 Execution Blueprint 部分。
• <root>/config/shared/verification-gate.md 和 <root>/config/shared/anti-rationalization.md；下文的阶段循环中需应用这两个文件。

6. 按顺序执行各阶段

使用内部任务或待办事项跟踪器监控进度。对于 Execution Blueprint 中定义的每个阶段：

6a. 阶段执行前

运行 scripts/check-phase-readiness.cjs <plan-id> <phase-number>。如果脚本以非零状态码退出，则停止该阶段，并在继续之前报告阻塞问题。

读取 <root>/config/hooks/PRE_PHASE.md，并在开始该阶段前执行其中的指示。

6b. 任务分派

确定此阶段中所有依赖项均已满足的待执行任务。在分派任务前，阅读 <root>/config/hooks/PRE_TASK_ASSIGNMENT.md 并按照其中的说明选择 Agent。

先解析每个选定任务的执行路线。对每个选定任务各调用一个解析器，并在一次并行工具操作中同时调用：

scripts/dispatch-task-execution.cjs resolve <task-file> <current-harness> <workspace> <plan-id> <task-id>

解析器不会启动外部进程。解读所有路线结果后，在一次并行工具操作中同时发起所有外部执行和所有子 Agent。外部执行使用：

scripts/dispatch-task-execution.cjs execute <handoff> <task-file> <current-harness> <workspace> <plan-id> <task-id>

<current-harness> 是运行此技能的受支持运行环境的确切标识符；<workspace> 是项目工作目录。

解读单行 JSON 结果，并严格按照 kind 执行一次操作：

kind	必须执行的操作
native-default	直接分派，不添加任何执行设置说明。
native-override	直接分派，并明确要求使用返回的确切 model。仅当存在 reasoningEffort 属性时，才要求使用返回的 reasoningEffort。
external-override	使用返回的 handoff 运行 execute 命令，然后根据同一张表处理其结果。
fallback	未启动任何任务。明确记录返回的 reason 和 detail，然后直接分派，不添加任何执行设置说明。
launched-success	外部进程已成功退出（退出码为 0）。不要直接分派；像审核本机 Agent 一样审核状态和证据。
launched-failure	任务失败。将其状态设为 failed，并运行 <root>/config/hooks/POST_ERROR_DETECTION.md。切勿改为本机重试。
infrastructure-failure	按照上一行的规定处理。

交接规则：

• 对每个任务传入解析器返回的完全一致的、不透明的 handoff 字符串。切勿重新构造。
• 切勿将一个任务的 handoff 用于另一个任务，也不要在启动任务后重新解析路线。

同时部署所有剩余的本机子 Agent。每个子 Agent 在开始任何实现工作前，都必须阅读并执行 <root>/config/hooks/PRE_TASK_EXECUTION.md，然后执行任务并更新状态。不要运行 scripts/check-for-updates.cjs；受委派的工作者不会处理更新通知。

6c. 阶段完成验证

确保阶段中的每项任务状态均为 completed，并收集其输出。不要将子 Agent 声称成功的报告视为证据。标记阶段完成前，应用 <root>/config/shared/verification-gate.md 中的证据关卡。

6d. 阶段执行后处理

阅读 <root>/config/hooks/POST_PHASE.md 并执行其中的说明。此钩子成功前，不要进入下一阶段。

在计划的 Execution Blueprint 部分中，将阶段状态更新为 completed。

对下一阶段重复上述步骤，直到所有阶段均已完成。

对以下合理化表应用 <root>/config/shared/anti-rationalization.md：

你发现自己在想……	约束规则
“子 Agent 报告成功了，所以任务已完成。”	报告只是声明，不是证据。将阶段标记为完成前，应用验证关卡。
“测试大概能通过。”	“大概”是危险信号。运行用于验证的命令，阅读其输出和退出码，然后陈述结果。
“我会在下一阶段之后再验证。”	只有 POST_PHASE.md 已基于已验证的证据成功执行，阶段才算完成。现在就验证；不要在阶段未经验证时继续推进。

7. 执行后验证

阅读 <root>/config/hooks/POST_EXECUTION.md 并执行其中的说明。如果验证失败，立即停止执行。计划将保留在 plans/ 中以供调试。

在宣布执行完成前，对计划的 Success Criteria 和 Self Validation 步骤应用 <root>/config/shared/verification-gate.md 中的证据关卡。

运行代码审查门禁

POST_EXECUTION.md 报告通过后，遵循 st-code-review 技能并运行其捆绑机制：

code-review.cjs <plan-id> <current-harness>

从 st-code-review 技能的同级 scripts 目录中解析 code-review.cjs，并传入运行此技能的确切受支持的测试框架标识符。如果未安装 st-code-review 技能，请在执行摘要中记录该情况，然后继续生成摘要并归档。

按以下顺序处理它在标准输出中打印的单行 JSON：

1. 将其原样复制到执行摘要的审查结果中。不要重新格式化，也不要省略字段。将 codeReview 原样复制到终端代码审查条目中。
2. 遵循其顶层 action。如果是 halt，则停止，报告顶层 detail，并输出包含审查结果的终端执行摘要。如果是 continue，则继续生成执行摘要并归档。
3. 仅当 verdict.kind 为 review-recorded 时，读取 <plan-dir>/review/review.xml 和 <plan-dir>/review/findings.json，然后决定采取哪些发现的措施。severity 和 confidence 是供参考的标签，不是指令。

绝不要将未经认证的审查报告为通过。

硬性规则：

• 审查只运行一次。不要为了验证修复而重新运行门禁。
• 检测使用审查者路线。每项修复都通过实施者路线执行；审查者不负责修复其发现的问题。
• 进行任何修复后，必须完整重新运行 POST_EXECUTION.md，然后才能声明执行完成。之前的通过结果不再适用。

8. 附加执行摘要

在计划文档中附加执行摘要部分，并填写 <root>/config/templates/EXECUTION_SUMMARY_TEMPLATE.md 中的每个字段。根据结果中的 codeReview 字段添加代码审查条目；如果未生成结果，则标记为失败并说明原因。在重要事件下，始终原样记录审查门禁的 JSON 行，然后说明采取了哪些发现的措施、忽略了哪些发现及其原因。

9. 归档计划

将已完成的计划目录从 <root>/plans/<plan-folder> 移至 <root>/archive/<plan-folder>，并保留整个文件夹结构。如果移动失败，记录错误，但不要因此判定整体执行失败。

失败模式

• 步骤 1 分配的 ID 对应的计划目录已存在。 重新运行下一个计划 ID 脚本并重试一次。如果冲突仍然存在，则停止并报告。
• 执行错误。 如果某项任务失败，读取 <root>/config/hooks/POST_ERROR_DETECTION.md，在重要事件中记录错误，停止当前阶段，并在继续前请求用户指示。

执行摘要

最后输出且仅输出以下区块（如有保留的更新通知，则另行附加）：

---
Execution Summary:
- Plan ID: [numeric-id]
- Status: [Archived or Halted]
- Location: [absolute path to current plan directory]
- Code Review: [codeReview from the review result, or Failed with the reason no result was produced]
---

即使审查门禁停止执行，也要输出此区块。使用实际状态和位置；停止后绝不要声称已归档。复制 codeReview 时，不得遗漏测试框架、模型信息或拒绝原因。已采取发现的措施不会将 Address 变为 Pass，因为审查不会重新运行。如果执行在审查前停止，则报告 Failed，并附上 "Review was not run" 和阻止执行的原因。

下游自动化将读取此摘要；格式必须准确。

如果存在保留的更新 notice，则在结构化摘要区块之后，或在此技能不输出摘要区块时，在最终回复之后附加该确切句子。通知之后不得有任何内容。