Menu
任务开工前用这个 skill 评估是否需要先写 spec。触发：涉及 ≥3 模块、>30 文件改动、>10 步骤、架构级决策、或用户说「先出方案 / 先写 spec」。生成的 spec 放 workspace/specs/
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
调研开源 repo 看「可偷什么」时，用这个流程——克隆读全源、按 ROI 排清单、审视现有系统、偷抽象不偷代码、融入现有机制不做加法。Use when 用户发 GitHub 链接 + 问「可以偷师 / 借鉴什么」，或你提议要参考外部项目。
Session 收工标准 SOP——任何路径触发「收工」（reaction ✅ / 文字「收工 / wrap up / 闭包」/ cron 自动）都走同一动作链：自测 → commit（含受保护路径 override 规则）→ 清过程产物（临时 spec / debug 输出 / dry-run 文件 / 中间 patch）→ 报 commit hash + 清理清单。Use when 用户说「收工 / 闭包 / wrap up / OK 收工 / 结束这一段」，或 ✅ reaction 触发 inject 含「收工」字样。
Bug 修复 / 排查场景，连续 2 次假设或 patch 没命中根因时强制停手出 audit。Use when 同一 bug 已经试过 ≥2 次修复、症状仍在或换了形态再现、即将动「第 3 刀」时；触发关键词：「还是有这个问题」「又出现了」「同样的报错」「再试一次」「这次应该」。不适用于一次就 reproduce + 一次修好的场景。
存档目录，非可用 skill。
何时调 AskUserQuestion 工具（出 Slack Block Kit 选择卡）vs 何时直接做 / 文字反问。Use when 用户指令含「帮我看下 / 可以吗 / 你看着办 / 哪个 / 选 / 用 X 还是 Y」等歧义表达；或动作不可逆（push/删/对外发）且有多个等价方案；或同一指令有 ≥2 种合理解读且代价差异大。Skip when 自己能 grep/读文件查到、常规决策、thread 近 5 条已有就近答、cron worker。
改动开工前强制评估爆炸半径，避免「修一漏二 / 头疼医头」。Use when 改动涉及：删除文件/符号、重命名、路径迁移、接口签名变更、状态机修改、短路逻辑修正、配置 key 改名，或用户原话含「改 X / 删 X / 重命名 / 迁移 / 重构 X / 修这个 bug」+ 该 X 在多处被引用。不适用于纯新增、孤立 bugfix（无外部依赖）、文档/注释改动。
| name | execplan |
| description | 任务开工前用这个 skill 评估是否需要先写 spec。触发：涉及 ≥3 模块、>30 文件改动、>10 步骤、架构级决策、或用户说「先出方案 / 先写 spec」。生成的 spec 放 workspace/specs/ |
| provenance | user-authored |
复杂任务（>10 步骤、>30 文件、跨会话恢复、需要 Karry 审阅后 agent 独立推进）前写一份 ExecPlan，让不知道任何上下文的新会话也能接着干完。
基于 OpenAI Codex Exec Plans + Yansu scenario-simulation 改造。
每次 worker 收到任务，开工前先评估复杂度（不向用户输出评估过程，只在命中时开口）：
命中门槛（满足任一就必须提议）：
命中时的提议格式（任务回复的开头，而不是夹在中间）：
:clipboard: 这个任务建议先写 ExecPlan
*理由*：{触发的具体门槛}
*spec 路径*：`workspace/specs/{kebab-name}.md`
*选项*：
- `写 spec` — 我先出 ExecPlan 供你审阅再开工
- `直接干` — 跳过 spec，立即执行
- `我来写` — 你自己写 spec
用户回复「直接干」或已显式给出简单指令 → 不再追问，正常执行。
用户回复「写 spec」→ 按骨架写完 ExecPlan 并 commit，等 Karry 在 ## 验收场景 段对场景拍板后再进实施 turn。
进入 workspace/specs/{name}.md 相关任务时：
spec(xxx): ...）用户说「巡检一下 spec / 看看 spec 状态」时执行：
workspace/specs/*.md，按 Progress 未勾选比例、最后更新时间排序不设 cron（2026-04-18 决定，遵循简洁原则）。
## 验收场景 段（≥3 条），Karry 拍板才进实施。借鉴 Yansu，挡前置理解错位~/Orb/profiles/<your-profile>/workspace/specs/{task-name}.mddm-routing.md / worker-zombie-cleanup.md）代码块（用缩进块替代）；顶层也不必用 包裹整份文档## 执行 段，注明总 turn 预算；大改拆「调研 turn ≤ X」+「实施 turn ≤ Y」两段# {动作短语标题}
## Purpose / 大图景
做完这个 Karry 能做什么之前做不了的？用户可见行为是什么？
## Progress
- [x] (2026-04-18 11:30 JST) 已完成项
- [ ] 待办项
## Surprises & Discoveries
- 观察: ...
证据: {日志/测试输出}
## Decision Log
- 决策: 用 A 不用 B
理由: ...
日期: 2026-04-18
## Outcomes & Retrospective
（收尾写）
## Context / 当前状态
假设读者零上下文。关键文件写全路径，定义每个术语。
## Plan of Work
散文描述：改哪些文件（全路径）、加什么、为什么。
## 验收场景 ← Karry 拍板 gate
列 ≥3 条具体场景，每条写「输入 → 期望可观测行为」。覆盖至少：
- **Happy path**：典型成功用例
- **Edge case**：边界 / 罕见输入 / 并发 / 部分失败
- **Failure mode**：明确的失败行为（报错文案 / 降级路径 / 不该发生什么）
写完发 Slack 等 Karry 确认。Karry 改场景 = spec 调整；Karry 点头 = 进实施。
## Concrete Steps
具体命令 + cwd + 预期输出片段。
## Validation / Acceptance
跑什么、看到什么——对应「验收场景」每条要可执行验证。
## Idempotence / Recovery
能不能重跑？失败如何回滚？
## Interfaces / Dependencies
涉及的模块、函数签名、IPC 协议。写全限定路径。
## 执行
总预算 ≤ N turn；若是大改，拆「调研 turn ≤ X」+「实施 turn ≤ Y」两次 codex session。
每个 milestone 独立可验证、增量交付。写 milestone 时讲故事：目标 → 工作 → 结果 → 证据。
| 工具 | 用途 | 触发层次 |
|---|---|---|
execplan (本文件) | 把一次性复杂任务拆成可独立执行的 spec | 即时 gate + 周扫 |
skill-factory | 把重复工作流沉淀为可复用 skill | 即时提议 + 周聚合 |
state-assumptions-before-acting | 开工前显式化假设 | 任务进入实施前 |
commit-lineage | commit message 锚定 spec/lesson | 每次 commit |