关于 issue-spec
issue-spec 是用于在仓库现有工作流中起草和管理变更规格的技能，指导需求探索、范围与测试定义、验证、发布及交接，并遵循仓库自身规则。
主要功能
- 01探索现有代码、问题和规格
- 02组织范围、设计与测试计划
- 03明确边界及未决事项
- 04验证范围、依赖和标签
- 05发布或更新规格并关联子任务
- 06将就绪工作交接至交付流程
适用场景
- 01为仓库编写变更规格
- 02更新相关的现有规格
- 03准备范围明确的实现与审查工作
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/issue-spec确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
references/spec-format.mdscripts/spec-list.shspec-show.shtemplates/issue-spec-template.md详细介绍
问题规格说明
范围
此技能负责规格编写方法，不负责决定哪些更改需要编写规格。请阅读目标仓库的 AGENTS.md 和相关工作流覆盖文件，了解始终需要规格的范围、标签、必需章节和例外情况。明确要求编写规格即可开始；不要再次询问是否要编写。使用仓库声明的规格载体。若仓库采用基于 issue 的 SDD 循环，则使用 GitHub issue；不要凭推断迁移其他仓库的规格格式。
前置条件
了解预期更改、目标仓库和适用约定。对于 GitHub 工作，仅在需要能力映射时使用 harness-operations。不要求安装个人工具或使用特定的 GitHub 工具。起草时请阅读格式参考，并以模板作为起点，而非额外政策。
流程
- 发现相关代码、近期更改以及现有 issue/规格。复用或修订相关工作，而不是重复创建。根据检出目录/远程仓库和约定确定目标仓库；不要根据技能源仓库推断。
- 通过概述、设计、可独立验证的计划项、对应的测试项、对齐情况和可选备注来记录意图。包含仓库要求的影响/示例章节。规格尽量控制在约 2000 个 token 以内；较大的功能应拆分为一个父项和范围独立的子项。
- 在对齐情况中说明边界。继续执行已获授权的实现决策。对于工作所需但尚未明确解决的具体人工决策边界，使用由 harness-operations 映射的结构化提问能力；说明问题来源、受影响的计划项、选项及利弊。仅使用纯文本提问或“由人工决定”清单并不代表已请求作出决定。依赖该决定的工作须等待明确答复；继续进行独立且已获授权的工作。在同一轮处理中将答复纳入规格并清除已解决的阻塞项。如果没有获准使用的提问工具，请说明这一限制，并通过既定交接渠道处理，不要擅自假设答案。
- 验证范围、不变量、测试覆盖、依赖项和必需标签。在 GitHub 正文中，每个说明段落或列表项都应保持在同一源代码行；使用空行分隔各区块。交付前不要将计划项标记为已完成。
- 通过可用且获授权的工具发布或更新规格。采用仓库现有的标签、优先级和领域惯例；不要仅因本流程在示例中使用某种分类，就创建新的分类体系。在支持的情况下，使用原生子 issue 建立父子关系；否则记录明确链接。
- 将已准备好的工作交接给 pre-push 和 pr-lifecycle。遵循仓库的 worktree/分支规则。通用流程不会规定 harness 分支前缀。
完成
报告规格的路径/URL、范围、决策，以及发布能力受阻的情况。本地草稿不等于已发布的 issue。在基于 issue 的 SDD 中，最终交付使用 Closes #N 链接，部分交付使用 Part of #N 链接，并仅在合并后更新计划进度。如果仓库没有规格门禁，不要强行添加。
可选辅助工具
list helper 和 show helper 是可选的 CLI 便捷工具，需要已认证的 GitHub CLI 和 jq。若这些前置条件不可用，请改用已连接的 GitHub 工具。
评论
支持 Markdown