Set Up Matt Pocock Skills
Set up per-repository configurations that engineering skills depend on:
- Issue Tracker — Where issues are stored (default: GitHub; local markdown works out of the box)
- Triage Labels — Label strings used for the five standard triage roles
- Domain Documentation — Where and ADRs are stored, as well as 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. Exploration
Check the current repository to understand its starting state. Read everything that exists; don't make assumptions:
- and — Is this a GitHub repository? Which one?
- and in the repository root — Do they exist? Do they already have a section?
- and in the repository root
- and any directories
- — Does output from a previous run of this skill already exist?
- — Signs indicating that the local markdown issue tracker convention is in use
- Is the skill installed? (A skill folder alongside this skill folder, or in your available skills.) This determines whether Section B is executed.
- Monorepo signals — Presence of , a field in , or with their own . Only present in truly large multi-package repositories; without them, it's a single context, and almost all repositories are single-context.
2. Present Findings and Ask
Summarize what exists and what's missing. Then go through each section in order — one section, one answer, then the next.
Start each section with a recommended answer so the user can accept it with a single word. Only provide a one-line explanation if the choice actually branches; skip the entire section if exploration has already resolved it (skip Section B if
is not installed, skip Section C if there's no monorepo).
Section A — Issue Tracker.
Explanation: The "issue tracker" for this repository is where issues are stored. Skills like
,
,
will read from and write to it — they need to know whether to call
, write markdown files under
, or follow another workflow you describe. Choose the location where you actually track work for this repository.
Default stance: These skills are designed for GitHub. If
points to GitHub, propose GitHub. If
points to GitLab (
or self-hosted), propose GitLab. Otherwise (or if the user prefers), provide:
- GitHub — Issues are stored in the repository's GitHub Issues (uses CLI)
- GitLab — Issues are stored in the repository's GitLab Issues (uses CLI)
- Local Markdown — Issues exist as files under in this repository (suitable for solo projects or repositories without a remote)
- Other (Jira, Linear, etc.) — Ask the user to describe the workflow in a paragraph; the skill will record it as free text
Record the choice in
docs/agents/issue-tracker.md
. GitHub and GitLab templates come with a "PRs as a request surface" flag, which is
off by default — keep it off and don't mention it; users who want external PRs to be added to the triage queue can turn this flag on in the file later.
Section B — Triage Label Vocabulary. If the
skill is not installed (as exploration has told you), skip this entire section — uninstalled skills don't need labels.
If it is installed, ask only one question:
Do you want to keep the default triage labels? (Recommended: Yes)
The default values are the five standard roles, with each label string equal to its role name:
,
,
,
,
. If
Yes is selected, write them as-is. Only if the user says No — usually because their tracker already uses other names (e.g.,
instead of
) — collect overrides so
will apply existing labels instead of creating duplicates.
Section C — Domain Documentation. Default is
single-context — one
+
at the repository root. This is suitable for almost all repositories; write it without asking.
Only if exploration finds monorepo signals, offer
multi-context — a root-level
pointing to each context's
file. Then confirm which layout they want.
3. Confirm and Edit
Show the user the draft:
- The block to be added to either / (selection rules are in Step 4)
- Contents of
docs/agents/issue-tracker.md
docs/agents/triage-labels.md
Let them edit before writing.
4. Write
Choose the file to edit:
- If exists, edit it.
- Otherwise, if exists, edit it.
- If neither exists, ask the user which one to create — don't choose for them.
Never create
if
exists (and vice versa) — always edit the one that already exists.
If the selected file already has a
block, update its content in place instead of appending a duplicate. Don't overwrite the user's edits to 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`.
Only include the
sub-block and write
docs/agents/triage-labels.md
if
is installed and Section B was executed. Otherwise, omit both.
Then write the documentation files using the seed templates in this skill folder as a starting point:
- issue-tracker-github.md — GitHub issue tracker
- issue-tracker-gitlab.md — GitLab issue tracker
- issue-tracker-local.md — Local markdown issue tracker
- triage-labels.md — Label mapping (only if is installed)
- domain.md — Domain documentation consumption rules + layout
For "Other" issue trackers, write
docs/agents/issue-tracker.md
from scratch using the user's description.
5. Complete
Tell the user the setup is complete, and which engineering skills will now read these files. Mention that they can edit
directly later — they only need to re-run this skill if they want to switch issue trackers or start over.