Menü
为当前仓库配置工程类 Skills，包括 Issue 跟踪器、分诊标签词汇和领域文档布局。首次使用其他工程类 Skills 前运行一次。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
使用并行 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 以来的变更”时。
| 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。