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

setup-matt-pocock-skills

Coding & development

View repository

Updated 10-16 06:07

About this skill

Setup Matt Pocock's Skills

Scaffold the per-repo configuration that the engineering skills assume:

  • Issue tracker: where issues live (GitHub by default; local markdown is also supported out of the box)
  • 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 prompt-driven skill, not a deterministic script. Explore, present what you found, confirm only choices that are still open, 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?
  • The active harness's documented instruction file (for example AGENTS.md or CLAUDE.md): does it already contain an ## Agent skills section?
  • 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 sign that 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/. Treat these as package-layout evidence; their absence does not rule out multiple documented contexts.

2. Present findings and ask

Summarise what's present and what's missing. Record choices already established by repository files or the active harness, then ask only for choices that remain open. Take the sections in order, one section and one answer at a time when an answer is needed.

Lead each open section with the recommended answer 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 the layout is already documented).

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.

Default posture: 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 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. If that file already exists, preserve its repo-specific conventions and edit only what the confirmed choice requires. The GitHub and GitLab templates carry a "PRs as a request surface" 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 and the label vocabulary is not already determined by the repo or harness, 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), collect the overrides so triage applies existing labels instead of creating duplicates. If the repo or harness already determines the vocabulary, preserve it and do not ask again.

Section C: Domain docs. Use the existing documented single- or multi-context layout when it is settled. If it is not settled, propose the layout from the repository's actual domains, structure, and context-map signals; do not choose single-context merely because multiple-context documentation is absent. Confirm only when that choice remains open.

When the layout is not settled, a repository without existing multiple-context documentation may still choose multi-context if its actual domains and structure warrant it; do not default from the absence of a CONTEXT-MAP.md alone.

3. Confirm and edit

Show the user a draft of the intended changes when a real choice or material edit remains. When the harness or the user's request already determines the target, show the edit and proceed without adding an approval ritual:

  • The ## Agent skills block to add to the instruction file actually consumed by the active harness (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)

When a choice remains open, let them edit before writing. When the target is already determined, proceed with the shown edit without inventing another approval ritual.

4. Write

Pick the file to edit:

  • Edit the instruction file the active harness actually consumes, using its documented precedence. For Codex, create or edit AGENTS.md when that is the documented repo-instruction file, even if CLAUDE.md also exists; preserve the other file.
  • If exactly one existing instruction file is compatible with the harness, use it without asking. If both exist and the harness documents no precedence, report the gap and ask only that real choice.
  • If neither instruction file exists and the harness names its target, create that target; otherwise ask the user which one to create.

If an ## Agent skills block already exists in the chosen file, update its contents in-place rather than appending a duplicate. Don't overwrite user edits to the 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`.

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 using the seed templates in this skill folder as a starting point:

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.