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

setup-matt-pocock-skills

General & other

View repository

Updated 10-15 21:08

About this skill

Set up Matt Pocock's skills

Set up the per-repository configuration that the engineering skills depend on:

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

This is a prompt-driven skill, not a deterministic script. Explore, present your findings, confirm with the user, then write.

Process

1. Explore

Look at the current repository to understand its starting state. Read everything that exists; do not assume:

  • git remote -v and .git/config — is this a GitHub repository? Which one?
  • Repository root AGENTS.md and CLAUDE.md — do they exist? Is there already a ## Agent skills section in them?
  • Repository root GLOSSARY.md and GLOSSARY-MAP.md
  • docs/adr/ and any src/*/docs/adr/ directories
  • docs/agents/ — does output from a previous run of this skill already exist?
  • .scratch/ — signs that a local markdown issue tracker convention is already in use
  • triage Is the skill installed? (A triage skill folder alongside this skill folder, or triageamong your available skills.) This determines whether Section B runs.
  • Monorepo signals — there is pnpm-workspace.yaml、package.json contains a workspaces field, or there are src/ with their own packages/*. Only appears in genuinely large multi-package repositories; without them it is single-context, and almost all repositories are single-context.

2. Present findings and ask

Summarize what exists and what is missing. Then go through the sections in order — one section, one answer, then the next section.

Start each section with a recommended answer so the user can accept it with a single word. Only give a one-line explanation when the choice genuinely forks; skip a section entirely when exploration has already resolved it (skip Section B when triage is not installed, skip Section C when there is no monorepo).

Section A — Issue tracker.

Explanation: this repository's "issue tracker" is where issues live.to-tickets、triage、to-spec and other skills read and write it — they need to know whether to call gh issue create, write markdown files under .scratch/ , or follow some other workflow you describe. Pick a place where you actually track work for this repository.

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

  • GitHub — issues live in the repository's GitHub Issues (using gh CLI）
  • GitLab — issues live in the repository's GitLab Issues (using glab CLI）
  • Local markdown — issues live in this repository as files under .scratch/<feature>/ (good for solo projects or repositories with no remote)
  • Other(Jira, Linear, etc.) — have the user describe the workflow in a paragraph; the skill records it as free text

Record the choice in docs/agents/issue-tracker.md. The GitHub and GitLab templates carry the "PRs as a request surface" flag, which is off by defaultoff—leave it off and do not bring it up; users who want external PRs to enter the triage queue can turn this flag on in the file later.

Section B — Triage label vocabulary. If the triage skill is not installed (exploration has already told you), skip the whole section—an uninstalled skill does not need labels.

If it is installed, ask just one question:

Do you want to keep the default triage labels? (Recommended:Yes）

The default is the five canonical roles, with each label string equal to its role name:needs-triage、needs-info、ready-for-agent、ready-for-human、wontfix. ChooseYes, and write them in as-is. Only when the user says no—usually because their tracker already uses different names (for example, using bug:triage for needs-triage)—collect the overrides, so that triage applies existing labels rather than creating duplicates.

Section C — Domain documentation. Default issingle-context—one GLOSSARY.md + docs/adr/at the repository root. This fits almost every repository; write it without asking.

Only when exploration finds monorepo signals, offermulti-context—a root-level GLOSSARY.md pointing to each context's GLOSSARY-MAP.mdfile. Then confirm which layout they want.

3. Confirm and edit

Show the user the draft:

  • The CLAUDE.md / AGENTS.md block to add to the file being edited in ## Agent skills (see step 4 for selection rules)
  • docs/agents/issue-tracker.md、docs/agents/domain.md and the contents of docs/agents/triage-labels.md (the latter only when triage is installed)

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—do not choose for them.

When CLAUDE.md already exists, never create AGENTS.md(and vice versa)—always edit the one that already exists.

If the chosen file already has a ## Agent skills block, update its contents in place rather than appending a duplicate. Do not overwrite the user's edits to surrounding sections.

The block:

## 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`.

Only when triage is installed and Section B was performed, include the ### Triage labels sub-block and write docs/agents/triage-labels.md. Otherwise omit both.

If Section B was performed on GitHub or GitLab, create each configured label that does not already exist in the tracker (gh label create / glab label create）。

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

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

5. Done

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