用途：把任意起点（原始文本、脑暴报告、GitHub issue、对话）转化为结构化执行规格（spec），产出 3-7 个按优先级排序的工作流，每个工作流含复杂度评级、依赖关系与可测试验收标准，并可选择据此创建 GitHub issue。它是流程中的“结构桥梁”：读取上下文、生成工作流，再交由 /apex 逐个实现。
主要能力与参数：-s/--save 保存到 .claude/output/spec/{slug}/spec.md；-i/--issues 从工作流创建 GitHub issue（隐含启用 -s）；-a/--auto 跳过问答、自行做合理假设；-e/--economy 不使用子代理、仅用直接工具；-f <path>/--from <path> 指定前置上下文（文件、GitHub issue #N 或 URL）。小写启用、大写禁用，默认全部关闭。flags 会从输入中移除，剩余部分作为 {idea}；{slug} 由 {idea} 转为 kebab-case，最多 5 个词。
依赖与用法：创建 issue 或使用 GitHub issue/URL 形式的 -f 需已认证的 gh（GitHub CLI，需先 gh auth login）；其他 flags 无需 gh。非 Markdown 来源（PDF、DOCX、PPTX、音频、YouTube）需先用 /markitdown -s 预处理后传入保存路径。示例：/spec -s add user authentication with OAuth；/spec -s -a -i migrate from REST to GraphQL；/spec -s -e add search functionality。
流程与子代理：流程为先发现（读取前置文档、代码库、问答），再写规格，最后（仅 -i 时）创建 issue。发现阶段默认使用自适应子代理（Explore 用于查找现有模式/文件/架构，general-purpose 用于研究方案与检索），-e 时改为直接工具；子代理数量按上下文从 0-1 到 4-6 不等，需在同一条消息中并行启动，简单想法或小代码库建议不使用子代理。
输出与校验：保存时生成 {output_dir}/spec.md；启用 -i 时在文档后追加 “## GitHub Issues” 段，映射每个工作流到其 issue 编号。编写后必须运行 python3 ${CLAUDE_SKILL_DIR}/scripts/validate_spec.py {output_file}，退出码须为 0；需重写被标记的工作流直到通过（3-7 个工作流、已设置优先级与复杂度、依赖可解析、无环）。脚本需 Python 3.7+。
限制：本技能只产出文档，绝不实现代码改动；一次只加载一个步骤文件；所有步骤间持久化状态变量。自带文件包括 templates/spec.md（规范格式）、scripts/setup-labels.sh（幂等创建 GitHub 标签）、scripts/validate_spec.py（模式与依赖图校验，需 Python 3.7+）。具体各步骤细节、模板内容与标签脚本行为暂未提供。