5.9 KiB
5.9 KiB
name, description, metadata
| name | description | metadata | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| le-spec | 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、直接写代码、直接改代码"。 |
|
Le SPEC —— 需求分析与 SPEC 生成总控
用户负责表达意图与做关键决策；你负责理解、挖掘、思考、推荐、整理与验证。 产出物不是"更漂亮的需求文档"，而是在开始编码前把该想清楚的都想清楚的正式 SPEC。
三条铁律（先于一切流程）
- 真实调用，不冒充。 访谈必须真实加载
grilling原文并遵循其 design-tree/frontier 机制；方案分析必须真实加载think原文；规格必须经openspecCLI 生成与校验。禁止用自拟提示词模拟依赖行为。每次依赖交互记入调用账本（见下），无账本条目视为未发生。 - 不重复、不复盘。 已确认的决策写入状态文件后，后续任何阶段（Think / 验收 / 审查）只消费不重问；发现新不确定性时做针对性追问，不重启流程。
- 批准前不编码。 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
- 依赖真实调用协议：dependencies.md（Phase 2/3/5 入口必读）
- Phase 4 规程：acceptance.md；Phase 6 规程：review.md
阶段是逻辑流不是机械串行：simple 档压缩执行（见 workflow.md 复杂度分档），用户可随时切换讨论模块、修改需求、查看草稿——但只能向前跳过 AI 侧环节，不能跳过用户确认停点。
启动协议（每次触发本 skill 时）
- 定位项目 OpenSpec 根：
openspec context --json。有根且存在<root>/openspec/le-spec/state.md→ 读状态，从其「下一步」恢复，不重做已完成阶段。 - 无状态文件 → 全新分析：跑
python3 <skill_dir>/scripts/deps_check.py检查依赖（见铁律 1）。缺失 required 级依赖 → 停止并给出精确安装命令（见 dependencies.md），不得以降级模拟继续。 - 按 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 后迁移。
停手点（回合终止硬约束）
- 依赖检查失败 → 停，给安装指引。
- Phase 2 每轮问完 → 终止回合等用户回答；Phase 3 推荐方案给出 → 等用户决断。
- Phase 4 发现 blocking 问题 → 终止回合，向用户澄清后才能进 Phase 5。
- Phase 7 呈交确认包 → 终止回合；未获明确批准不得动实现代码。
- 用户要求删除/重写已批准 SPEC 的大范围内容 → 停，先确认影响范围。
反例黑名单
- 不把临时想法当已确认需求，不把 AI 推荐方案当用户已批准。
- 不为凑轮数追问，也不为省事跳过 blocking 问题。
- 不在 SPEC 里编造业务规则、验收标准或技术约束。
- 不把产品需求、技术设计、开发任务混写进一个文件（OpenSpec 三 artifact 天然分离，遵循它）。
- 不在旧会话假设新装依赖"应该可用"——调用前先 deps_check 或确认账本路径可写。