SuperAPI AI Directory

setup-matt-pocock-skills

Coding & development

View repository

Updated 10-15 21:08

About this skill

Set up Matt Pocock's engineering skills

Scaffold the repository-level configuration needed by the engineering skills:

  • Issue tracker — where issues are stored (GitHub by default; local markdown is also supported out of the box)
  • Taxonomy labels — the actual label strings corresponding to the five standard taxonomy roles
  • Domain documentation —— CONTEXT.md and ADRs, and the reading rules

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

Process

1. Explore

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

  • git remote -v and .git/config — is this a GitHub repository? Which one specifically?
  • In the repository root, AGENTS.md and CLAUDE.md — do they exist? Do they already contain a ## Agent skills section?
  • In the repository root, CONTEXT.md and CONTEXT-MAP.md
  • docs/adr/ and any src/*/docs/adr/ directories
  • docs/agents/ — does output from previous runs of this skill already exist?
  • .scratch/ — a sign that a local markdown issue tracking scheme is already in use

2. Present findings and ask questions

Summarize what already exists and what is missing. Thenone by oneguide the user through three decisions — present only one section at a time, and move on to the next only after getting the user's answer. Do not throw all three at them at once.

Assume the user does not know what these terms mean. Start each section with a brief explanation (what it is, why these skills need it, what changes depending on the choice), then show the options and defaults.

Part A — Issue tracker.

Explanation: The issue tracker is where this repository's issues are stored.to-issues、triage、to-prd and qa and other skills read from and write to it — they need to know whether to call gh issue create, write markdown files into the .scratch/ directory, or follow some other workflow you describe. Choose where you actually track work for this repository.

Default preference: 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 address), recommend GitLab. Otherwise (or if the user has a preference), offer the following options:

  • GitHub — issues are stored in the repository's GitHub Issues (using gh CLI)
  • GitLab — issues are stored in the repository's GitLab Issues (using glab CLI)
  • Local markdown — issues are stored as files in this repository under .scratch/<feature>/ (suitable for personal projects or projects with no remote repository)
  • Other(Jira, Linear, etc.) — ask the user to describe the workflow in a paragraph, and the skill will record it as free text

Part B — Taxonomy label vocabulary.

Explanation: When triage When the skill processes an incoming issue, it moves the issue through a state machine—needs triage, waiting for the reporter's reply, can be picked up by an AFK agent, needs human implementation, or won't fix. To do this, it needs to apply labels consistent withthe labels you actually have configured. If your repository already uses different label names (for example bug:triage instead of needs-triage), map them here so the skill uses the correct labels instead of creating duplicate labels.

Five standard roles:

  • needs-triage — maintainer needs to triage
  • needs-info — waiting for the reporter to provide more information
  • ready-for-agent — spec is complete and AFK-ready (an agent can pick it up without human context)
  • ready-for-human — needs human implementation
  • wontfix — won't fix

Default: each role's label string equals its name. Ask the user whether any need to be overridden. If their issue tracker has no labels yet, the defaults are fine.

Part C — Domain documentation.

Explanation: some skills (improve-codebase-architecture、diagnose、tdd) read the CONTEXT.md file to learn the project's domain language, and docs/adr/ to learn past architecture decisions. They need to know whether the repository uses a single global context or multiple contexts (for example a monorepo with both frontend and backend contexts), so they can look in the right places.

Confirm the layout:

  • Single context — there is only one CONTEXT.md + docs/adr/at the repository root. Most repositories are like this.
  • Multiple contexts — the CONTEXT-MAP.md at the root points to separate CONTEXT.md files (usually used for monorepos).

3. Confirm and edit

Show the user the following draft:

  • The CLAUDE.md / AGENTS.mdblock to add to ## Agent skills (for selection rules, see step 4)
  • docs/agents/issue-tracker.md、docs/agents/triage-labels.md、docs/agents/domain.md contents of

Let the user modify it 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.

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

If the selected file already has a ## Agent skills block, update its contents in place instead of appending another duplicate block. Do not overwrite the user's modifications to surrounding paragraphs.

The contents of the block:

## Agent skills

### Issue tracker

[对 issue 跟踪位置的一句话总结]。详见 `docs/agents/issue-tracker.md`。

### Triage labels

[对标签词汇的一句话总结]。详见 `docs/agents/triage-labels.md`。

### Domain docs

[对布局的一句话总结——"单上下文"或"多上下文"]。详见 `docs/agents/domain.md`。

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

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

5. Finish

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