setup-matt-pocock-skills

name	setup-matt-pocock-skills
description	为当前仓库配置工程类 Skills，包括 Issue 跟踪器、分诊标签词汇和领域文档布局。首次使用其他工程类 Skills 前运行一次。
disable-model-invocation	true

配置 Matt Pocock Skills

创建工程类 Skills 在每个仓库中依赖的配置：

• Issue 跟踪器——Issues 保存在哪里。默认使用 GitHub，也原生支持本地 Markdown。
• 分诊标签——五种标准分诊角色实际使用的标签字符串。
• 领域文档——CONTEXT.md 和 ADR 保存在哪里，以及使用方读取这些文档时应遵守的规则。

本 Skill 由提示词驱动，不是一段结果完全固定的脚本。先探索仓库，展示发现，与用户确认，再写入文件。

流程

1. 探索

检查当前仓库，了解初始状态。以实际存在的内容为准，不作假设：

• git remote -v 和 .git/config——这是 GitHub 仓库吗？具体是哪一个？
• 仓库根目录的 AGENTS.md 和 CLAUDE.md——是否存在？其中是否已经包含 ## Agent skills 一节？
• 根目录的 CONTEXT.md 和 CONTEXT-MAP.md
• docs/adr/ 及所有 src/*/docs/adr/ 目录
• docs/agents/——本 Skill 以前是否已经生成过配置？
• .scratch/——是否已有使用本地 Markdown Issue 跟踪器的迹象？

2. 展示发现并询问用户

总结已经存在和仍然缺失的内容。随后引导用户依次完成三项决策，每次只讨论一项：展示一个部分，取得用户回答，再进入下一项。不要一次性抛出全部三个问题。

默认用户不了解这些术语。每个部分先用一小段文字解释它是什么、这些 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。其他情况下，或用户另有偏好时，提供以下选项：

• GitHub——Issues 位于仓库的 GitHub Issues，使用 gh CLI
• GitLab——Issues 位于仓库的 GitLab Issues，使用 glab CLI
• 本地 Markdown——Issues 作为文件保存在仓库的 .scratch/<feature>/ 下，适合个人项目或没有远程仓库的项目
• 其他（Jira、Linear 等）——让用户用一段话说明工作流，本 Skill 将其原样记录成自由格式说明

当且仅当用户选择 GitHub 或 GitLab 时，再提出一个后续问题：

说明：开源仓库收到的功能请求有时以 PR 形式出现，而不只是 Issue；PR 可以看作附带代码的 Issue。启用后，/triage 会把外部 PR 纳入同一队列，使用相同标签和状态完成分诊；协作者正在推进的 PR 不受影响。如果 PR 并不是你的请求入口，请保持关闭。

• 是否把 PR 作为请求入口——是 / 否，默认否。将答案写入 docs/agents/issue-tracker.md。本地 Markdown 和其他跟踪器没有 PR，应跳过此问题。

B 部分——分诊标签词汇。

说明：triage Skill 处理新 Issue 时，会让它经过一个状态机：等待维护者评估、等待报告者补充信息、可以交给无需人工上下文的 Agent、需要人类实现，或决定不处理。为此，它需要添加与你的 Issue 跟踪器实际配置相符的标签或等价状态。如果仓库已经使用不同名称，例如 bug:triage 代替 needs-triage，请在这里建立映射，避免 Skill 创建重复标签。

五种标准角色：

• needs-triage——等待维护者评估
• needs-info——等待报告者补充信息
• ready-for-agent——信息完整，可以交给无需人工上下文的 Agent
• ready-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。

3. 确认并编辑

向用户展示以下内容的草稿：

• 准备添加到 CLAUDE.md 或 AGENTS.md 的 ## Agent skills 区块。具体文件选择规则见步骤 4。
• docs/agents/issue-tracker.md、docs/agents/triage-labels.md、docs/agents/domain.md 的完整内容。

允许用户在写入前修改草稿。

4. 写入

选择要编辑的文件：

• 如果存在 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-tracker-github.md——GitHub Issue 跟踪器
• issue-tracker-gitlab.md——GitLab Issue 跟踪器
• issue-tracker-local.md——本地 Markdown Issue 跟踪器
• triage-labels.md——标签映射
• domain.md——领域文档读取规则和布局

选择“其他”Issue 跟踪器时，根据用户说明从头编写 docs/agents/issue-tracker.md。

5. 完成

告知用户配置已经完成，并说明哪些工程类 Skills 会读取这些文件。提醒用户以后可以直接编辑 docs/agents/*.md；只有想要切换 Issue 跟踪器或从头重新配置时，才需要再次运行本 Skill。