Skill Learning

setup-matt-pocock-skills

1. Bilingual SKILL.md

左右滑动可直接切换英文版与中文版;两种语言按段落自动对齐。英文中的蓝色虚线词语可点击查看解释。共标记 12 处。

入口 skill:setup-matt-pocock-skills左右滑动切换语言 · 段落位置自动对齐
# Setup Matt Pocock's Skills
that the engineering skills assume:
- **Issue tracker**: where issues live (GitHub by default; local markdown is also ) - **Triage labels**: the strings used for the five canonical triage roles - **Domain docs**: where `CONTEXT.md` and ADRs live, and the consumer rules for reading them
This is a , not a deterministic script. Explore, present what you found, confirm with the user, then write.
## Process
### 1. Explore
Look at the current repo to understand its starting state. :
- `git remote -v` and `.git/config`: is this a GitHub repo? Which one? - `AGENTS.md` and `CLAUDE.md` at the repo root: does either exist? Is there already an `## Agent skills` section in either? - `CONTEXT.md` and `CONTEXT-MAP.md` at the repo root - `docs/adr/` and any `src/*/docs/adr/` directories - `docs/agents/`: does this skill's prior output already exist? - `.scratch/`: a local-markdown issue tracker convention is already in use - Is the `triage` skill installed? (a `triage` skill folder alongside this one, or `triage` in your available skills.) This decides whether Section B runs at all. - Monorepo signals: a `pnpm-workspace.yaml`, a `workspaces` field in `package.json`, or a populated `packages/*` with its own `src/`. These are present only in a genuinely large multi-package repo; their absence means single-context, which is almost every repo.
### 2. Present findings and ask
Summarise what's present and what's missing. Then take the sections in order.
so the user can accept it in a word. Give a one-line explainer only when the choice genuinely branches; skip the section entirely when exploration already settled it (Section B when `triage` isn't installed, Section C when there's no monorepo).
**Section A: Issue tracker.**
> Explainer: The "issue tracker" is where issues live for this repo. Skills like `to-tickets`, `triage`, and `to-spec` read from and write to it. They need to know whether to call `gh issue create`, write a markdown file under `.scratch/`, or follow some other workflow you describe. Pick the place you actually track work for this repo.
: these skills were designed for GitHub. If a `git remote` points at GitHub, propose that. If a `git remote` points at GitLab (`gitlab.com` or a self-hosted host), propose GitLab. Otherwise (or if the user prefers), offer:
- **GitHub**: issues live in the repo's GitHub Issues (uses the `gh` CLI) - **GitLab**: issues live in the repo's GitLab Issues (uses the [`glab`](https://gitlab.com/gitlab-org/cli) CLI) - **Local markdown**: issues live as files under `.scratch/<feature>/` in this repo (good for solo projects or repos without a remote) - **Other** (Jira, Linear, etc.): ask the user to describe the workflow in one paragraph; the skill will record it as freeform prose
Record the choice in `docs/agents/issue-tracker.md`. The GitHub and GitLab templates carry a "" flag, defaulted **off**. Leave it off and don't raise it: a user who wants external PRs in the triage queue can flip the flag in the file later.
**Section B: Triage label vocabulary.** Skip this section entirely if the `triage` skill isn't installed (exploration told you), since an uninstalled skill needs no labels.
If it is installed, ask exactly one question:
> Do you want to keep the default triage labels? (recommended: **yes**)
The defaults are the five canonical roles, each label string equal to its name: `needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix`. On **yes**, write them as-is. Only if the user says no, usually because their tracker already uses other names (e.g. `bug:triage` for `needs-triage`), so `triage` applies existing labels instead of creating duplicates.
**Section C: Domain docs.** Default to **single-context** (one `CONTEXT.md` + `docs/adr/` at the repo root). This fits almost every repo; write it without asking.
Offer **multi-context** (a root `CONTEXT-MAP.md` pointing to per-context `CONTEXT.md` files) only when exploration found monorepo signals. Then confirm which layout they want.
### 3. Confirm and edit
Show the user a draft of:
- The `## Agent skills` block to add to whichever of `CLAUDE.md` / `AGENTS.md` is being edited (see step 4 for selection rules) - The contents of `docs/agents/issue-tracker.md`, `docs/agents/domain.md`, and `docs/agents/triage-labels.md` (the last only when `triage` is installed)
Let them edit before writing.
### 4. Write
**Pick the file to edit:**
- If `CLAUDE.md` exists, edit it. - Else if `AGENTS.md` exists, edit it. - If neither exists, ask the user which one to create; don't pick for them.
Never create `AGENTS.md` when `CLAUDE.md` already exists (or vice versa); always edit the one that's already there.
If an `## Agent skills` block already exists in the chosen file, rather than appending a duplicate. Don't overwrite user edits to the surrounding sections.
The block:
```markdown ## Agent skills
### Issue tracker
[one-line summary of where issues are tracked]. See `docs/agents/issue-tracker.md`.
### Triage labels
[one-line summary of the label vocabulary]. See `docs/agents/triage-labels.md`.
### Domain docs
[one-line summary of layout: "single-context" or "multi-context"]. See `docs/agents/domain.md`. ```
Include the `### Triage labels` sub-block, and write `docs/agents/triage-labels.md`, only when `triage` is installed and Section B ran. When it isn't, both are omitted.
Then write the docs files :
- [issue-tracker-github.md](./issue-tracker-github.md): GitHub issue tracker - [issue-tracker-gitlab.md](./issue-tracker-gitlab.md): GitLab issue tracker - [issue-tracker-local.md](./issue-tracker-local.md): local-markdown issue tracker - [triage-labels.md](./triage-labels.md): label mapping (only if `triage` is installed) - [domain.md](./domain.md): domain doc consumer rules + layout
For "other" issue trackers, write `docs/agents/issue-tracker.md` from scratch using the user's description.
### 5. Done
Tell the user the setup is complete and which engineering skills will now read from these files. Mention they can edit `docs/agents/*.md` directly later; re-running this skill is only necessary if they want to switch issue trackers or restart from scratch.
# 设置 Matt Pocock 的技能
搭建工程技能所依赖的每仓库配置:
- **Issue tracker**:issue 存放在哪里(默认使用 GitHub;同时开箱即用地支持本地 Markdown) - **Triage 标签**:五个标准 triage 角色所使用的字符串 - **领域文档**:`CONTEXT.md` 和 ADR 存放在哪里,以及读取它们的使用方规则
这是一个由提示驱动的技能,而不是确定性脚本。先探索,展示发现,请用户确认,然后再写入。
## 流程
### 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/`:这个技能以前的输出是否已经存在? - `.scratch/`:它表明仓库可能已经使用本地 Markdown issue tracker 约定 - 是否安装了 `triage` 技能?(本技能旁边有 `triage` 技能文件夹,或可用技能中包含 `triage`。)这决定是否执行 B 节。 - Monorepo 信号:`pnpm-workspace.yaml`、`package.json` 中的 `workspaces` 字段,或包含自身 `src/` 的非空 `packages/*`。这些信号只会出现在真正的大型多包仓库中;缺少这些信号就意味着单一上下文,而几乎所有仓库都属于这种情况。
### 2. 展示发现并提问
总结已有内容和缺失内容。然后按顺序逐节处理。每节只问一个问题,收到一个答案后再进入下一节。
每节都先给出推荐答案,让用户只用一个词就能接受。只有当选择确实会产生分支时,才给出一行解释;如果探索已经确定答案,就完全跳过该节(未安装 `triage` 时跳过 B 节;不是 monorepo 时跳过 C 节)。
**A 节:Issue tracker。**
> 说明:“issue tracker”是当前仓库存放 issue 的地方。`to-tickets`、`triage` 和 `to-spec` 等技能会读写它。它们需要知道应该调用 `gh issue create`、在 `.scratch/` 下写 Markdown 文件,还是遵循你描述的其他工作流。请选择你在这个仓库中实际跟踪工作的地方。
默认立场:这些技能是为 GitHub 设计的。如果 `git remote` 指向 GitHub,就建议 GitHub。如果 `git remote` 指向 GitLab(`gitlab.com` 或自托管主机),就建议 GitLab。否则(或用户另有偏好),提供:
- **GitHub**:issue 存放在仓库的 GitHub Issues 中(使用 `gh` CLI) - **GitLab**:issue 存放在仓库的 GitLab Issues 中(使用 [`glab`](https://gitlab.com/gitlab-org/cli) CLI) - **本地 Markdown**:issue 作为文件存放在仓库的 `.scratch/<feature>/` 下(适合个人项目或没有 remote 的仓库) - **其他**(Jira、Linear 等):请用户用一段话描述工作流;技能会把它记录为自由格式文本
把选择记录到 `docs/agents/issue-tracker.md`。GitHub 和 GitLab 模板带有“把 PR 作为请求入口”的开关,默认**关闭**。保持关闭且不要主动提起:希望把外部 PR 纳入 triage 队列的用户以后可以自行在文件中打开它。
**B 节:Triage 标签词汇。** 如果没有安装 `triage` 技能(探索阶段已经得知),就完全跳过本节,因为未安装的技能不需要标签。
如果已安装,只问一个问题:
> 你想保留默认 triage 标签吗?(推荐:**是**)
默认值是五个标准角色,每个标签字符串都与角色名相同:`needs-triage`、`needs-info`、`ready-for-agent`、`ready-for-human`、`wontfix`。回答**是**时,原样写入。只有用户回答否时(通常因为 tracker 已经使用其他名称,例如用 `bug:triage` 表示 `needs-triage`),才收集覆盖值,使 `triage` 使用现有标签而不是创建重复标签。
**C 节:领域文档。** 默认使用**单一上下文(single-context)**(仓库根目录一个 `CONTEXT.md` 加 `docs/adr/`)。这适用于几乎所有仓库;无需提问,直接写入。
只有探索发现 monorepo 信号时,才提供**多上下文(multi-context)**方案(根目录 `CONTEXT-MAP.md` 指向各上下文的 `CONTEXT.md` 文件)。然后确认用户想要哪种布局。
### 3. 确认并编辑
向用户展示以下内容的草稿:
- 要添加到所编辑 `CLAUDE.md` / `AGENTS.md` 中的 `## Agent skills` 区块(选择规则见第 4 步) - `docs/agents/issue-tracker.md`、`docs/agents/domain.md` 和 `docs/agents/triage-labels.md` 的内容(最后一个仅在已安装 `triage` 时展示)
写入前允许用户修改草稿。
### 4. 写入
**选择要编辑的文件:**
- 如果存在 `CLAUDE.md`,编辑它。 - 否则,如果存在 `AGENTS.md`,编辑它。 - 如果两者都不存在,询问用户要创建哪一个;不要替用户选择。
当 `CLAUDE.md` 已存在时,绝不创建 `AGENTS.md`(反之亦然);始终编辑已经存在的那个文件。
如果所选文件中已经有 `## Agent skills` 区块,就原地更新其内容,而不是追加重复区块。不要覆盖周边小节中的用户编辑。
区块内容:
```markdown ## Agent skills
### Issue tracker
[一行总结 issue 在哪里跟踪]。参见 `docs/agents/issue-tracker.md`。
### Triage labels
[一行总结标签词汇]。参见 `docs/agents/triage-labels.md`。
### Domain docs
[一行总结布局:“single-context”或“multi-context”]。参见 `docs/agents/domain.md`。 ```
只有已安装 `triage` 且执行了 B 节时,才包含 `### Triage labels` 子区块并写入 `docs/agents/triage-labels.md`。否则两者都省略。
然后以本技能文件夹中的种子模板为起点写入文档文件:
- [issue-tracker-github.md](./issue-tracker-github.md):GitHub issue tracker - [issue-tracker-gitlab.md](./issue-tracker-gitlab.md):GitLab issue tracker - [issue-tracker-local.md](./issue-tracker-local.md):本地 Markdown issue tracker - [triage-labels.md](./triage-labels.md):标签映射(仅在已安装 `triage` 时) - [domain.md](./domain.md):领域文档使用方规则和布局
对于“其他”issue tracker,依据用户描述从头编写 `docs/agents/issue-tracker.md`。
### 5. 完成
告诉用户设置已完成,以及哪些工程技能现在会读取这些文件。说明以后可以直接编辑 `docs/agents/*.md`;只有想切换 issue tracker 或从头重新设置时,才需要再次运行此技能。

Entry SHA-256: 2bcd89e97777cdb705914424e39c97d5db524c8eb4eafac8120778a07774f0ec

2. Why This Skill Is Clever

一句话核心机制

把不同仓库会变化的“issue 放哪、标签叫什么、领域文档在哪”抽成可检查的仓库内 Markdown 配置,并用“先探查、再分段确认、最后写入”的交互事务建立它。

触发与调用边界

直接来源: frontmatter 规定它用于首次使用其他工程技能之前的一次性仓库配置,并设置 disable-model-invocation: true。正文进一步说明这是“prompt-driven skill, not a deterministic script”,必须在写入前探索、展示和确认。

支持性上下文: agents/openai.yaml 的 allow_implicit_invocation: false 与 frontmatter 一致,确认它只能由用户显式触发。配套 docs 说明用户通过 /setup-matt-pocock-skills 调用,但这不是所选原文的一部分。

解释: 该技能不是普通安装器。它配置的是当前目标仓库,而不是修改技能自身或创建全局偏好;任何实际执行都必须在目标仓库上下文中进行。

信息架构 / 执行顺序

  1. Explore: 读取 remote、现有 agent 指令、领域文档、ADR、旧配置、.scratch/、triage 安装状态和 monorepo 信号。
  2. Present findings and ask: 先总结事实,再按 A/B/C 顺序一次处理一个决策。
  3. Issue tracker: 根据 remote 推荐 GitHub、GitLab、本地 Markdown 或用户描述的其他系统,并把结果写入统一契约文件。
  4. Triage labels: 仅在安装了 triage 时询问,优先接受五个标准角色名。
  5. Domain docs: 普通仓库直接采用 single-context;只有发现 monorepo 证据才询问 multi-context。
  6. Confirm and edit: 先展示将写入的 instruction block 和配置文件草稿,允许用户修改。
  7. Write / Done: 按现有文件选择规则原地更新 agent 指令,写入模板派生文档,最后报告哪些技能会读取它们。

最巧妙的设计点

1. 先发现事实,再决定提问数量

“Read whatever exists; don't assume”

直接来源: 探索清单不仅收集输出所需数据,也决定后续哪些问题根本不该问:没有 triage 就跳过 B,没有 monorepo 信号就跳过 C。探索因此既是取证层,也是对话裁剪器。

2. 把推荐值设计成低摩擦的“接受路径”

“Lead each section with the recommended answer so the user can accept it in a word.”

直接来源: 它并不把灵活性等同于把所有选项平铺给用户。先给证据支持的建议,再只解释真正分叉的选择,能让常见仓库用极少确认完成设置。

3. 用条件节保持输出与能力一致

“Skip this section entirely if the triage skill isn't installed”

直接来源: 不存在的下游能力不会获得无用配置;同一条件同时控制问题、Agent skills 子区块和 triage-labels.md 文件,形成跨阶段一致的不变量。

4. 把环境差异移到数据文件,而不是复制流程逻辑

“Record the choice in docs/agents/issue-tracker.md.”

直接来源: GitHub、GitLab、本地 Markdown和“其他”最终都收敛到同一文件路径。下游技能可以读取稳定接口,而无需各自重新询问 tracker 或硬编码平台。

解释: 这是典型的策略外置:技能保留通用执行逻辑,仓库用可版本化 Markdown 提供环境策略。

5. 写入前设置显式的人类提交点

“Let them edit before writing.”

直接来源: 草稿必须包含将修改的 instruction block 和配置文件内容。用户确认发生在任何写入前,使多文件变更成为可预览的交互事务,而不是执行后通知。

6. 对已有用户文件采用最小侵入更新

“update its contents in-place rather than appending a duplicate”

直接来源: 文件选择优先复用已有 CLAUDE.md 或 AGENTS.md,已有区块原地更新,并明确不得覆盖周边用户编辑。这三条共同防止重复、分叉和大范围重写。

防失败机制与显式不变量

直接来源:

取舍、可移植风险与宿主假设

解释: CLAUDE.md 优先于 AGENTS.md 是明确但与宿主相关的假设:若当前 harness 只读取后者,而仓库恰好保留前者,配置入口可能写到错误位置。GitHub/GitLab 检测依赖 Git remote,monorepo 判断也只覆盖列出的信号,非 Node 生态的大型仓库可能被误判为 single-context。正文给出模板链接,却没有在同一文件中定义模板内容的版本迁移策略;重复运行时如何合并用户对 docs/agents/*.md 的深度定制仍需谨慎。流程还依赖用户能够逐轮回答,因此不适合无人值守地直接应用到任意仓库。

可迁移原则

  1. 把跨环境差异做成稳定的仓库内契约。 下游流程只读固定路径,平台差异留在配置数据里。
  2. 让探索决定问题,而不是只决定答案。 已有证据能消除的选择就不要再询问。
  3. 为常见路径提供一词确认。 默认值应有证据支持,同时保留真正需要的分支。
  4. 用同一条件贯穿问答、渲染和写入。 可选能力关闭时,所有相关输出都必须一致消失。
  5. 多文件写入前先展示完整草稿。 把确认变成事务提交点。
  6. 编辑用户文件时优先局部、幂等更新。 找到稳定区块并原地更新,不追加副本,也不重写邻接内容。

今日实践题

如果一个仓库同时存在 CLAUDE.md 和 AGENTS.md,但当前运行环境只读取 AGENTS.md,你会如何改造“优先编辑 CLAUDE.md”这条规则,同时保持一次只维护一个权威配置入口?

Evidence note

本文关于触发条件、五阶段流程、问题跳过、默认策略、文件选择、模板和写入边界的结论来自所选 SKILL.md。agents/openai.yaml 仅用于佐证禁止隐式调用;docs 页面只用于理解公开调用方式和已知权衡,未作为原文展示。关于策略外置、交互事务、宿主错位风险和迁移原则属于设计解释。

Source & provenance
Repository path
skills/engineering/setup-matt-pocock-skills/SKILL.md
Generated
2026-08-21 08:23 Asia/Shanghai
Upstream commit
0ab1b63a410a03d3627979a109c8695de27af954
Source
View on GitHub