用途：在动手写代码前，为某个 GitHub issue 生成一份可长期保存的功能规格文档，避免直接编码。
触发方式：/spec --issue N [--fast]。--issue N 为必填，读取 GitHub issue #N；--fast 跳过提问，采用 reference/defaults.md 中的默认值，但仍需用户批准规格（硬性关卡）。
输出：docs/specs/YYYY-MM-DD-{slug}-issue-{N}.md，YAML frontmatter 含 issue: N，便于 /implementation --issue N 自动找到该文件。
工作流：1) 加载代码库地图，检查 docs/codebase/INDEX.md 是否存在且小于 7 天，否则先运行 /map-codebase；2) 用 gh issue view N --json title,body,labels,state 读取 issue；3) 进行 9 阶段头脑风暴，先读实际相关代码（模型、迁移、外键模式）再提问，问题需体现对代码库的理解；4) 按 templates/spec.md 写规格，所有列、端点、清单文件都要写全，不留占位符或 TBD，未知项显式记为待定决策；5) 可选对抗性审查，会启动 Codex/Gemini 审查者查找缺失约束、错误外键假设、范围蔓延、矛盾与安全缺口；6) 提交规格：git add docs/specs/{filename} 与 git commit -m "docs(spec): {feature slug} spec — issue #{N}"；7) 输出交接块，提供当前会话实现或并行 worktree 实现两种选项。
限制：该技能只写规格文档，不开始实现、不写任何代码；规格留在 main 分支，多个规格可并行提交，因为只是文档不产生代码冲突。