技能介绍

问题从哪来

复杂改动里，单 Agent 从需求写到合并，常见问题不是「写不出来」，而是改 A 时不知道 B/C 会不会被带崩：跨模块调用链、鉴权/支付/破坏性 API、重构拆文件或改接口签名时，靠「看过一遍」很难当验收标准。

本 Skill 的定位是工程治理——不是多堆几个能力插件，而是把交付变成可检查的流程：结构化拆解、模块化实现、对抗验证、集成验收。

怎么跑起来

触发判断可以记成一句：上线出问题，是只坏自己，还是会连坐别的模块？ 跨模块、安全敏感、重构改契约、或你不够熟悉这块代码时，应加载；单文件小改、文档/配置、纯问答则不必。

流程上是层次式编排：主 Agent 当编排者做 Phase Gate，不写实现代码；Subagent A（架构师）产出 module contract 并创建 Subagent B；每个模块一个 Subagent B 走 PEV（Plan–Execute–Verify），在共享基板上落地；Subagent C 做集成对齐检查；安全侧由第三方 cli C 做双轮对抗审查。

硬约束只有一条但不可绕过：测试必须由 cli A 执行，主 Agent 直写或 Subagent B 实现后都要子进程调 cli A 跑回归，内联「我觉得没问题」不算过关。

产物走 templates/ 标准模板落到约定路径（如 run/artifacts/task-spec.md、run/contracts/{module}.md），配合 policies/ 里的风险分级、Gate、文件安全策略；失败轨迹写入 run/state/failure-traces.jsonl 便于归因（cli B）。

边界与代价

轻量路径：边界清晰、单模块、低风险且有足够上下文时，可只做「实现 + cli A + 审查决策」。
完整六 Phase：跨模块、RED/YELLOW 风险、需要并行多实现或交接记录时走全流程。
嵌套 Subagent A 本身是一次高成本调用；主会话请求密度高时可能撞上平台 429，可退避重试、改轻量路径，或为 Subagent A 用独立 API key 避免与主 Agent 共用一个限流桶。