Skill v1.0.0

name: 智能体闭环开发 description: Use when 必须使用——每当用户提出任何需要创建、修改或删除代码/文件的请求，或发现 bug 需要修复时，无论请求多简短、多隐含、是否在对话中途随口提出，都必须在做任何其他事情之前首先调用本 skill metadata: version: "1.0.0"

触发

• 必须触发：创建/修改/删除代码或文件、加功能、重构、新增、改写；发现 bug 需修复；对话中途随口提出的产出需求；"继续/接着做"（本 skill 已触发且任务未完成时）。
• 不触发：纯问答、文件阅读/搜索、纯格式化/注释、闲聊不写代码、纯根因排查（只查不修，走 root-cause-analysis）、纯文稿写作（由当前智能体直接完成，不再设专门技能）。

协作语义与等待纪律（硬规则）

• L3 只用于大型、长程任务：把一个超大任务切成若干相互独立的部分，模仿真人团队「各自独立工作 → 沟通 → 整合」；每个 member ≈ 一个 L2（端到端做完自己那份再整合）。不要因为“任务大”就建团——要因为“需要持续负责人与并行独立交付”才建团。
• member 之间可直接沟通：任务切分不可能一开始就完美，执行中会出现交叉、重叠、接口变化；member 之间直接协商比“上报 leader 再转发”高效。leader 只在边界冲突需裁决、目标变更、验收标准修改时介入；改了交付边界同步 leader（记录在案），不必阻塞等批准。
• member ≠ leaf：leaf 寿命绑定单个任务、只与派发者沟通、任务完成即结束；member 长期存在（睡眠/随时唤醒复用），管一个领域、可跨任务复用、可直接与其它 member/leader 沟通。
• 等待纪律（硬规则）：本 skill 涉及长命令 / 测试 / 构建 / 网络请求时，≥30 秒一律放后台任务或派 leaf，本回合内不等待（不轮询、不 sleep、不反复检查同一任务）；结果靠二次唤醒取。leader 与 member 都不阻塞。

目标

每次开发走完整闭环：需求理解 → 计划制定 → 执行实现 → 真实验证 → 问题循环。禁止跳步、禁止伪验证（仅跑单测）、禁止发现问题后不回头修复。

前置：项目上下文与开工门禁

若项目根存在 `docs/GOAL.md`（即已建立新文档体系）：

1. 先调 skill(name="myworkflow-project-maintain")，读 GOAL 确认开发本意、读 STATE 了解当前进度、读 docs/design/index.json 定位本次改动对应的 design 点。
2. 过下面的开工门禁：

□ 本次改动是否对应 docs/design/index.json 中的某个点？
  ├─ 是 → 记下点编号，开工
  ├─ 否，且性质是「新增功能 / 行为变更 / 新模块」 → 🚫 硬门禁：先补齐 design，未生成不得开工
  └─ 否，且性质是「bug 修复 / 重构 / 配置 / 文档 / 格式化」 → 允许跳过 design，
     但必须在 PROGRESS 条目里标注 [Debug]/[Change] 并写明"本次无 design（小场景豁免）"

豁免不适用于：新增功能、行为变更、新增模块、接口变更、影响 ≥2 个模块的修改——这些必须先生成 design。

判断不清时的默认：按"需要 design"处理。

若项目没有 `docs/` 体系：跳过本节，直接走下面的 5 阶段。

design 的补齐与 index.json 的写入由 project-maintain 执行，本 skill 不直接改 `index.json`。

主线（5 阶段，不可跳）

阶段 1：需求理解

读 CLAUDE.md 与相关代码（有 docs/ 体系时另读 GOAL 与本次的 design 点）；复述核心目标/输入/输出/约束；模糊点用 ask_user_question 追问——每个问题都要能改变后续做法，一律用 ask_user_question 而非纯文本；复杂或意图不明 → skill(name="myworkflow-req-clarify")。确认后进阶段 2。

阶段 2：计划制定

