用途：在明确要求或仓库贡献策略要求时，创建或修订一份聚焦的规格说明 issue。该技能负责规格方法本身，而非判定哪些改动需要规格；需要读取目标仓库的 AGENTS.md 和相关工作流覆盖层，了解强制规格范围、标签、必需章节与例外。明确要求写规格即可开始，无需再确认。
前提：需知道预期改动、目标仓库和适用契约。GitHub 相关工作时，仅在需要能力映射时使用 harness-operations；不要求个人安装或特定 GitHub 工具。起草时读取格式参考，并将模板作为起点而非额外策略。
流程：先发现相关代码、近期变更与已有 issue/规格，复用或修订相关工作而非新建重复项；目标仓库由其检出/远程与契约确定，不从技能来源仓库推断。用 Overview、Design、可独立验证的 Plan 项、对应 Test 项、Alignment 和可选 Notes 捕获意图，并包含仓库要求的 impact/example 章节。规格尽量控制在约 2000 tokens 以内，较大功能拆为父项与独立范围的子项。
边界与问题：在 Alignment 中说明边界；已授权的实现决策继续推进。对工作所需的未决人工边界，使用 harness-operations 映射的结构化提问能力，指明来源、受影响的 Plan 项、选项与权衡；纯文本提问或“Human decides”清单本身不构成提问请求。等待明确答复前，继续独立的授权工作；得到答复后在同一会话中并入规格并清除阻塞。若没有允许的提问工具，说明该限制并用既定交接渠道，不假设已有答案。
校验与发布：校验范围、不变量、测试覆盖、依赖与必需标签。GitHub 正文中每个段落或列表项保持单行源码，空行分隔块；交付前不得将 Plan 项标记为完成。通过可用的授权工具发布或更新规格，应用仓库既有标签、优先级和区域约定，不因本流程示例而新建分类法。支持时用原生子 issue 建立子关系，否则记录显式链接。就绪工作交给 pre-push 和 pr-lifecycle，遵循仓库的 worktree/分支规则；通用流程不选择 harness 分支前缀。
完成：报告规格路径/URL、范围、决策及任何受阻的发布能力。本地草稿不算已发布 issue。在基于 issue 的 SDD 下，最终交付用 Closes #N 关联，部分交付用 Part of #N，仅落地后调和 Plan 进度。仓库无规格门禁时不要强加。可选辅助：list helper 与 show helper 为可选 CLI 便利工具，需要已认证的 GitHub CLI 与 jq；前提不可用时改用已连接的 GitHub 工具。