71 lines
5.9 KiB
Markdown
71 lines
5.9 KiB
Markdown
---
|
||
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 或确认账本路径可写。
|