产出分步清单 + 验证方案（以用户身份验证，不写"跑测试"）+ 风险点。跨文件或 ≥2 独立模块 → 计划头标注工作级别：L1 单智能体（单一不可分交付物/单文件小改）直接做；L2 子智能体（≥2 个平铺、无依赖小交付物）用 subagent 平铺派发、每件端到端；L3 团队（多域、交付物有接口/依赖、需持续负责人）走 task-dispatch 下 mission。展示计划获批准后进阶段 3。

阶段 3：执行实现

1. 按级别拆解执行：L1 直接实现；L2 按可独立验收的小交付平铺、每件一个执行者端到端做完；L3 按交付物横切、每个交付物一个 owner（skill(name="myworkflow-task-dispatch")），禁止把同一交付物按阶段拆窗口/接力。全部回收后 skill(name="myworkflow-integration-verify") 验证跨交付物接口合规。
2. TDD（新增/修改逻辑必须；文档/配置/静态资源跳过）：先写失败测试 → 最小实现 → 重构。写测试前对照 [references/testing-anti-patterns.md] 的 5 条反模式与 Mock 铁律自检。
3. 遇到 bug 不盲目改：调 skill(name="myworkflow-root-cause-analysis") 定位根因（只查不修）→ 按报告根因修复 → 继续。
4. 自检：计划步骤全完成、TDD 全绿、无语法/import 错误。

阶段 4：真实验证（硬门禁）

1. 前置：阶段 3 所有 TDD 全绿；有失败回阶段 3 补完。
2. 调用 skill(name="myworkflow-real-world-verify")，传入：项目根目录/类型、变更概要、启动命令、测试命令、关键用户路径（≥5 条）。
3. 核心原则：TDD 全过 ≠ 功能完成。 TDD 测"代码按预期运行"，真实验证测"用户按预期使用"，缺一不可。

阶段 5：判断与循环

验证全过 → 完成
有 ❌ → 小（几行可修）→ 回阶段3；中（动设计不改需求）→ 回阶段2；大（方向根本错）→ 回阶段1

每个 ❌ 必须处理，不允许降级跳过；≤3 轮完整循环，3 轮后仍有问题 → 停下上报用户。

后置步骤

1. 报告验证结果与产物。
2. 同步项目文档：项目有 docs/ 体系 → skill(name="myworkflow-project-maintain") 走完成时流程（写 PROGRESS 条目、更新版本号（仅当项目有明确版本策略或用户要求时；单次改动默认不改版本号——版本号属于用户/项目策略，智能体不擅自递增）、把 design 点置为「待验收」、刷新 STATE、校验 index）。点状态只能由 project-maintain 置为「待验收」，「完成」只能由用户确认后置位。
3. 提交远程（commit/PR/merge）→ skill(name="myworkflow-github-collab")。

完成标志

• [ ] 需求已确认、计划已批准
• [ ] 开工门禁已过（有 design 点，或已记录小场景豁免）
• [ ] 代码按计划产出（按级别交付：L1 直接完成 / L2 子智能体平铺回收 / L3 团队 owner 交付；跨交付物已集成验证）
• [ ] 阶段 4 真实验证完成（happy path + 边界 + 回归）
• [ ] 所有 ❌ 已循环修复（≤3 轮）
• [ ] 项目文档已同步（有 docs/ 体系时）
• [ ] 结果已报告用户

证据口径映射（与 myworkflow-subagent-protocol 一致，不重复其长段）

• produced（回执）：代码/补丁已产出并交回（产物路径 + 改动摘要）；只有路径不算完成。
• verified（可复核证据）：真实命令 + exit code + 产物路径/sha256（有 runId 时写 runId）；超时、无输出、非空文件都不算证据。
• accepted（owner 验收）：上面「完成标志」清单逐条核对证据后才算完成；idle / 超时 / 非空 completion.md 都不是完成。
• L1 由当前上下文自证；L2 子智能体各自交回后由派发方复核；L3 由该交付物 owner 验收、leader 只裁量。

元使用：审计模式

任务为审计/优化 skill 时：明确审计目标与维度 → L2 用 fresh 只读子智能体做审计（作者盲区只有新鲜视角能发现；≥2 维度或需持续负责人 → 升级 L3 团队，由 leader 定审计边界）→ 读报告，P0/P1 各项 = 验证场景 → 自动循环修复，P0/P1/P2 全部清零才停止（≤3 轮）。

