le-spec v1.0.0：Le SPEC 智能需求分析与 SPEC 生成总控 skill——真实集成 grilling/grill-with-docs(domain-modeling) + think + openspec(CLI 1.16.1 + 7 个 openspec-* skills，均经 skills.sh 装入 ~/.agents/skills 并软链四 runtime)；七阶段工作流（识别/十类分拣/Grill 访谈/Think 挑战/反向验收/OpenSpec 生成/四视角审查）复杂度三档自适应；状态 state.md + 调用账本 ledger.jsonl 双持久化支撑中断恢复与真实调用核验；依赖检查 deps_check.py 分级报缺+精确安装命令，ledger.py append/check/tail；四类回合终止停点（批准前不编码为硬约束）；测试 A-I 九项全过：两场景 fresh-context 子代理多轮实测（4 轮访谈+变更+中断恢复+strict validate 双项目通过），账本 28 条真实调用（grilling×9/think×2/openspec CLI×14），独立子代理审查实测抓出自审遗漏的 2 blocking；已知限制 7 项如实入库（reports/test-report.md）

skills/le-spec/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: le-spec
+description: |
+  Le SPEC —— 智能需求分析与 SPEC 生成总控：把模糊、零散、矛盾的自然语言想法，经真实集成的 Grill 深度访谈、Think 方案挑战、OpenSpec 规格工程，转化为可执行、可测试的正式 SPEC。
+  何时触发：用户想从想法或零散需求出发，先梳理清楚再开发（"帮我把这个想法整理成 spec""我要做个 App，先分析下需求""这些需求有点乱，帮我梳理""先想清楚再写代码""来一场需求访谈""write a spec""refine these requirements"）；提到 grill / openspec / 需求工程 / SPEC 生成；已有项目新增功能或变更需求要走规格（"给这个功能写个 spec""需求变了，更新规格"）。
+  不要触发：已批准 SPEC 的实现与编码（交给 Coding Agent / openspec-apply-change）；纯 PRD/需求文档的润色与排版；与需求澄清无关的普通文档写作；用户明说"别做 spec、直接写代码、直接改代码"。
+metadata:
+  author: Leroy
+  version: "1.0.0"
+  runtimes: zcode, claude-code, codex
+  requires: grilling + grill-me/grill-with-docs + domain-modeling (mattpocock/skills), think (tw93/Waza), openspec CLI + openspec-* skills (Fission-AI/OpenSpec)
+---
+
+# Le SPEC —— 需求分析与 SPEC 生成总控
+
+用户负责表达意图与做关键决策；你负责理解、挖掘、思考、推荐、整理与验证。
+产出物不是"更漂亮的需求文档"，而是**在开始编码前把该想清楚的都想清楚**的正式 SPEC。
+
+## 三条铁律（先于一切流程）
+
+1. **真实调用，不冒充。** 访谈必须真实加载 `grilling` 原文并遵循其 design-tree/frontier 机制；方案分析必须真实加载 `think` 原文；规格必须经 `openspec` CLI 生成与校验。禁止用自拟提示词模拟依赖行为。每次依赖交互记入调用账本（见下），无账本条目视为未发生。
+2. **不重复、不复盘。** 已确认的决策写入状态文件后，后续任何阶段（Think / 验收 / 审查）只消费不重问；发现新不确定性时做**针对性**追问，不重启流程。
+3. **批准前不编码。** Phase 7 是回合终止硬停点：向用户呈交确认包后终止回合，未经用户明确批准，不得创建/修改任何实现代码，不得执行 openspec-apply-change。
+
+## 阶段机
+
+| 阶段 | 做什么 | 依赖调用 | 退出条件 |
+|---|---|---|---|
+| 0 识别 | 判项目类型、只读检查、复杂度分级 | `openspec context --json`（探测已有根） | 复杂度定档、上下文清单成形 |
+| 1 理解 | 原始需求结构化（十类分拣） | — | `state.md` 初始化完成 |
+| 2 访谈 | Grill 深度访谈 | **grilling**；已有代码库时叠加 **domain-modeling** | 收敛标准满足（见 workflow.md） |
+| 3 方案 | 方案分析与挑战 | **think**（无实质分歧可跳过） | 推荐方案获用户确认 |
+| 4 验收 | 需求反向验收（独立工程师视角） | 独立子代理（fresh context） | 无 blocking 级未决问题 |
+| 5 规格 | OpenSpec 生成正式 SPEC | **openspec CLI** + openspec-propose/new-change 工作流 | artifacts 齐全且 `validate` 通过 |
+| 6 审查 | SPEC 独立质量审查（四视角） | 独立子代理 + `openspec validate` | 审查问题清零或降为非阻塞 |
+| 7 交接 | 用户确认与交接 | — | 用户明确批准 → 交给 Coding Agent |
+
+- 每阶段详细规程：[workflow.md](references/workflow.md)
+- 依赖真实调用协议：[dependencies.md](references/dependencies.md)（**Phase 2/3/5 入口必读**）
+- Phase 4 规程：[acceptance.md](references/acceptance.md)；Phase 6 规程：[review.md](references/review.md)
+
+阶段是逻辑流不是机械串行：simple 档压缩执行（见 workflow.md 复杂度分档），用户可随时切换讨论模块、修改需求、查看草稿——但**只能向前跳过 AI 侧环节，不能跳过用户确认停点**。
+
+## 启动协议（每次触发本 skill 时）
+
+1. 定位项目 OpenSpec 根：`openspec context --json`。有根且存在 `<root>/openspec/le-spec/state.md` → 读状态，从其「下一步」恢复，不重做已完成阶段。
+2. 无状态文件 → 全新分析：跑 `python3 <skill_dir>/scripts/deps_check.py` 检查依赖（见铁律 1）。缺失 required 级依赖 → 停止并给出精确安装命令（见 dependencies.md），不得以降级模拟继续。
+3. 按 Phase 0 → 1 进入。
+
+## 状态与账本（持久化，跨会话恢复）
+
+- `<root>/openspec/le-spec/state.md` —— 阶段、已确认决策、否定方案、开放问题、假设、下一步、访谈轮次计数。每轮重要交互后增量更新；用户变更需求时记录影响范围。
+- `<root>/openspec/le-spec/ledger.jsonl` —— 调用账本，经 `scripts/ledger.py append` 记录每次依赖交互（dep / kind / cmd / exit / summary）。Phase 7 交付与 Phase 6 审查以账本为真实调用证据。
+- 项目无 OpenSpec 根时暂用 `.le-spec/` 存放，待 Phase 5 init 后迁移。
+
+## 停手点（回合终止硬约束）
+
+1. 依赖检查失败 → 停，给安装指引。
+2. Phase 2 每轮问完 → 终止回合等用户回答；Phase 3 推荐方案给出 → 等用户决断。
+3. Phase 4 发现 blocking 问题 → 终止回合，向用户澄清后才能进 Phase 5。
+4. Phase 7 呈交确认包 → **终止回合**；未获明确批准不得动实现代码。
+5. 用户要求删除/重写已批准 SPEC 的大范围内容 → 停，先确认影响范围。
+
+## 反例黑名单
+
+- 不把临时想法当已确认需求，不把 AI 推荐方案当用户已批准。
+- 不为凑轮数追问，也不为省事跳过 blocking 问题。
+- 不在 SPEC 里编造业务规则、验收标准或技术约束。
+- 不把产品需求、技术设计、开发任务混写进一个文件（OpenSpec 三 artifact 天然分离，遵循它）。
+- 不在旧会话假设新装依赖"应该可用"——调用前先 deps_check 或确认账本路径可写。