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

setup-matt-pocock-skills

Agents & models

View repository

Updated 10-16 09:17

About this skill

Configure Matt Pocock's Skills

Set up the per-repo configuration that the engineering skills assume:

  • Issue tracker - where issues live (GitHub by default; local markdown also natively supported)
  • Triage labels - the strings used by the five canonical triage roles
  • Domain docs - GLOSSARY.md and the location of ADRs, plus the consumer rules that read them

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

Process

1. Explore

Look at the current repo to understand the starting state. Read what already exists; do not assume:

  • git remote -v and .git/config - is this a GitHub repo? Which one?
  • repo root's AGENTS.md and CLAUDE.md - do they exist? Do they already contain ## Agent skills section？
  • repo root's GLOSSARY.md and GLOSSARY-MAP.md
  • docs/adr/ and any src/*/docs/adr/ directories
  • docs/agents/ - has this skill previously output content?
  • .scratch/ - indicate the local-markdown issue tracker convention is already in use
  • Is triage skill installed (a triage folder next to this skill, or triagepresent among available skills)? This determines whether Section B runs.
  • Monorepo signals：pnpm-workspace.yaml、package.json of workspaces field, or existing content that each carry src/ of packages/*. Only genuinely large multi-package repos count; without these signals it is single-context, which is true of almost all repos.

2. Present findings and ask

Summarize what already exists and what is missing. Handle sections in order: one section at a time, one answer, then move to the next.

For each section, give the recommended answer first, so the user can accept it with one word. Only give a one-line explainer when the choice genuinely branches; skip the whole section when exploration has already determined the answer (skip Section B when triage is not installed; skip Section C when there is no monorepo).

Section A - Issue tracker.

Explainer: the "issue tracker" is where this repo stores its issues.to-tickets、triage and to-spec and other skills 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, recommend GitHub. If git remote points to GitLab (gitlab.com or a self-hosted host), recommend GitLab. Otherwise (or if the user prefers), offer:

  • GitHub - issues live in the repo's GitHub Issues (use gh CLI）
  • GitLab - issues live in the repo's GitLab Issues (use glab CLI）
  • Local markdown - issues live as files under this repo's .scratch/<feature>/ (good for personal projects or repos without a remote)
  • Other(Jira, Linear, etc.) - have the user describe the workflow in a paragraph; the skill records it as freeform prose

Record the choices in docs/agents/issue-tracker.md. The GitHub and GitLab templates carry a "PRs as a request surface" flag, defaulting to off; keep it closed and do not ask questions. Users who want to put external PRs into the triage queue can modify the file directly afterward.

Section B - Triage label vocabulary. If not installed, triage, skip this section entirely; uninstalled skills do not need labels.

If installed, ask only one question:

Keep the default triage labels? (recommended: yes）

The default is five canonical roles, with the label string the same as the role name:needs-triage、needs-info、ready-for-agent、ready-for-human、wontfix. If the answer is yes, write them as-is. Only when the user says no (usually because the tracker already uses other names, for example using bug:triage for needs-triage) should you collect overrides, to avoid triage creating duplicate labels.

Section C - Domain docs. Default single-context: one under the repo root GLOSSARY.md + docs/adr/. This suits almost every repo; write it directly without asking.

Only when exploration finds monorepo signals, offer multi-context(under root, GLOSSARY-MAP.md points to each context's GLOSSARY.md files), and confirm which layout the user wants.

3. Confirm and edit

Show the user the draft:

  • To add to CLAUDE.md / AGENTS.md the ## Agent skills block (see step 4 for selection rules)
  • docs/agents/issue-tracker.md、docs/agents/domain.md, and only when triage is installed, the docs/agents/triage-labels.md content

Allow the user to make changes 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 the user.

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 block. Do not overwrite user edits in surrounding sections.

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 include when triage is installed and Section B actually runs ### Triage labels sub-block and write docs/agents/triage-labels.md; otherwise omit both.

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

For "other" issue trackers, write from scratch based on the user's description docs/agents/issue-tracker.md。

5. Done

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