菜单
新功能的规划→spec→issue 生命周期。当用户说"讨论下"、"写 spec"、"开 issue"、"怎么做"、"设计一下"、"拆任务"、"评估方案"、或描述新功能需求时触发。即使用户只是随口提到一个想法或改进方向，只要涉及"该怎么做"的问题，都应触发此 skill 来结构化思考。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Linear issue management (search, create, update, close, comment) with arbitrary GraphQL queries.
Use when asked to review or audit an implementation plan.
Delegate coding tasks to Codex CLI. Use when executing code changes, reviews, debugging, or parallelizing tasks via Codex.
Release workflow for skills repo. Use when releasing, bumping version, creating tags, or publishing changes. Trigger on "release", "发布", "new version", "bump version".
Multi-lens adversarial review via Codex. Trigger on "review", "审查", "check the code".
Write HANDOFF.md before ending a complex session. Use when wrapping up, switching tasks, or when context is getting large and a fresh session would help.
| name | spec-driven-dev |
| description | 新功能的规划→spec→issue 生命周期。当用户说"讨论下"、"写 spec"、"开 issue"、"怎么做"、"设计一下"、"拆任务"、"评估方案"、或描述新功能需求时触发。即使用户只是随口提到一个想法或改进方向，只要涉及"该怎么做"的问题，都应触发此 skill 来结构化思考。 |
在写代码之前，把"做什么、不做什么、怎么算做完"想清楚写下来。投入多少取决于复杂度 — 简单的事不需要重型流程，复杂的事不能跳过设计。
| 用户意图 | 入口 |
|---|---|
| "讨论下 X" / "这个怎么做" / "评估一下方案" | → 复杂度评估 → 对应阶段 |
| "写个 spec" / "出个规格" | → 直接进阶段 2 |
| "开 issue" / "拆任务" / "创建 issue" | → 直接进阶段 3 |
| "我想加个 X 功能" / 描述一个需求 | → 复杂度评估 → 对应阶段 |
检查本目录下 config.json 是否存在：
provider 字段，加载对应 providers/<provider>.mdgh CLI），再创建 config.jsonConfig 结构：
{ "provider": "linear", "specDir": "docs/specs" }
provider: linear / github / localspecDir: spec 文件存放目录简单 — 单模块、改动可预见、需求清晰
→ 跳过设计和 spec，直接创建 1 个 issue。例：给 CLI 加个 --verbose flag
中等 — 2-3 个模块、需要明确范围和边界 → 写 spec（含设计决策段），然后创建 issue。例：给 API 加分页，涉及接口定义和前端适配
复杂 — 跨多模块、有多个可选方案、需要取舍决策 → 先创建 design() issue → 讨论 → 写 spec → 拆分 issues。例：从 REST 迁移到 GraphQL，涉及 schema 设计、客户端改造、兼容策略
判断不了时默认中等 — 写 spec 的成本远低于返工成本。
一个文件贯穿整个生命周期，用 frontmatter 的 status 标记进展：
status: design ← 阶段 1 产出：问题 + 设计决策
status: spec ← 阶段 2 产出：补全目标、约束、范围、验证方式
status: ready ← 阶段 3 产出：任务已创建（issue 或本地清单）
status: implemented ← 实现合并并验证后
过程记录不在文件里 — design() issue 是讨论过程的留底（无 issue tracker 时跳过）。
每个阶段完成后，问用户是否继续到下一阶段。
Issue 操作按 config 中声明的 provider 执行，具体命令参见 providers/<provider>.md。
<specDir>/NNN-title.md（status: design）+ design() issue⚠️ 阶段 3 有副作用（远程模式）— 会创建真实 issue。创建前必须先展示 draft 给用户确认。
merge 后：