القائمة
任务开工前用这个 skill 评估是否需要先写 spec。触发：涉及 ≥3 模块、>30 文件改动、>10 步骤、架构级决策、或用户说「先出方案 / 先写 spec」。生成的 spec 放 workspace/specs/
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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 |