SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillssetup-matt-pocock-skills

setup-matt-pocock-skills

Agents & models

View repository

Updated 10-15 23:44

About this skill

Set up Matt Pocock's skills

Set up every repo configuration the engineering skills assume:

  • Issue tracker— where issues live (defaults to GitHub; local markdown also works out of the box)
  • Triage labels— the strings used for the five canonical triage roles
  • Domain docs——CONTEXT.md and where ADRs live, plus the consumer rules for reading them

This is a prompt-driven skill, not a deterministic script. Explore, show what you find, confirm with the user, then write.

Process

1. Explore

Look at the current repo to understand its starting state. Read whatever exists; don't assume:

  • git remote -v and .git/config— is this a GitHub repo? Which one?
  • Repo root's AGENTS.md and CLAUDE.md— does either exist? Does it already have a ## Agent skills section?
  • Repo root's CONTEXT.md and CONTEXT-MAP.md
  • docs/adr/ and any src/*/docs/adr/ directory
  • docs/agents/— does prior output from this skill already exist?
  • .scratch/— indicates a local markdown issue tracker convention is already in use

2. Show findings and ask

Summarize what exists and what's missing. Then guide the userone at a timethrough the three decisions—show one section, get the user's answer, then move to the next. Don't throw all three at them at once.

Assume the user doesn't know what these terms mean. Start each section with a brief explanation (what it is, why these skills need it, what changes if they choose differently). Then show the options and defaults.

Part A—Issue tracker.

Explainer: an "issue tracker" is where this repo's issues live. Skills like to-issues、triage、to-prd and qa read from and write to it—they need to know whether to call gh issue create, write markdown files under .scratch/ , or follow some other workflow you describe. Choose where you actually track work for this repo.

Default stance: these skills are designed for GitHub. If git remote points to GitHub, propose that. If git remote points to GitLab (gitlab.com or self-hosted host), propose GitLab. Otherwise (or if the user prefers), offer:

  • GitHub— issues live in the repo's GitHub Issues (using gh CLI）
  • GitLab— issues live in the repo's GitLab Issues (using glab CLI）
  • Local markdown— issues live as files under .scratch/<feature>/ in this repo (good for personal projects or repos with no remote)
  • Other(Jira, Linear, etc.)—ask the user to describe the workflow in a paragraph; the skill will record it as free-form prose

Part B—Triage label vocabulary.

Explainer: when triage When the skill processes an incoming issue, it moves it through a state machine—needs triage, waiting on reporter, ready for AFK agent to pick up, ready for human, or won't fix. To do that, it needs to apply labels that match the strings in youractually configured(or the equivalent in your issue tracker). If your repo already uses different label names (e.g. bug:triage instead of needs-triage), map them here so the skill applies the correct labels instead of creating duplicates.

Five canonical roles:

  • needs-triage— maintainer needs to triage
  • needs-info— waiting on reporter
  • ready-for-agent— fully specified, AFK-ready (agent can pick it up without human context)
  • ready-for-human— needs human implementation
  • wontfix— no action will be taken

Default: each role's string equals its name. Ask the user if they want to override any. If their issue tracker has no existing labels, the defaults are fine.

Part C—domain documentation.

Interpreter: some skills (improve-codebase-architecture、diagnose、tdd) read the CONTEXT.md file to learn the project's domain language, and docs/adr/ for past architectural decisions. They need to know whether the repo has one global context or multiple (e.g. a monorepo with separate frontend/backend contexts), so they look in the right place.

Confirm the layout:

  • Single-context— one CONTEXT.md + docs/adr/at the repo root. Most repos are like this.
  • Multi-context— the root CONTEXT-MAP.md points to each context's CONTEXT.md file (usually a monorepo).

3. Confirm and edit

Show the user the draft:

  • To be added to the CLAUDE.md / AGENTS.md being edited ## Agent skills block (see the selection rules in step 4)
  • docs/agents/issue-tracker.md、docs/agents/triage-labels.md、docs/agents/domain.md contents

Let them edit before writing.

4. Write

Choose the file to edit:

  • If CLAUDE.md exists, edit it.
  • Otherwise, if AGENTS.md exists, edit it.
  • If neither exists, ask the user which one to create—don't choose for them.

Never create CLAUDE.md when AGENTS.mdalready exists (or vice versa)—always edit the one that already exists.

If the ## Agent skills block already exists in the chosen file, update its contents in place instead of appending a duplicate. Don't overwrite the user's edits to surrounding sections.

The block:

## Agent skills

### Issue tracker

[一行摘要说明 issue 跟踪的位置]。参见 `docs/agents/issue-tracker.md`。

### 分类标签

[标签词汇的一行摘要]。参见 `docs/agents/triage-labels.md`。

### 领域文档

[布局的一行摘要——"单上下文"或"多上下文"]。参见 `docs/agents/domain.md`。

Then write three documentation files using the seed templates in this skill folder as a starting point:

For "other" issue trackers, write docs/agents/issue-tracker.md。

5. Done

Tell the user setup is complete and which engineering skills will now read from these files. Mention that they can edit docs/agents/*.mddirectly later—they only need to rerun this skill if they want to switch issue trackers or start from scratch.