Menu
为当前仓库配置工程类 Skills，包括 Issue 跟踪器、分诊标签词汇和领域文档布局。首次使用其他工程类 Skills 前运行一次。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | setup-matt-pocock-skills |
| description | 为当前仓库配置工程类 Skills，包括 Issue 跟踪器、分诊标签词汇和领域文档布局。首次使用其他工程类 Skills 前运行一次。 |
| disable-model-invocation | true |
创建工程类 Skills 在每个仓库中依赖的配置：
CONTEXT.md 和 ADR 保存在哪里，以及使用方读取这些文档时应遵守的规则。本 Skill 由提示词驱动，不是一段结果完全固定的脚本。先探索仓库，展示发现，与用户确认，再写入文件。
检查当前仓库，了解初始状态。以实际存在的内容为准，不作假设：
git remote -v 和 .git/config——这是 GitHub 仓库吗？具体是哪一个？AGENTS.md 和 CLAUDE.md——是否存在？其中是否已经包含 ## Agent skills 一节？CONTEXT.md 和 CONTEXT-MAP.mddocs/adr/ 及所有 src/*/docs/adr/ 目录docs/agents/——本 Skill 以前是否已经生成过配置？.scratch/——是否已有使用本地 Markdown Issue 跟踪器的迹象？总结已经存在和仍然缺失的内容。随后引导用户依次完成三项决策，每次只讨论一项：展示一个部分，取得用户回答，再进入下一项。不要一次性抛出全部三个问题。
默认用户不了解这些术语。每个部分先用一小段文字解释它是什么、这些 Skills 为什么需要它，以及不同选择会带来什么变化；然后再展示选项和默认建议。
A 部分——Issue 跟踪器。
说明：“Issue 跟踪器”是当前仓库保存 Issues 的地方。
to-tickets、triage、to-spec、qa等 Skills 都会读写它，因此必须知道应运行gh issue create、在.scratch/下写 Markdown 文件，还是遵循你提供的其他流程。请选择这个仓库实际用于跟踪工作的地方。
默认倾向：这些 Skills 最初围绕 GitHub 设计。如果 git remote 指向 GitHub，应优先建议 GitHub；如果指向 GitLab（gitlab.com 或自托管地址），应优先建议 GitLab。其他情况下，或用户另有偏好时，提供以下选项：
gh CLIglab CLI.scratch/<feature>/ 下，适合个人项目或没有远程仓库的项目当且仅当用户选择 GitHub 或 GitLab 时，再提出一个后续问题：
说明：开源仓库收到的功能请求有时以 PR 形式出现，而不只是 Issue；PR 可以看作附带代码的 Issue。启用后，
/triage会把外部 PR 纳入同一队列，使用相同标签和状态完成分诊；协作者正在推进的 PR 不受影响。如果 PR 并不是你的请求入口，请保持关闭。
docs/agents/issue-tracker.md。本地 Markdown 和其他跟踪器没有 PR，应跳过此问题。B 部分——分诊标签词汇。
说明：
triageSkill 处理新 Issue 时，会让它经过一个状态机：等待维护者评估、等待报告者补充信息、可以交给无需人工上下文的 Agent、需要人类实现，或决定不处理。为此，它需要添加与你的 Issue 跟踪器实际配置相符的标签或等价状态。如果仓库已经使用不同名称，例如bug:triage代替needs-triage，请在这里建立映射，避免 Skill 创建重复标签。
五种标准角色：
needs-triage——等待维护者评估needs-info——等待报告者补充信息ready-for-agent——信息完整，可以交给无需人工上下文的 Agentready-for-human——需要人类实现wontfix——不会处理默认情况下，每个角色对应的标签字符串与角色名称相同。询问用户是否要覆盖其中任何一项。如果 Issue 跟踪器尚未配置标签，直接使用默认值即可。
C 部分——领域文档。
说明：
improve-codebase-architecture、diagnosing-bugs、tdd等 Skills 会读取CONTEXT.md，了解项目领域语言；也会读取docs/adr/，了解过去的架构决策。它们需要知道仓库只有一个全局上下文，还是包含多个上下文，例如前端和后端各自拥有独立上下文的 monorepo，才能读取正确位置。
确认布局：
CONTEXT.md 和一个 docs/adr/。多数仓库采用这种结构。CONTEXT-MAP.md，其中指向各上下文自己的 CONTEXT.md，通常用于 monorepo。向用户展示以下内容的草稿：
CLAUDE.md 或 AGENTS.md 的 ## Agent skills 区块。具体文件选择规则见步骤 4。docs/agents/issue-tracker.md、docs/agents/triage-labels.md、docs/agents/domain.md 的完整内容。允许用户在写入前修改草稿。
选择要编辑的文件：
CLAUDE.md，编辑它。AGENTS.md，编辑它。CLAUDE.md 已存在时，绝不能另外创建 AGENTS.md；反之亦然。始终编辑仓库已经采用的那个文件。
所选文件中已经存在 ## Agent skills 区块时，原地更新区块内容，不能追加重复区块。不要覆盖周围章节中用户自己写的内容。
区块格式：
## Agent skills
### Issue tracker
[用一行说明 Issues 保存在哪里，以及外部 PR 是否属于分诊入口]。详见 `docs/agents/issue-tracker.md`。
### Triage labels
[用一行说明标签词汇]。详见 `docs/agents/triage-labels.md`。
### Domain docs
[用一行说明布局是 “single-context” 还是 “multi-context”]。详见 `docs/agents/domain.md`。
随后以本 Skill 目录中的种子模板为起点，写入三个配置文档：
选择“其他”Issue 跟踪器时，根据用户说明从头编写 docs/agents/issue-tracker.md。
告知用户配置已经完成，并说明哪些工程类 Skills 会读取这些文件。提醒用户以后可以直接编辑 docs/agents/*.md；只有想要切换 Issue 跟踪器或从头重新配置时，才需要再次运行本 Skill。
使用并行 sub-agents 为一个 module 生成多套差异显著的 interface 设计。适用于用户希望设计 API、探索 interface 选项、比较 module 形态，或提到“design it twice”的场景。
运行交互式 QA session：用户通过对话报告 bugs 或 issues，agent 随后创建 GitHub issues；同时在后台探索 codebase，获取上下文和 domain language。适用于用户希望报告 bugs、开展 QA、通过对话创建 issues，或提到“QA session”的场景。
通过用户访谈创建一份由微小 commits 组成的详细 refactor plan，并将其提交为 GitHub issue。适用于用户希望规划 refactor、创建 refactoring RFC，或将 refactor 拆分为安全的增量步骤。
从当前对话中提取一份 DDD 风格的 ubiquitous language glossary，标出歧义并提出规范术语，保存到 UBIQUITOUS_LANGUAGE.md。适用于用户希望定义 domain terms、建立 glossary、收紧术语、创建 ubiquitous language，或提到“domain model”或“DDD”的场景。
询问当前情境适合使用哪个 Skill 或工作流。本 Skill 是仓库内其他 Skills 的路由入口。
从用户指定的固定点（commit、branch、tag 或 merge-base）开始，从两个维度审查代码变更：Standards 检查代码是否遵守仓库记录的编码规范，Spec 检查实现是否符合原始 Issue、PRD 或规格。两个审查由并行子 Agent 分别完成，再并列汇报。适用于用户希望审查分支、PR、开发中的改动，或要求“审查自 X 以来的变更”时。