/setup-matt-pocock-skills 技能

它做什么

setup-matt-pocock-skills 会针对一个仓库回答三个问题：issue 放在哪里、分诊标签（triage labels）叫什么、领域文档（domain docs）放在哪里。它把答案记录成 docs/agents/ 下的 Markdown 文件。

这些文件是仓库之间唯一会变化的东西。技能本身在任何地方都完全相同。它们在运行时读取 docs/agents/issue-tracker.md，并照它说的做。这就是为什么这套技能不绑定 GitHub，也是为什么你永远不需要为了让某个技能指向另一个追踪器而去编辑技能文件。用「把技能连接到自定义 issue 追踪器（issue tracker）」来调用它，适用于任何你能以编程方式连接的东西，且无需改动技能。

它是一项提示词驱动的技能，而不是确定性脚本。它会读取你的 git remote、CLAUDE.md 和 GLOSSARY.md，给出它发现的结果，并在写下任何内容之前等你确认。

什么时候用它

你通过输入 /setup-matt-pocock-skills 来调用它；agent 不会主动去拿它。它的元数据刻意把它标记为不可调用，所以没有别的技能能替你触发它。

每个仓库用一次，时机是在第一次使用任何其他工程技能之前。如果 triage、to-spec、to-tickets 或 wayfinder 开始猜测你的 issue 该去哪里，或者套用你的追踪器里没有的标签，那这个仓库还没有配置过。你可以在一个项目进行到一半的仓库里运行它。技能会读取已经存在的内容，所以之前的工作不会丢失。

前提条件

它会写入你运行它的那个仓库：

它写入	位置
`issue-tracker.md`	`docs/agents/`
`domain.md`	`docs/agents/`
`triage-labels.md`	`docs/agents/`，仅当安装了 `triage` 技能时
一个 `## Agent skills` 块	`CLAUDE.md` 或 `AGENTS.md` 中已经存在的那个

你要把这一切作为 Markdown 提交。没有用户级或全局模式。配置住在仓库里，所以每个仓库都有自己的副本。

三个决定

它会在每个小节开头给出推荐答案，并跳过探索已经回答过的问题。大多数运行只需要两次确认。

决定	它提议什么	它什么时候问
issue 追踪器	与你的 `git remote` 匹配的那个	总是问，因为这是唯一真正的选择
分诊标签	保留五个规范名称（`needs-triage`、`needs-info`、`ready-for-agent`、`ready-for-human`、`wontfix`）	仅当安装了 `triage` 技能时
领域文档	单上下文（single-context）：仓库根目录一份 `GLOSSARY.md` 加 `docs/adr/`	仅当它发现 monorepo 信号时，然后它会提议多上下文（multi-context）的 `GLOSSARY-MAP.md`

追踪器选项：

选项	issue 放在哪里	需要什么
GitHub	仓库的 GitHub Issues	`gh` CLI
GitLab	仓库的 GitLab Issues	`glab` CLI
本地 Markdown	本仓库 `.scratch/<feature>/` 下的文件	什么都不需要，连远程仓库都不需要
其他	你说哪里就哪里	你写的一段描述工作流的文字

前三个选项以模板形式随技能提供，开箱即用。本地 Markdown 是一个完整选项，不是退路。这个技能支持没有远程仓库的单人项目。一个注意事项：如果你用 GitHub，就不要用本地 Markdown。它们是替代方案，所以选一个。

「其他」也是一个完整选项。Jira、Linear、Azure DevOps 和 Beads 都是这样工作的。你描述工作流，技能把你的文字记进 docs/agents/issue-tracker.md，下游技能就照着这段文字做。用户已经建出过这样的东西：一个基于 MCP 的 Jira 变体、一个形如 gh 的 Gitea CLI、一个手工搭的本地仪表盘。

常见问题

我必须用 GitHub 吗？

不必须。GitHub、GitLab 和 .scratch/ 下的本地 Markdown 都以现成模板的形式提供，其他任何东西都能通过「其他」路径工作。这是被问得最多的问题，措辞大致是这样：“被死死锁在 GitHub 上了”、“我能用 GitLab / Jira 吗”、“Azure DevOps 呢”。答案永远一样：选择追踪器的是配置，不是技能。

更新技能之后需要重跑它吗？

