القائمة
在当前会话中执行包含若干独立任务的实现计划时使用
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Kimi WebBridge lets AI control the user's real browser — navigate, click, type, read, screenshot, and interact with any website using the user's actual login sessions. Use this skill whenever the user wants to interact with websites, automate browser tasks, scrape web content, or perform any action requiring a real browser. Also use when the user mentions "browser", "webpage", "open URL", "screenshot", or asks to read/interact with any website. Use even for simple-sounding browser requests — the daemon handles all complexity.
对 PostgreSQL 数据库执行只读检查时使用。优先读 doc/db/quick-guide 匹配场景，表结构按需 docker exec psql 查询；查库后评估是否沉淀 quick-guide。触发词：查数据库、检查表、行数、数据覆盖、schema、docker exec psql、DB 状态、doc/db、快捷检索指南、quick-guide。
在进行任何创意性工作之前必须使用此技能 — 创建功能、构建组件、添加功能、实现需求或修改行为。在实现前探索用户意图、需求和设计。用户说"头脑风暴"或类似的表达时，应触发此技能。
调用 DeepSeek API（/chat/completions）的强制查阅规范，覆盖思考模式（reasoning_content / thinking / reasoning_effort）与多轮对话上下文拼接。**任何**涉及 DeepSeek API 的代码编写、修改、排错前必须先调用本 skill。触发词：DeepSeek、deepseek、deepseek-v4-pro、reasoning_content、思考模式、thinking mode、reasoning_effort、deepseek 多轮、deepseek chat completions、api.deepseek.com。
当面临 2 个以上可独立执行、无共享状态或顺序依赖的任务时使用
手动触发
| name | subagent-driven-development |
| description | 在当前会话中执行包含若干独立任务的实现计划时使用 |
按计划执行：把任务按依赖与文件交集划成批次，同一批次内不相交的任务并行派发子代理；每个任务完成后由一个审查者一次性审查 spec 合规 + 代码质量。
为什么用子代理： 你把任务委派给上下文隔离的专职代理。通过精确地构造它们的指令与上下文，你确保它们专注且能完成任务。它们绝不应继承你会话的上下文或历史——你只为它们构造它们真正需要的东西。这同时也为你自己保留了用于协调工作的上下文。
核心原则： 不相交任务并行派发 + 单一审查者（一次覆盖 spec 合规与代码质量）= 高质量、快迭代
digraph when_to_use {
"已有实现计划？" [shape=diamond];
"任务大体独立？" [shape=diamond];
"留在当前会话？" [shape=diamond];
"subagent-driven-development" [shape=box];
"executing-plans" [shape=box];
"手动执行或先头脑风暴" [shape=box];
"已有实现计划？" -> "任务大体独立？" [label="是"];
"已有实现计划？" -> "手动执行或先头脑风暴" [label="否"];
"任务大体独立？" -> "留在当前会话？" [label="是"];
"任务大体独立？" -> "手动执行或先头脑风暴" [label="否 - 紧耦合"];
"留在当前会话？" -> "subagent-driven-development" [label="是"];
"留在当前会话？" -> "executing-plans" [label="否 - 并行会话"];
}
对比 Executing Plans（并行会话）：
并行的前提是任务不相交。开工前先把计划里的全部任务分成若干批次：
两个任务可放进同一批次（可并行）当且仅当：
不满足任一条件的任务排到后续批次（批次之间串行）。一个批次的所有任务都验收通过后，再开下一个批次（下一批次可依赖上一批次的产物）。
并行验证命令安全： 会清空并重写产物目录的构建命令（各语言生态的 build，输出到 dist//build//target/ 等）是隐性共享文件集——两个 subagent 并发跑同一个 build 会互相损坏产物（一个清理目录时另一个在写入，产出不可预测）。因此并行 implementer 的验证步骤只用：
build 由控制者在批次末统一跑一次，不放进并行 implementer 的验证。写任务卡时，对同一批次内的并行任务，"验证"段落只用"只读检查 + 隔离测试"，不要写会重写产物目录的构建命令。串行批次（单个 implementer）则不受此限，可照常 build。
非代码产物的验证盲区： 单元测试只覆盖代码逻辑。数据库迁移 SQL / shell 脚本 / 配置文件 / 模板等产物，单元测试完全碰不到——SQL 语法错误、表名/外键冲突、脚本路径错误、模板字符编码问题，只有实际执行或专门校验才能暴露。涉及这类产物的任务，任务卡的"验证"段落不能只写单元测试，必须额外包含产物本身的正确性验证：
bash -n、PowerShell 的 [scriptblock]::Create）或实际执行控制者验收这类任务时，要确认 implementer 不只是"单元测试通过"，还验证了非代码产物本身。
并行提交的 git 安全： 同一分支上多个 implementer 并发提交会抢占 git 索引。做法固定一种：令并行 implementer 只实现 + 测试、不提交，由控制者在批次结束后按任务逐个提交其不相交的文件集。
禁止用 git worktree 隔离（即调用 Agent 工具时不要传 isolation: "worktree"）：worktree 子目录常被依赖目录（如 node_modules、.venv、target 等）的文件锁占用，git worktree remove 经常失败、留下顽固残留，还要额外把改动 patch 回主分支。冲突应靠"按不相交文件域切批次"从源头避免，而非靠 worktree 物理隔离。唯一例外：agent 必须执行破坏性操作（git reset --hard、大范围分支重写）时才考虑 worktree。
拿不准两个任务是否真不相交时，当作相交、排进不同批次——错误的并行会制造冲突，代价远高于少一点并行度。
单任务工作量上限： 派发前预估每个任务的工作量。即使一个任务和别的任务不相交，若它会创建/删除/重写大量文件（例如批量删除 >30 个文件、重写一整个模块、生成大量样板代码），也应提前拆成多个子任务（串行或并行），而非塞给单个 subagent——单个 subagent 上下文膨胀会导致它读不全文件、遗漏边界、自审失真。经验阈值：单任务改动文件数 >20，或净增/删行数 >1000 时，考虑拆分。任务过大时 subagent 往往会自己 BLOCKED 上报，但提前拆分比事后补救代价更低——控制者在划分批次阶段就应识别这类大任务。
digraph process {
rankdir=TB;
"读取计划，提取所有任务全文+上下文，按依赖与文件交集划分批次，创建 TodoWrite" [shape=box];
"还有剩余批次？" [shape=diamond];
subgraph cluster_per_wave {
label="每个批次（批次内任务并行）";
"并行派发本批次各 implementer 子代理 (./implementer-prompt.md)" [shape=box];
"某 implementer 有疑问？" [shape=diamond];
"回答疑问、提供上下文" [shape=box];
"各 implementer 实现、测试、自审（不提交，控制者批次末按序提交）" [shape=box];
"对每个完成的任务派发审查者子代理 (./reviewer-prompt.md)" [shape=box];
"审查者通过（spec 合规 且 代码质量）？" [shape=diamond];
"对应 implementer 修复（spec 缺口优先于质量问题）" [shape=box];
"在 TodoWrite 中标记本批次任务完成" [shape=box];
}
"为整个实现派发最终代码审查者子代理" [shape=box];
"使用 superpowers:finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];
"读取计划，提取所有任务全文+上下文，按依赖与文件交集划分批次，创建 TodoWrite" -> "还有剩余批次？";
"还有剩余批次？" -> "并行派发本批次各 implementer 子代理 (./implementer-prompt.md)" [label="是"];
"并行派发本批次各 implementer 子代理 (./implementer-prompt.md)" -> "某 implementer 有疑问？";
"某 implementer 有疑问？" -> "回答疑问、提供上下文" [label="是"];
"回答疑问、提供上下文" -> "并行派发本批次各 implementer 子代理 (./implementer-prompt.md)" [label="重新派发该 implementer"];
"某 implementer 有疑问？" -> "各 implementer 实现、测试、自审（不提交，控制者批次末按序提交）" [label="否"];
"各 implementer 实现、测试、自审（不提交，控制者批次末按序提交）" -> "对每个完成的任务派发审查者子代理 (./reviewer-prompt.md)";
"对每个完成的任务派发审查者子代理 (./reviewer-prompt.md)" -> "审查者通过（spec 合规 且 代码质量）？";
"审查者通过（spec 合规 且 代码质量）？" -> "对应 implementer 修复（spec 缺口优先于质量问题）" [label="否"];
"对应 implementer 修复（spec 缺口优先于质量问题）" -> "对每个完成的任务派发审查者子代理 (./reviewer-prompt.md)" [label="重新审查"];
"审查者通过（spec 合规 且 代码质量）？" -> "在 TodoWrite 中标记本批次任务完成" [label="是"];
"在 TodoWrite 中标记本批次任务完成" -> "还有剩余批次？";
"还有剩余批次？" -> "控制者跑完整 build + 全套测试套件（抓跨任务集成问题）" [label="否"];
"控制者跑完整 build + 全套测试套件（抓跨任务集成问题）" -> "为整个实现派发最终代码审查者子代理" [label="通过"];
"为整个实现派发最终代码审查者子代理" -> "使用 superpowers:finishing-a-development-branch";
}
每个任务的审查彼此独立，因此同一批次的审查者也可并行派发（一个任务一个审查者）。某任务通过验收即可标记完成，无需等批次内其他任务。
最终验证（所有批次完成后、最终审查前，由控制者亲自跑）： 单任务审查只看本任务的 spec 合规与代码质量，跨任务的集成问题（模块 import 路径错、类型不匹配、新组件未在框架中注册、路由/接线漏挂）没有任何单任务闸门能抓到。因此所有批次完成、派发最终代码审查者之前，控制者必须单线程跑一次完整构建 + 全套测试套件（不是派给并行 subagent）：
全绿后再派发最终代码审查者。若构建/测试失败，失败点通常指向某个任务的隐性集成缺口——修完重跑，全绿才进入 finishing。不要把这一步省略或交给某个 subagent，它是整个实现唯一的跨任务集成闸门。
在每个角色上使用能胜任的最弱模型，以节省成本、提升速度。
机械性实现任务（孤立函数、清晰的 spec、1-2 个文件）：用又快又便宜的模型。当计划写得足够明确时，大多数实现任务都是机械性的。
集成与判断类任务（多文件协调、模式匹配、调试）：用标准模型。
架构、设计与审查类任务：用现有最强的模型。
任务复杂度信号：
implementer 子代理会报告四种状态之一。分别妥善处理：
DONE： 进入审查（一个审查者覆盖 spec 合规 + 代码质量）。
DONE_WITH_CONCERNS： implementer 完成了工作，但标记了疑虑。在继续之前先读这些疑虑。如果疑虑关乎正确性或范围，先解决再审查。如果只是观察（例如"这个文件变大了"），记录下来并继续审查。
NEEDS_CONTEXT： implementer 需要未提供的信息。补齐缺失的上下文并重新派发。
BLOCKED： implementer 无法完成任务。评估阻塞点：
绝不要忽视上报，也不要在不做任何改变的情况下强迫同一模型重试。如果 implementer 说它卡住了，那就一定有东西需要改变。
并行批次中，逐个处理各 implementer 的状态：DONE 的任务可立即进入审查，无需等同批次其他任务收尾。
./implementer-prompt.md - 派发 implementer 子代理./reviewer-prompt.md - 派发审查者子代理（一次覆盖 spec 合规 + 代码质量）绝不要：
git worktree remove 失败、残留难清；仅破坏性操作例外）如果子代理提问：
如果审查者发现问题：
如果子代理任务失败：