st-generate-tasks

st-generate-tasks

输入

用户通过对话提供数字计划 ID。

操作流程

1. 定位 strikethroo 根目录

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

在后续每个步骤中，都将脚本打印的路径视为 <root>。

委派的执行工作线程跳过此步骤，也不发送更新通知。

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

2. 解析计划

运行 scripts/validate-plan-blueprint.cjs <plan-id> planFile，获取计划文件的绝对路径。使用其他字段名会打印对应字段。

如果脚本以非零状态退出，请停止并让用户确认计划 ID。不要猜测其他 ID。

3. 加载项目上下文

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

• <root>/config/STRIKETHROO.md — 项目和目录约定。
• 第 2 步返回路径中的计划正文 — 任务必须包含哪些内容的约定。
• <root>/config/templates/TASK_TEMPLATE.md — 每个任务文件都必须遵循的结构。
• <root>/config/shared/anti-rationalization.md — 在第 4 步中应用。

4. 分析并拆解计划

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

任务精简（强制）：

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

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

当你发现自己在想……	必须遵守的规则
“再多一个任务也无妨。”	这违反了 20–30% 的精简目标。每个任务都必须追溯到一项明确列出的交付项，否则就不应存在。
“这个边缘情况值得单独成一个任务。”	将其纳入负责该行为的任务。不要把微不足道的操作拆成独立单元。
“加个测试套件更保险。”	为简单功能编写全面测试属于过度设计。遵循测试原则，只编写有意义的测试。
“为了未来扩展，这项任务很有必要。”	YAGNI。计划未提及，就不是任务。

5. 应用粒度和技能规则

每项任务都必须：

• 单一用途 — 交付目标明确。
• 原子化 — 无法再有意义地拆分。
• 针对特定技能 — 可由具备 1–2 项技术技能的 Agent 执行。
• 可验证 — 包含明确的验收标准，其中至少有一个具体且可运行的验证步骤（命令及其预期输出，或其他可观察的信号）。绝不能满足于含糊的“正常工作”。

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

6. 测试理念：“少写测试，以集成为主”

为以下内容编写测试：

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

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

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

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

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

7. 依赖分析

当任务 B 需要任务 A 的输出或产物、修改任务 A 创建的代码，或测试任务 A 实现的功能时，任务 B 依赖任务 A。如果任务 B 在任务 A 完成之前无法开始，则将其记录为硬依赖；如果任务 B 只是有了任务 A 的结果后执行效果更好，则将其记录为软依赖。验证最终依赖图无环。

8. 复杂度分析

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

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

**回溯规则：**拆分、细化或合并后，重新进行依赖分析并重新评分调整后的任务。最多重复三次。如果三轮后复杂度仍未解决，则停止并向用户说明阻塞原因。

9. 分配任务 ID

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

10. 生成任务文件

将每个任务写入：

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

每个文件都必须符合 <root>/config/templates/TASK_TEMPLATE.md。只有在需要说明分数合理性时才添加 complexity_notes。切勿编写 execution_profile；路由辅助程序会写入该字段。

为正文的每个章节填写针对该任务的内容。在“Implementation Notes”下的 <details> 块中加入详细的实现指导，确保不具备思考能力的大模型也能仅凭该章节完成任务。

11. 验证清单

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

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

12. 路由任务执行

阅读 <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 或任务正文中手动填写具体的执行目标。

13. 运行 POST_TASK_GENERATION_ALL 钩子

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

如果存在保留的更新 notice，请将其原样追加在结构化摘要块之后；如果此技能不输出摘要块，则追加在最终回复之后。该通知之后不得再有任何内容。

失败模式

• 用户拒绝澄清阻塞性歧义。 将受影响任务的 status: "needs-clarification"，并在任务的“Implementation Notes”中记录待解决的问题。不要自行编造答案。
• 辅助脚本意外失败。 将 stderr 告知用户并停止——不要改为手动分配 ID 或查找路径。