v1.1 之后的直接答案是「需要」。技能自己的结束语则更缓和。它告诉你，只有切换追踪器或者从头开始时才需要重跑。两种说法都站得住。种子模板会随版本变化，所以来自旧版本的 docs/agents/issue-tracker.md，可能相对现在读取它的技能已经过时。如果下游技能的做法与文档描述的不一样，就重跑一次配置。它很便宜。

它写进了 CLAUDE.md，但我用的是 Codex。

这是一个已知缺口，而且仍未解决。文件选择规则是「如果 CLAUDE.md 存在就编辑它，否则编辑 AGENTS.md」。它检查哪个文件存在，而不是哪个运行环境（harness）在运行。在一个还留着 Claude Code 时代 CLAUDE.md 的仓库里，技能会把它的 ## Agent skills 块写进一个 Codex 永远不会读的文件。用户有两种变通做法：手动把那个块移到 AGENTS.md，或者让 AGENTS.md 作为权威版本、把 CLAUDE.md 做成指向它的一行指针。如果两个文件都不存在，技能会问你要创建哪一个，而不是替你挑一个。这让一些期待它自己做决定的人感到困惑。

它没有创建我的分诊标签。

它不会创建。docs/agents/triage-labels.md 是一份映射：它告诉 /triage，你的追踪器里哪些字符串对应五个规范角色。它不会运行 gh label create。在全新的 GitHub 仓库里，这些标签还不存在，用户不止一次把这件事当作 bug 提交。两个后果：

如果你的追踪器已经在用这些规范名称，这份映射就是一张恒等表，没有什么需要配置。这是预期中的常见情况，而不是漏掉的步骤。
这个技能也不会创建 wayfinder 的 wayfinder:map 和 wayfinder:<type> 标签，而 gh issue create --label <missing> 会直接失败，而不是把标签创建出来。在 GitHub 仓库上第一次运行 wayfinder 之前，先手动创建它们。

我能在这里配置其他技能的行为吗（质询（grilling）的节奏、问题格式、语气）？

不能。它只配置三样东西：追踪器、标签、文档布局。用户曾要求把它做成存放个人偏好的地方。答案是：技能保持自己的主见，不接受按用户区分的配置。偏好属于你自己的 CLAUDE.md，写成普通指令即可，每个技能本来就会读它。

我能把配置放在 ~/.claude 里，而不是提交到每个仓库吗？

目前不行。有一位在多个仓库里运行这些技能的用户为此提了一个仍未关闭的需求，但用户级模式并不存在。每个仓库都带着自己的 docs/agents/。

用一个技能来配置其他技能，不奇怪吗？

一个由来已久的抱怨说确实奇怪，原话是：“用一个技能来配置其他技能，我觉得不对劲：这意味着 LLM 在配置自己的技能。” 这个取舍是真实存在的。如果没有配置这一步，每个会接触 issue 的技能都得自带一份追踪器说明。它的产物是你可以阅读和编辑的 Markdown，这限制了风险。你可以读完它写下的每个文件，再手动修改。日常改动就这样做，不要靠再跑一次。

它生效的标志

docs/agents/issue-tracker.md 和 docs/agents/domain.md 存在；如果装了 triage，还应有 triage-labels.md。
你的运行环境所读取的指令文件里出现一个 ## Agent skills 小节，每个上述文件都有一行摘要指向它。
它提议的追踪器与你在用的远程仓库一致，标签字符串也与你的追踪器里已有的标签一致。
此后，/to-tickets 发布时不再问你 issue 放在哪里，/triage 会套用已有标签，而不是自己发明。
技能文件本身没有任何改动。如果配置过程编辑了某个 SKILL.md，那就是出了问题。

它在体系中的位置

setup-matt-pocock-skills 是工程流程（flow）的一次性配置（run-once setup），是其他一切都假定的前提条件，而不是链条上的一步。它的邻居就是它的读者：triage，负责套用这里写下的标签词汇；to-spec 和 to-tickets，负责发布到这里点名的追踪器；以及 wayfinder，它读取同一个追踪器文件里的「Wayfinding operations」小节，学会如何存放地图和子工单（ticket）。domain-modeling 稍后会补上配置所记录的领域文档布局。它只在你敲定一个术语或一项决策时才创建 GLOSSARY.md 和 ADR，所以配置之后仓库里没有领域文档是正常的。至于接下来该用哪个技能，ask-matt 会为整套技能做路由。

原文：aihero.dev/skills-setup-matt-pocock-skills