// Use when 已有书面实施计划、任务相对独立，且在本会话内通过子代理逐任务落实时。触发场景：执行实施计划、子代理开发、按计划实现、Task 派发实现、两阶段代码审查、plan execution。
超压缩通信模式。通过去掉废话、冠词和客套语，在保持完整技术准确性的同时削减约 75% token 用量。 当用户说"caveman 模式"、"简洁模式"、"少废话"、"省 token"、"简短点"或调用 /caveman 时触发。
对用户的计划或设计进行不留情面的深度追问，直到达成共同理解，逐一解决决策树的每个分支。当用户想要压力测试计划、检验设计时触发。触发词：追问我、grill me、逐一问我、挑战我的方案、深度追问、质疑设计、设计评审追问。
将当前对话压缩为交接文档，供下一个 Agent 会话接续工作。触发词：交接、handoff、下一个会话、会话摘要、接续工作、传给下一个 agent。
在代码库中发现架构"深化"机会——将浅模块变成深模块的重构，提升可测试性和 AI 可导航性。与 architecture-advisor 互补：architecture-advisor 设计新架构，本技能改善现有代码库结构。触发词：改进代码库架构、架构深化、找重构机会、模块耦合太紧、难以测试、代码难以理解、架构改进、improve architecture、refactor opportunities。
快速验证设计的一次性原型。区分两条分支——逻辑/状态模型用终端交互 App，UI 布局用多变体路由切换。当用户想原型验证、检验数据模型或状态机、探索多种 UI 方案时触发。触发词：原型、prototype、验证方案、快速试验、让我玩一玩、试几个设计。
面试向 LLM Wiki 全流程：Raw 层在 raw/ 沉淀 _research.md、basic/、blog/（见 references/raw-layer.md）；Wiki 层只读 raw/、编译维护 wiki/（实体/概念、index、log，见 references/wiki-layer.md）。触发：建资料包、收录博客、从 raw 导入 wiki、查询、lint、面试备考知识库。关键词：LLM Wiki、raw、wiki、ingest、面试、Obsidian、知识库、用户供稿。
| name | subagent-driven-development |
| description | Use when 已有书面实施计划、任务相对独立，且在本会话内通过子代理逐任务落实时。触发场景：执行实施计划、子代理开发、按计划实现、Task 派发实现、两阶段代码审查、plan execution。 |
按书面实施计划逐任务推进：每个任务派发新的实现子代理（隔离上下文），任务完成后依次做 规格符合性审查 → 代码质量审查（顺序不可颠倒）。主会话负责读计划一次、提取任务全文、协调与决策，不把整段对话历史灌给子代理。
开场声明：「我正在使用子代理驱动开发技能执行计划。」
与「同会话逐步执行」的区别： 本技能强调每任务新子代理 + 双审查；若用户选择在当前会话手写每一步、不用 Task 派子代理，可改按 references/inline-execution-hint.md 配合 tdd-master（TDD 开发大师） 与 code-review-expert（代码审查专家），不再套用下文的 Task 模板。
code-review-expert（代码审查专家）：整体收尾审查/质量门禁debug-expert（调试专家）：实现或测试失败时切换排查writing-plans（实施计划编写） 产出），任务粒度小、相对独立。flowchart TD
A[有实施计划?] -->|否| Z[先完成方案设计与实施计划编写]
A -->|是| B[任务可独立切片?]
B -->|否| Y[收紧计划或改人工串行]
B -->|是| C[本技能: 子代理逐任务]
references/implementer-prompt.md）references/spec-reviewer-prompt.md）references/code-quality-reviewer-prompt.md，对齐 code-review-expert（代码审查专家） 的严重度与证据要求）code-review-expert（代码审查专家） 级别的汇总审查（可再派子代理），并请用户确认合并/PR；若项目后续提供「分支收尾」类技能可再衔接。实现子代理须返回以下之一：
| 状态 | 处理 |
|---|---|
| DONE | 进入规格符合性审查 |
| DONE_WITH_CONCERNS | 先阅读关切；涉及正确性/范围的先处理再审查；仅为观察性备注可记录后继续 |
| NEEDS_CONTEXT | 补充上下文后重新派发同一任务 |
| BLOCKED | 缺信息则补上下文；能力不足则换更强模型；任务过大则拆计划；计划错误则上升用户 |
禁止忽视 BLOCKED、禁止无变更重复派发同模型硬重试。
| 文件 | 用途 |
|---|---|
references/implementer-prompt.md | 实现子代理 |
references/spec-reviewer-prompt.md | 规格符合性审查（先） |
references/code-quality-reviewer-prompt.md | 代码质量审查（后） |
派发时将计划中的任务全文粘贴进提示词，并补充场景上下文（依赖、架构位置、工作目录）。
main/master 上开始改代码。| 技能 | 作用 |
|---|---|
writing-plans（实施计划编写） | 产生本技能消费的勾选式计划 |
tdd-master（TDD 开发大师） | 实现与运行测试时应遵循 RED-GREEN-REFACTOR；计划中已拆步骤时以计划为准 |
code-review-expert（代码审查专家） | 代码质量审查输出结构与严重度对齐；全量收尾可再显式调用 |
debug-expert（调试专家） | 实现或测试失败时切换排查 |
[读取计划 docs/specs/plans/xxx.md，提取任务 1–N 全文，写入 Todo]
任务 1：
→ Task: implementer（全文任务 + 上下文）
→ 实现者 DONE
→ Task: spec reviewer → ✅
→ Task: code quality reviewer → 有 Important 问题 → 实现者修复 → 再审 → ✅
→ 标记任务 1 完成
任务 2：…
全部完成后 → 可选：Task 最终审查 → 用户确认合并