续接与恢复（进行中 / 被中断 / 失败后）

续接入口（触发）：用户说「继续 / 接着做 / 下一步 / 恢复到哪了」、出现压缩摘要、重启 / 换会话 / 被二次唤醒、同一任务重试、别人交回半成品时——先进入本节，不从头开始。

• R1 先对账，再动手：先用可核查证据确认进度——读交付物、运行记录（任务清单 / verification 报告 / completion 回执）、状态文件、上一轮证据；禁止凭对话记忆假设「应该做完了」。对不出结论时先做只读探查，不猜。
• R2 三级状态判定（沿用 produced / verified / accepted）：已 accepted → 跳过、不重做；已 produced 未 verified → 补验证 / 补证据，不重做产物；尚未开始 → 按正常流程做；判不清 → 按「未完成」处理并先探查。
• R3 只推进「最小下一步」：续接不是重跑整条流程——找出下一个未完成的独立交付物，只做它；做完再判下一步。
• R4 需求漂移先确认：新指令若改变目标 / 范围 / 验收标准 → 先确认再重排，不硬续旧计划、不静默改范围。
• R5 失败后续接：同一种失败不得重复：记录已试路径与错误指纹（同命令 + 同输入 + 同版本），换方法 / 降级 / 上报，并在记录里写明「这次为什么与上次不同」。
• R6 中断恢复（压缩 / 重启 / 换会话）：从磁盘事实（交付物、状态文件、运行记录、团队状态）重建进度，不依赖对话记忆。
• R7 交接四样（给 / 要都必须齐）：已做 / 未做 / 证据（含 runId 或产物路径）/ 下一步 + 未解决项；接手方先复核再动手。
• R8 恢复后先判级并加载技能：重新确认任务级别、加载对应技能后再动手（每轮纪律照常生效）。
• 与 5 阶段主线衔接：续接不跳阶段 4 真实验证门禁；已完成且 accepted 的部分不重做，未验证的补证据；禁止从阶段 1 重开已推进的任务。

证据纪律（反臆测 E1–E6）

生产侧（阶段 1 需求理解、阶段 3 执行实现）硬约束，逐条自查：

• E1 证据优先：写代码 / 改文件前先读源码，核实接口、字段、参数、行为、版本；不凭记忆、惯例或「通常如此」下判断。检查点：每个新引用的符号都能指出出处（文件 + 行号）。反例：没打开 src/assemble.js 就照印象写导出名。
• E2 假设显式化：拿不到证据时先写「假设（未核实）」，并立即去核实（读文件 / 跑命令 / 查文档）；禁止把假设当事实写进代码、注释、文档或计划。
• E4 自检问句：动手前先问「这条规则是我猜的，还是有出处？」无出处 → 先查再写；查不到 → 标注假设（未核实）并写明影响与核实方法。
• E5 禁止编造：不得为让输出完整而编造 API、路径、参数、版本、行号、测试结果；不确定的一律空缺并明示，不拿「应该 / 大概」当证据。

衔接：关键接口 / 字段至少两处独立来源交叉核对（源码 + 运行输出），冲突以可执行结果为准并记录（E6）；每条结论绑证据——命令 + exit code 或文件 + 行号，核实不了的写「未核实」（E3），口径与 myworkflow-subagent-protocol 回执一致。

反例自查：报告写「应该能跑」却无命令与 exit code（E3）、凭空写出行号或版本号（E5）、把惯例当字段约定（E1）——均属违规，须补读源码或补跑命令后重写。

E7 代价优先（谨慎执行）

• 改动前先评估代价与影响面：是否不可逆、影响多少文件/用户/数据、能否回滚；不确定时按高风险处理。
• 高风险（删数据、改历史、覆盖生产文件、发布、重启、大范围改动）必须先备份 + 预演/dry-run + 小步验证，并写明回滚路径。
• 检查点：汇报必须含代价评估（影响面 / 可逆性 / 回滚方式），未评估视为未完成。