mirror of
https://github.com/mattpocock/skills.git
synced 2026-04-30 22:13:54 +07:00
Compare commits
2 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 Matt Pocock
|
b7bf8cc3c1 | ||
|
Matt Pocock
|
d0592f4cfb |
@@ -2,10 +2,10 @@
|
||||
"name": "mattpocock-skills",
|
||||
"skills": [
|
||||
"./skills/engineering/diagnose",
|
||||
"./skills/engineering/github",
|
||||
"./skills/engineering/grill-with-docs",
|
||||
"./skills/engineering/triage",
|
||||
"./skills/engineering/improve-codebase-architecture",
|
||||
"./skills/engineering/setup-matt-pocock-skills",
|
||||
"./skills/engineering/triage",
|
||||
"./skills/engineering/tdd",
|
||||
"./skills/engineering/to-issues",
|
||||
"./skills/engineering/to-prd",
|
||||
|
||||
@@ -1,25 +0,0 @@
|
||||
# Issue tracker integrations are limited to mainstream tools
|
||||
|
||||
`setup-matt-pocock-skills` only offers first-class support for **mainstream** issue trackers. Requests to add support for niche, new, or single-vendor experimental trackers are out of scope.
|
||||
|
||||
## Why this is out of scope
|
||||
|
||||
Every issue-tracker backend hard-codes a CLI shape into the skills (commands, flags, output parsing). Each new backend is permanent maintenance surface — it has to keep working as the tool's CLI evolves, and it has to keep being tested against `/to-prd`, `/to-issues`, `/triage`, and friends. That cost is only worth paying for trackers a meaningful fraction of users actually have.
|
||||
|
||||
"Mainstream" is a judgment call, not a numeric bar:
|
||||
|
||||
- GitHub, GitLab, and Backlog.md are the kind of tools we'd consider mainstream — broadly known, widely used, well past the experimental phase.
|
||||
- A brand-new agent-focused tool with a few hundred GitHub stars is not, no matter how interesting the design.
|
||||
|
||||
Stars, age, and download counts are useful signals when making the call but none of them is the rule. The rule is: would a typical engineer recognise this tool and have plausibly chosen it for their team?
|
||||
|
||||
The escape hatches for non-mainstream trackers already exist:
|
||||
|
||||
- `local markdown` for lightweight in-repo tracking.
|
||||
- `other/custom` for users who want to wire something up themselves.
|
||||
|
||||
Neither requires the core skills to know about the specific tool.
|
||||
|
||||
## Prior requests
|
||||
|
||||
- #99 — "Add dex as an issue tracker backend" (dex was ~3 months old and ~300 stars at the time of the request)
|
||||
@@ -1,18 +0,0 @@
|
||||
# Hard limits on the number of questions during grilling
|
||||
|
||||
The `/grill-me` skill (and grilling sessions inside other skills) does not enforce a maximum number of questions. Requests to add a configurable cap or hard ceiling are out of scope.
|
||||
|
||||
## Why this is out of scope
|
||||
|
||||
Grilling is intentionally open-ended. The point is to keep digging until each branch of the decision tree is resolved — some plans need three questions, some need fifty. A fixed cap would either cut off useful exploration on hard problems or feel arbitrary on easy ones.
|
||||
|
||||
If a session feels too long, the right escape hatches already exist:
|
||||
|
||||
- The user can stop the session at any time and accept the current state of the plan.
|
||||
- The user can tell the model to wrap up, summarise, and move on — natural-language steering is the intended control surface, not a numeric limit.
|
||||
|
||||
Adding a hard cap would also conflate two different failure modes: a model that asks too many questions because the plan is genuinely under-specified (working as intended) vs. a model that asks redundant or low-value questions (a prompt-quality issue, not a quantity issue). The fix for the latter belongs in the skill prompt, not in a counter.
|
||||
|
||||
## Prior requests
|
||||
|
||||
- #44 — "Codex just asked me 200 questions"
|
||||
@@ -1,15 +0,0 @@
|
||||
# Verify/Check Mode for `setup-matt-pocock-skills`
|
||||
|
||||
This project will not add a dedicated verify/check mode (or a separate verify skill) for `setup-matt-pocock-skills`.
|
||||
|
||||
## Why this is out of scope
|
||||
|
||||
A second skill — or a `--verify` flag — for checking whether `docs/agents/*.md` artifacts still match the seed-template schema would duplicate work the existing setup skill already handles in conversation.
|
||||
|
||||
The intended workflow is: **run `/setup-matt-pocock-skills` and tell it to verify your current setup.** The skill is prompt-driven, so the maintainer can scope it to a verification pass ("don't rewrite anything, just check my existing files against the current seed templates and report drift") without needing a separate code path. Adding a flag or a sibling skill would split the surface area of a feature that's already expressible through the natural-language entry point.
|
||||
|
||||
Keeping configuration management to a single skill also avoids the maintenance cost of two skills drifting from each other when seed templates evolve.
|
||||
|
||||
## Prior requests
|
||||
|
||||
- #106 — Feature request: verify/check mode for setup-matt-pocock-skills
|
||||
-26
@@ -1,26 +0,0 @@
|
||||
# Matt Pocock Skills
|
||||
|
||||
A collection of agent skills (slash commands and behaviors) loaded by Claude Code. Skills are organized into buckets and consumed by per-repo configuration emitted by `/setup-matt-pocock-skills`.
|
||||
|
||||
## Language
|
||||
|
||||
**Issue tracker**:
|
||||
The tool that hosts a repo's issues — GitHub Issues, Linear, a local `.scratch/` markdown convention, or similar. Skills like `to-issues`, `to-prd`, `triage`, and `qa` read from and write to it.
|
||||
_Avoid_: backlog manager, backlog backend, issue host
|
||||
|
||||
**Issue**:
|
||||
A single tracked unit of work inside an **Issue tracker** — a bug, task, PRD, or slice produced by `to-issues`.
|
||||
_Avoid_: ticket (use only when quoting external systems that call them tickets)
|
||||
|
||||
**Triage role**:
|
||||
A canonical state-machine label applied to an **Issue** during triage (e.g. `needs-triage`, `ready-for-afk`). Each role maps to a real label string in the **Issue tracker** via `docs/agents/triage-labels.md`.
|
||||
|
||||
## Relationships
|
||||
|
||||
- An **Issue tracker** holds many **Issues**
|
||||
- An **Issue** carries one **Triage role** at a time
|
||||
|
||||
## Flagged ambiguities
|
||||
|
||||
- "backlog" was previously used to mean both the *tool* hosting issues and the *body of work* inside it — resolved: the tool is the **Issue tracker**; "backlog" is no longer used as a domain term.
|
||||
- "backlog backend" / "backlog manager" — resolved: collapsed into **Issue tracker**.
|
||||
@@ -1,14 +1,4 @@
|
||||
<p>
|
||||
<a href="https://www.aihero.dev/s/skills-newsletter">
|
||||
<picture>
|
||||
<source media="(prefers-color-scheme: dark)" srcset="https://res.cloudinary.com/total-typescript/image/upload/v1777382277/skills-repo-dark_2x.png">
|
||||
<source media="(prefers-color-scheme: light)" srcset="https://res.cloudinary.com/total-typescript/image/upload/v1777382277/skill-repo-light_2x.png">
|
||||
<img alt="Skills" src="https://res.cloudinary.com/total-typescript/image/upload/v1777382277/skill-repo-light_2x.png" width="369">
|
||||
</picture>
|
||||
</a>
|
||||
</p>
|
||||
|
||||
# Skills For Real Engineers
|
||||
# Agent Skills For Real Engineers
|
||||
|
||||
My agent skills that I use every day to do real engineering - not vibe coding.
|
||||
|
||||
@@ -28,14 +18,9 @@ If you want to keep up with changes to these skills, and any new ones I create,
|
||||
npx skills@latest add mattpocock/skills
|
||||
```
|
||||
|
||||
2. Pick the skills you want, and which coding agents you want to install them on. **Make sure you select `/setup-matt-pocock-skills`**.
|
||||
2. Pick the skills you want, and which coding agents you want to install them on.
|
||||
|
||||
3. Run `/setup-matt-pocock-skills` in your agent. It will:
|
||||
- Ask you which issue tracker you want to use (GitHub, Linear, or local files)
|
||||
- Ask you what labels you apply to ticks when you triage them (`/triage` uses labels)
|
||||
- Ask you where you want to save any docs we create
|
||||
|
||||
4. Bam - you're ready to go.
|
||||
3. Bam - you're ready to go.
|
||||
|
||||
## Why These Skills Exist
|
||||
|
||||
@@ -145,13 +130,13 @@ Software engineering fundamentals matter more than ever. These skills are my bes
|
||||
Skills I use daily for code work.
|
||||
|
||||
- **[diagnose](./skills/engineering/diagnose/SKILL.md)** — Disciplined diagnosis loop for hard bugs and performance regressions: reproduce → minimise → hypothesise → instrument → fix → regression-test.
|
||||
- **[github](./skills/engineering/github/SKILL.md)** — GitHub backend for the engineering skills. Publishes PRDs and issues, applies triage outcomes via `gh`.
|
||||
- **[grill-with-docs](./skills/engineering/grill-with-docs/SKILL.md)** — Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates `CONTEXT.md` and ADRs inline.
|
||||
- **[triage](./skills/engineering/triage/SKILL.md)** — Triage issues through a state machine of triage roles.
|
||||
- **[improve-codebase-architecture](./skills/engineering/improve-codebase-architecture/SKILL.md)** — Find deepening opportunities in a codebase, informed by the domain language in `CONTEXT.md` and the decisions in `docs/adr/`.
|
||||
- **[setup-matt-pocock-skills](./skills/engineering/setup-matt-pocock-skills/SKILL.md)** — Scaffold the per-repo config (issue tracker, triage label vocabulary, domain doc layout) that the other engineering skills consume. Run once per repo before using `to-issues`, `to-prd`, `triage`, `diagnose`, `tdd`, `improve-codebase-architecture`, or `zoom-out`.
|
||||
- **[tdd](./skills/engineering/tdd/SKILL.md)** — Test-driven development with a red-green-refactor loop. Builds features or fixes bugs one vertical slice at a time.
|
||||
- **[to-issues](./skills/engineering/to-issues/SKILL.md)** — Break any plan, spec, or PRD into independently-grabbable GitHub issues using vertical slices.
|
||||
- **[to-prd](./skills/engineering/to-prd/SKILL.md)** — Turn the current conversation context into a PRD and submit it as a GitHub issue. No interview — just synthesizes what you've already discussed.
|
||||
- **[to-issues](./skills/engineering/to-issues/SKILL.md)** — Break any plan, spec, or PRD into independently-grabbable issues using vertical slices. Hands off to a backend skill (`/github`) to publish.
|
||||
- **[to-prd](./skills/engineering/to-prd/SKILL.md)** — Turn the current conversation context into a PRD. Hands off to a backend skill (`/github`) to publish. No interview — just synthesizes what you've already discussed.
|
||||
- **[triage](./skills/engineering/triage/SKILL.md)** — Triage issues through a label-based state machine. Backend-agnostic — pairs with `/github` to apply outcomes.
|
||||
- **[zoom-out](./skills/engineering/zoom-out/SKILL.md)** — Tell the agent to zoom out and give broader context or a higher-level perspective on an unfamiliar section of code.
|
||||
|
||||
### Productivity
|
||||
|
||||
@@ -1,10 +0,0 @@
|
||||
# Explicit `/setup-matt-pocock-skills` pointer only for hard dependencies
|
||||
|
||||
Engineering skills depend on per-repo config (issue tracker, triage label vocabulary, domain doc layout) seeded by `/setup-matt-pocock-skills`. Some skills cannot meaningfully function without that config — they have to publish to a specific issue tracker or apply a specific label string. Others only use it to sharpen output (vocabulary, ADR awareness) and degrade gracefully without it.
|
||||
|
||||
We split these into **hard-dependency** and **soft-dependency** skills:
|
||||
|
||||
- **Hard dependency** (`to-issues`, `to-prd`, `triage`) — include an explicit one-liner: _"… should have been provided to you — run `/setup-matt-pocock-skills` if not."_ Without the mapping, output is wrong, not just fuzzy.
|
||||
- **Soft dependency** (`diagnose`, `tdd`, `improve-codebase-architecture`, `zoom-out`) — reference "the project's domain glossary" and "ADRs in the area you're touching" in vague prose only. If the docs aren't there, the skill still works; output is just less sharp.
|
||||
|
||||
The split keeps soft-dependency skills token-light and avoids cargo-culting the setup pointer into places where it isn't load-bearing.
|
||||
@@ -1,7 +0,0 @@
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
REPO="$(cd "$(dirname "$0")/.." && pwd)"
|
||||
|
||||
cd "$REPO"
|
||||
find . -name SKILL.md -not -path '*/node_modules/*' | sed 's|^\./||' | sort
|
||||
@@ -3,11 +3,11 @@
|
||||
Skills I use daily for code work.
|
||||
|
||||
- **[diagnose](./diagnose/SKILL.md)** — Disciplined diagnosis loop for hard bugs and performance regressions: reproduce → minimise → hypothesise → instrument → fix → regression-test.
|
||||
- **[github](./github/SKILL.md)** — GitHub backend for the engineering skills. Publishes PRDs and issues, applies triage outcomes via `gh`.
|
||||
- **[grill-with-docs](./grill-with-docs/SKILL.md)** — Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates `CONTEXT.md` and ADRs inline.
|
||||
- **[triage](./triage/SKILL.md)** — Triage issues through a state machine of triage roles.
|
||||
- **[improve-codebase-architecture](./improve-codebase-architecture/SKILL.md)** — Find deepening opportunities in a codebase, informed by the domain language in `CONTEXT.md` and the decisions in `docs/adr/`.
|
||||
- **[setup-matt-pocock-skills](./setup-matt-pocock-skills/SKILL.md)** — Scaffold the per-repo config (issue tracker, triage label vocabulary, domain doc layout) that the other engineering skills consume.
|
||||
- **[tdd](./tdd/SKILL.md)** — Test-driven development with a red-green-refactor loop. Builds features or fixes bugs one vertical slice at a time.
|
||||
- **[to-issues](./to-issues/SKILL.md)** — Break any plan, spec, or PRD into independently-grabbable GitHub issues using vertical slices.
|
||||
- **[to-prd](./to-prd/SKILL.md)** — Turn the current conversation context into a PRD and submit it as a GitHub issue.
|
||||
- **[to-issues](./to-issues/SKILL.md)** — Break any plan, spec, or PRD into independently-grabbable issues using vertical slices. Hands off to a backend skill (`/github`) to publish.
|
||||
- **[to-prd](./to-prd/SKILL.md)** — Turn the current conversation context into a PRD. Hands off to a backend skill (`/github`) to publish.
|
||||
- **[triage](./triage/SKILL.md)** — Triage issues through a label-based state machine. Backend-agnostic — pairs with `/github` to apply outcomes.
|
||||
- **[zoom-out](./zoom-out/SKILL.md)** — Tell the agent to zoom out and give broader context or a higher-level perspective on an unfamiliar section of code.
|
||||
|
||||
@@ -7,7 +7,7 @@ description: Disciplined diagnosis loop for hard bugs and performance regression
|
||||
|
||||
A discipline for hard bugs. Skip phases only when explicitly justified.
|
||||
|
||||
When exploring the codebase, use the project's domain glossary to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
|
||||
Before exploring the codebase, follow [../grill-with-docs/DOMAIN-AWARENESS.md](../grill-with-docs/DOMAIN-AWARENESS.md). Use the `CONTEXT.md` vocabulary to get a clear mental model of the relevant modules.
|
||||
|
||||
## Phase 1 — Build a feedback loop
|
||||
|
||||
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
name: github
|
||||
description: GitHub backend for the engineering skills. Publishes PRDs and issues, applies triage outcomes via gh. Use when a content skill (`/to-prd`, `/to-issues`, `/triage`) has produced an artifact and the user wants to push it to GitHub.
|
||||
---
|
||||
|
||||
# GitHub Backend
|
||||
|
||||
The GitHub backend for content skills in the engineering bucket. Reads an artifact + state from conversation context and translates it into `gh` calls.
|
||||
|
||||
This skill does **not** explore the codebase, generate templates, or own state vocabulary. Those concerns live in the content skills (`/to-prd`, `/to-issues`, `/triage`). This skill is pure integration — swap it for `/linear`, `/beads`, etc. by implementing the same three operations.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- `gh` is authenticated and the working directory is a git repo with a GitHub remote
|
||||
- The repo has labels matching the state vocabulary defined in `/triage` (`bug`, `enhancement`, `needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix`). If any are missing, create them with `gh label create` before publishing.
|
||||
|
||||
## State → label mapping
|
||||
|
||||
The state vocabulary maps 1:1 to GitHub labels of the same name. Every issue gets exactly one category label (`bug` or `enhancement`) and one state label.
|
||||
|
||||
## AI Disclaimer
|
||||
|
||||
Every comment or issue body posted by this skill **must** start with:
|
||||
|
||||
```
|
||||
> *This was generated by AI during triage.*
|
||||
```
|
||||
|
||||
Prepend it to the body before calling `gh`.
|
||||
|
||||
## Operations
|
||||
|
||||
### `publishPRD(artifact)`
|
||||
|
||||
Input: a PRD body produced by `/to-prd` (already in the desired template) and a state (defaults to `ready-for-agent`).
|
||||
|
||||
Steps:
|
||||
|
||||
1. Verify the `enhancement` and state labels exist in the repo; create any missing ones with `gh label create`.
|
||||
2. Prepend the AI disclaimer to the body.
|
||||
3. Run `gh issue create --title "<derived from PRD>" --body "<body>" --label enhancement --label <state>`.
|
||||
4. Report the new issue URL to the user.
|
||||
|
||||
### `publishIssues(artifacts[])`
|
||||
|
||||
Input: an ordered list of vertical-slice artifacts produced by `/to-issues`. Each artifact has:
|
||||
|
||||
- title
|
||||
- body (already formatted — agent brief for AFK slices, summary for HITL)
|
||||
- type (`AFK` or `HITL`) → state mapping: AFK → `ready-for-agent`, HITL → `ready-for-human`
|
||||
- category (defaults to `enhancement` unless the parent issue was a bug)
|
||||
- blocked-by — references to other artifacts in this batch by their position
|
||||
|
||||
Steps:
|
||||
|
||||
1. Verify required labels exist; create any missing ones.
|
||||
2. Create issues in dependency order (blockers first) so each issue's "Blocked by" section can reference real numbers.
|
||||
3. For each artifact, after creation, substitute placeholder references in dependent artifacts with the real issue number.
|
||||
4. Prepend the AI disclaimer to each body before posting.
|
||||
5. Apply category + state labels to each.
|
||||
6. Report the list of created issue URLs.
|
||||
|
||||
Do **not** close or modify any parent issue.
|
||||
|
||||
### `applyTriageOutcome(issueId, outcome)`
|
||||
|
||||
Input: an issue identifier and a triage outcome from `/triage`. The outcome has:
|
||||
|
||||
- target state (one of the states above)
|
||||
- category (`bug` or `enhancement`)
|
||||
- comment body (may be empty for `needs-triage` with no progress to capture)
|
||||
- close (boolean — true for `wontfix`)
|
||||
|
||||
Steps:
|
||||
|
||||
1. Verify the target state and category labels exist; create missing ones.
|
||||
2. Read the issue's current labels. Remove any existing state label that conflicts with the target state. Remove existing category label if it differs from the target.
|
||||
3. Apply the new state and category labels: `gh issue edit <id> --add-label <state> --add-label <category> --remove-label <old-state>`.
|
||||
4. If a comment body is provided, prepend the AI disclaimer and post it: `gh issue comment <id> --body "<body>"`.
|
||||
5. If `close` is true: `gh issue close <id>`.
|
||||
6. For `wontfix` on an enhancement, ensure the corresponding `.out-of-scope/<concept>.md` file exists in the working directory before closing (the `/triage` skill is responsible for writing it; this skill just verifies the file is present and surfaces a warning if missing).
|
||||
7. Report the actions taken.
|
||||
|
||||
## Inferring the operation
|
||||
|
||||
When invoked, infer which operation to run from the most recent artifact in conversation context:
|
||||
|
||||
- A PRD artifact (from `/to-prd`) → `publishPRD`
|
||||
- A list of vertical-slice artifacts (from `/to-issues`) → `publishIssues`
|
||||
- A triage outcome with a target state (from `/triage`) → `applyTriageOutcome`
|
||||
|
||||
If multiple are present or the situation is ambiguous, ask the user which to run.
|
||||
+2
-2
@@ -1,6 +1,6 @@
|
||||
# Domain Docs
|
||||
# Domain Awareness
|
||||
|
||||
How the engineering skills should consume this repo's domain documentation when exploring the codebase.
|
||||
Consumer rules for any skill that explores a codebase. Producer rules (writing `CONTEXT.md`, offering ADRs) live in [SKILL.md](./SKILL.md).
|
||||
|
||||
## Before exploring, read these
|
||||
|
||||
@@ -1,20 +1,15 @@
|
||||
---
|
||||
name: grill-with-docs
|
||||
description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
<what-to-do>
|
||||
|
||||
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
|
||||
|
||||
Ask the questions one at a time, waiting for feedback on each question before continuing.
|
||||
|
||||
If a question can be answered by exploring the codebase, explore the codebase instead.
|
||||
|
||||
</what-to-do>
|
||||
|
||||
<supporting-info>
|
||||
|
||||
## Domain awareness
|
||||
|
||||
During codebase exploration, also look for existing documentation:
|
||||
@@ -84,5 +79,3 @@ Only offer to create an ADR when all three are true:
|
||||
3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
|
||||
|
||||
If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md).
|
||||
|
||||
</supporting-info>
|
||||
|
||||
@@ -32,7 +32,7 @@ This skill is _informed_ by the project's domain model. The domain language give
|
||||
|
||||
### 1. Explore
|
||||
|
||||
Read the project's domain glossary and any ADRs in the area you're touching first.
|
||||
Before exploring, follow [../grill-with-docs/DOMAIN-AWARENESS.md](../grill-with-docs/DOMAIN-AWARENESS.md) — read `CONTEXT.md` and relevant ADRs first.
|
||||
|
||||
Then use the Agent tool with `subagent_type=Explore` to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:
|
||||
|
||||
|
||||
@@ -1,121 +0,0 @@
|
||||
---
|
||||
name: setup-matt-pocock-skills
|
||||
description: Sets up an `## Agent skills` block in AGENTS.md/CLAUDE.md and `docs/agents/` so the engineering skills know this repo's issue tracker (GitHub or local markdown), triage label vocabulary, and domain doc layout. Run before first use of `to-issues`, `to-prd`, `triage`, `diagnose`, `tdd`, `improve-codebase-architecture`, or `zoom-out` — or if those skills appear to be missing context about the issue tracker, triage labels, or domain docs.
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
# 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 with the user, 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?
|
||||
- `AGENTS.md` and `CLAUDE.md` at the repo root — does either exist? Is there already an `## Agent skills` section in either?
|
||||
- `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/` — sign that a local-markdown issue tracker convention is already in use
|
||||
|
||||
### 2. Present findings and ask
|
||||
|
||||
Summarise what's present and what's missing. Then walk the user through the three decisions **one at a time** — present a section, get the user's answer, then move to the next. Don't dump all three at once.
|
||||
|
||||
Assume the user does not know what these terms mean. Each section starts with a short explainer (what it is, why these skills need it, what changes if they pick differently). Then show the choices and the default.
|
||||
|
||||
**Section A — Issue tracker.**
|
||||
|
||||
> Explainer: The "issue tracker" is where issues live for this repo. Skills like `to-issues`, `triage`, `to-prd`, and `qa` 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`](https://gitlab.com/gitlab-org/cli) 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
|
||||
|
||||
**Section B — Triage label vocabulary.**
|
||||
|
||||
> Explainer: When the `triage` skill processes an incoming issue, it moves it through a state machine — needs evaluation, waiting on reporter, ready for an AFK agent to pick up, ready for a human, or won't fix. To do that, it needs to apply labels (or the equivalent in your issue tracker) that match strings *you've actually configured*. If your repo already uses different label names (e.g. `bug:triage` instead of `needs-triage`), map them here so the skill applies the right ones instead of creating duplicates.
|
||||
|
||||
The five canonical roles:
|
||||
|
||||
- `needs-triage` — maintainer needs to evaluate
|
||||
- `needs-info` — waiting on reporter
|
||||
- `ready-for-agent` — fully specified, AFK-ready (an agent can pick it up with no human context)
|
||||
- `ready-for-human` — needs human implementation
|
||||
- `wontfix` — will not be actioned
|
||||
|
||||
Default: each role's string equals its name. Ask the user if they want to override any. If their issue tracker has no existing labels, the defaults are fine.
|
||||
|
||||
**Section C — Domain docs.**
|
||||
|
||||
> Explainer: Some skills (`improve-codebase-architecture`, `diagnose`, `tdd`) read a `CONTEXT.md` file to learn the project's domain language, and `docs/adr/` for past architectural decisions. They need to know whether the repo has one global context or multiple (e.g. a monorepo with separate frontend/backend contexts) so they look in the right place.
|
||||
|
||||
Confirm the layout:
|
||||
|
||||
- **Single-context** — one `CONTEXT.md` + `docs/adr/` at the repo root. Most repos are this.
|
||||
- **Multi-context** — `CONTEXT-MAP.md` at the root pointing to per-context `CONTEXT.md` files (typically a monorepo).
|
||||
|
||||
### 3. Confirm and edit
|
||||
|
||||
Show the user a draft of:
|
||||
|
||||
- The `## Agent skills` block to add to whichever of `CLAUDE.md` / `AGENTS.md` is being edited (see step 4 for selection rules)
|
||||
- The contents of `docs/agents/issue-tracker.md`, `docs/agents/triage-labels.md`, `docs/agents/domain.md`
|
||||
|
||||
Let them edit before writing.
|
||||
|
||||
### 4. Write
|
||||
|
||||
**Pick the file to edit:**
|
||||
|
||||
- If `CLAUDE.md` exists, edit it.
|
||||
- Else if `AGENTS.md` exists, edit it.
|
||||
- If neither exists, ask the user which one to create — don't pick for them.
|
||||
|
||||
Never create `AGENTS.md` when `CLAUDE.md` already exists (or vice versa) — always edit the one that's already there.
|
||||
|
||||
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:
|
||||
|
||||
```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`.
|
||||
```
|
||||
|
||||
Then write the three docs files using the seed templates in this skill folder as a starting point:
|
||||
|
||||
- [issue-tracker-github.md](./issue-tracker-github.md) — GitHub issue tracker
|
||||
- [issue-tracker-gitlab.md](./issue-tracker-gitlab.md) — GitLab issue tracker
|
||||
- [issue-tracker-local.md](./issue-tracker-local.md) — local-markdown issue tracker
|
||||
- [triage-labels.md](./triage-labels.md) — label mapping
|
||||
- [domain.md](./domain.md) — domain doc consumer rules + layout
|
||||
|
||||
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.
|
||||
@@ -1,22 +0,0 @@
|
||||
# Issue tracker: GitHub
|
||||
|
||||
Issues and PRDs for this repo live as GitHub issues. Use the `gh` CLI for all operations.
|
||||
|
||||
## Conventions
|
||||
|
||||
- **Create an issue**: `gh issue create --title "..." --body "..."`. Use a heredoc for multi-line bodies.
|
||||
- **Read an issue**: `gh issue view <number> --comments`, filtering comments by `jq` and also fetching labels.
|
||||
- **List issues**: `gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'` with appropriate `--label` and `--state` filters.
|
||||
- **Comment on an issue**: `gh issue comment <number> --body "..."`
|
||||
- **Apply / remove labels**: `gh issue edit <number> --add-label "..."` / `--remove-label "..."`
|
||||
- **Close**: `gh issue close <number> --comment "..."`
|
||||
|
||||
Infer the repo from `git remote -v` — `gh` does this automatically when run inside a clone.
|
||||
|
||||
## When a skill says "publish to the issue tracker"
|
||||
|
||||
Create a GitHub issue.
|
||||
|
||||
## When a skill says "fetch the relevant ticket"
|
||||
|
||||
Run `gh issue view <number> --comments`.
|
||||
@@ -1,23 +0,0 @@
|
||||
# Issue tracker: GitLab
|
||||
|
||||
Issues and PRDs for this repo live as GitLab issues. Use the [`glab`](https://gitlab.com/gitlab-org/cli) CLI for all operations.
|
||||
|
||||
## Conventions
|
||||
|
||||
- **Create an issue**: `glab issue create --title "..." --description "..."`. Use a heredoc for multi-line descriptions. Pass `--description -` to open an editor.
|
||||
- **Read an issue**: `glab issue view <number> --comments`. Use `-F json` for machine-readable output.
|
||||
- **List issues**: `glab issue list --state opened -F json` with appropriate `--label` filters. Note that GitLab uses `opened` (not `open`) for the state value.
|
||||
- **Comment on an issue**: `glab issue note <number> --message "..."`. GitLab calls comments "notes".
|
||||
- **Apply / remove labels**: `glab issue update <number> --label "..."` / `--unlabel "..."`. Multiple labels can be comma-separated or by repeating the flag.
|
||||
- **Close**: `glab issue close <number>`. `glab issue close` does not accept a closing comment, so post the explanation first with `glab issue note <number> --message "..."`, then close.
|
||||
- **Merge requests**: GitLab calls PRs "merge requests". Use `glab mr create`, `glab mr view`, `glab mr note`, etc. — the same shape as `gh pr ...` with `mr` in place of `pr` and `note`/`--message` in place of `comment`/`--body`.
|
||||
|
||||
Infer the repo from `git remote -v` — `glab` does this automatically when run inside a clone.
|
||||
|
||||
## When a skill says "publish to the issue tracker"
|
||||
|
||||
Create a GitLab issue.
|
||||
|
||||
## When a skill says "fetch the relevant ticket"
|
||||
|
||||
Run `glab issue view <number> --comments`.
|
||||
@@ -1,19 +0,0 @@
|
||||
# Issue tracker: Local Markdown
|
||||
|
||||
Issues and PRDs for this repo live as markdown files in `.scratch/`.
|
||||
|
||||
## Conventions
|
||||
|
||||
- One feature per directory: `.scratch/<feature-slug>/`
|
||||
- The PRD is `.scratch/<feature-slug>/PRD.md`
|
||||
- Implementation issues are `.scratch/<feature-slug>/issues/<NN>-<slug>.md`, numbered from `01`
|
||||
- Triage state is recorded as a `Status:` line near the top of each issue file (see `triage-labels.md` for the role strings)
|
||||
- Comments and conversation history append to the bottom of the file under a `## Comments` heading
|
||||
|
||||
## When a skill says "publish to the issue tracker"
|
||||
|
||||
Create a new file under `.scratch/<feature-slug>/` (creating the directory if needed).
|
||||
|
||||
## When a skill says "fetch the relevant ticket"
|
||||
|
||||
Read the file at the referenced path. The user will normally pass the path or the issue number directly.
|
||||
@@ -1,15 +0,0 @@
|
||||
# Triage Labels
|
||||
|
||||
The skills speak in terms of five canonical triage roles. This file maps those roles to the actual label strings used in this repo's issue tracker.
|
||||
|
||||
| Label in mattpocock/skills | Label in our tracker | Meaning |
|
||||
| -------------------------- | -------------------- | ---------------------------------------- |
|
||||
| `needs-triage` | `needs-triage` | Maintainer needs to evaluate this issue |
|
||||
| `needs-info` | `needs-info` | Waiting on reporter for more information |
|
||||
| `ready-for-agent` | `ready-for-agent` | Fully specified, ready for an AFK agent |
|
||||
| `ready-for-human` | `ready-for-human` | Requires human implementation |
|
||||
| `wontfix` | `wontfix` | Will not be actioned |
|
||||
|
||||
When a skill mentions a role (e.g. "apply the AFK-ready triage label"), use the corresponding label string from this table.
|
||||
|
||||
Edit the right-hand column to match whatever vocabulary you actually use.
|
||||
@@ -44,7 +44,7 @@ RIGHT (vertical):
|
||||
|
||||
### 1. Planning
|
||||
|
||||
When exploring the codebase, use the project's domain glossary so that test names and interface vocabulary match the project's language, and respect ADRs in the area you're touching.
|
||||
Before exploring the codebase, follow [../grill-with-docs/DOMAIN-AWARENESS.md](../grill-with-docs/DOMAIN-AWARENESS.md). Test names and interface vocabulary should match the project's `CONTEXT.md`.
|
||||
|
||||
Before writing any code:
|
||||
|
||||
|
||||
@@ -1,29 +1,27 @@
|
||||
---
|
||||
name: to-issues
|
||||
description: Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.
|
||||
description: Break a plan, spec, or PRD into independently-grabbable issues using tracer-bullet vertical slices. Backend-agnostic — pairs with `/github` (or another backlog skill) to publish. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.
|
||||
---
|
||||
|
||||
# To Issues
|
||||
|
||||
Break a plan into independently-grabbable issues using vertical slices (tracer bullets).
|
||||
|
||||
The issue tracker and triage label vocabulary should have been provided to you — run `/setup-matt-pocock-skills` if not.
|
||||
Break a plan into independently-grabbable issues using vertical slices (tracer bullets). Produce canonical artifacts; hand off to a backend skill (`/github` by default) to publish.
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Gather context
|
||||
|
||||
Work from whatever is already in the conversation context. If the user passes an issue reference (issue number, URL, or path) as an argument, fetch it from the issue tracker and read its full body and comments.
|
||||
Work from whatever is already in the conversation context. If the user passes an issue identifier as an argument and a backend is reachable, ask the backend skill to fetch the parent issue (with comments).
|
||||
|
||||
### 2. Explore the codebase (optional)
|
||||
|
||||
If you have not already explored the codebase, do so to understand the current state of the code. Issue titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.
|
||||
If you have not already explored the codebase, do so to understand the current state of the code. Before exploring, follow [../grill-with-docs/DOMAIN-AWARENESS.md](../grill-with-docs/DOMAIN-AWARENESS.md). Issue titles and bodies should use the project's `CONTEXT.md` vocabulary.
|
||||
|
||||
### 3. Draft vertical slices
|
||||
|
||||
Break the plan into **tracer bullet** issues. Each issue is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer.
|
||||
Break the plan into **tracer bullet** slices. Each is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer.
|
||||
|
||||
Slices may be 'HITL' or 'AFK'. HITL slices require human interaction, such as an architectural decision or a design review. AFK slices can be implemented and merged without human interaction. Prefer AFK over HITL where possible.
|
||||
Slices may be **HITL** or **AFK**. HITL slices require human interaction (an architectural decision, a design review). AFK slices can be implemented and merged without human interaction. Prefer AFK over HITL where possible.
|
||||
|
||||
<vertical-slice-rules>
|
||||
- Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI, tests)
|
||||
@@ -49,21 +47,33 @@ Ask the user:
|
||||
|
||||
Iterate until the user approves the breakdown.
|
||||
|
||||
### 5. Publish the issues to the issue tracker
|
||||
### 5. Produce artifacts
|
||||
|
||||
For each approved slice, publish a new issue to the issue tracker. Use the issue body template below. Apply the `needs-triage` triage label so each issue enters the normal triage flow.
|
||||
For each approved slice, produce an artifact with:
|
||||
|
||||
Publish issues in dependency order (blockers first) so you can reference real issue identifiers in the "Blocked by" field.
|
||||
- **title** — short descriptive name
|
||||
- **type** — `AFK` or `HITL`. Maps to state: AFK → `ready-for-agent`, HITL → `ready-for-human` (the state vocabulary lives in `/triage`)
|
||||
- **category** — `enhancement` by default, or `bug` if the parent was a bug
|
||||
- **blocked-by** — references to other slices in this batch (by their position in the list)
|
||||
- **body** — formatted per the templates below
|
||||
|
||||
<issue-template>
|
||||
**AFK slices** use the AGENT-BRIEF format from [../triage/AGENT-BRIEF.md](../triage/AGENT-BRIEF.md). The agent brief is the contract the AFK agent will work from.
|
||||
|
||||
**HITL slices** use the simpler template below — they require human judgment, so a procedural acceptance list is enough.
|
||||
|
||||
<hitl-template>
|
||||
## Parent
|
||||
|
||||
A reference to the parent issue on the issue tracker (if the source was an existing issue, otherwise omit this section).
|
||||
#<parent-issue-id> (if the source was an existing issue, otherwise omit)
|
||||
|
||||
## What to build
|
||||
|
||||
A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.
|
||||
|
||||
## Why this needs a human
|
||||
|
||||
Brief reason this can't be delegated to an AFK agent (e.g. requires architectural decision, design review, judgment call).
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- [ ] Criterion 1
|
||||
@@ -72,10 +82,17 @@ A concise description of this vertical slice. Describe the end-to-end behavior,
|
||||
|
||||
## Blocked by
|
||||
|
||||
- A reference to the blocking ticket (if any)
|
||||
- Blocked by <slice-ref> (if any)
|
||||
|
||||
Or "None - can start immediately" if no blockers.
|
||||
</hitl-template>
|
||||
|
||||
</issue-template>
|
||||
### 6. Hand off
|
||||
|
||||
Present the artifact list to the user and end with a handoff hint:
|
||||
|
||||
> Artifacts ready. Invoke `/github` (or your configured backend equivalent) to publish — it will create issues in dependency order, apply state and category labels, and substitute real identifiers into the "Blocked by" references.
|
||||
|
||||
Do not call `gh` directly. The backend skill owns publishing.
|
||||
|
||||
Do NOT close or modify any parent issue.
|
||||
|
||||
@@ -1,15 +1,13 @@
|
||||
---
|
||||
name: to-prd
|
||||
description: Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context.
|
||||
description: Turn the current conversation context into a PRD. Backend-agnostic — pairs with `/github` (or another backlog skill) to publish. Use when user wants to create a PRD from the current context.
|
||||
---
|
||||
|
||||
This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user — just synthesize what you already know.
|
||||
|
||||
The issue tracker and triage label vocabulary should have been provided to you — run `/setup-matt-pocock-skills` if not.
|
||||
This skill takes the current conversation context and codebase understanding and produces a PRD artifact. Do NOT interview the user — just synthesize what you already know. Hand off to a backend skill (`/github` by default) to publish.
|
||||
|
||||
## Process
|
||||
|
||||
1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the PRD, and respect any ADRs in the area you're touching.
|
||||
1. Explore the repo to understand the current state of the codebase, if you haven't already. Before exploring, follow [../grill-with-docs/DOMAIN-AWARENESS.md](../grill-with-docs/DOMAIN-AWARENESS.md). Use the project's `CONTEXT.md` vocabulary throughout the PRD.
|
||||
|
||||
2. Sketch out the major modules you will need to build or modify to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation.
|
||||
|
||||
@@ -17,7 +15,11 @@ A deep module (as opposed to a shallow module) is one which encapsulates a lot o
|
||||
|
||||
Check with the user that these modules match their expectations. Check with the user which modules they want tests written for.
|
||||
|
||||
3. Write the PRD using the template below, then publish it to the project issue tracker. Apply the `needs-triage` triage label so it enters the normal triage flow.
|
||||
3. Write the PRD artifact using the template below. Default state is `ready-for-agent` (state vocabulary lives in `/triage`); category is `enhancement`. Present the artifact to the user, then end with a handoff hint:
|
||||
|
||||
> PRD ready. Invoke `/github` (or your configured backend equivalent) to publish — it will create the issue with category `enhancement` and state `ready-for-agent`.
|
||||
|
||||
Do not call `gh` directly. The backend skill owns publishing.
|
||||
|
||||
<prd-template>
|
||||
|
||||
|
||||
@@ -1,86 +1,158 @@
|
||||
---
|
||||
name: triage
|
||||
description: Triage issues through a state machine driven by triage roles. Use when user wants to create an issue, triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.
|
||||
description: Triage issues through a label-based state machine. Backend-agnostic — pairs with `/github` (or another backlog skill) to apply outcomes. Use when user wants to triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.
|
||||
---
|
||||
|
||||
# Triage
|
||||
|
||||
Move issues on the project issue tracker through a small state machine of triage roles.
|
||||
Triage issues using a label-based state machine. This skill owns the *conceptual* state vocabulary, the AGENT-BRIEF format, and the workflows. It does **not** know how to talk to any specific backlog system — handoff to a backend skill (e.g. `/github`) when an outcome needs to be applied.
|
||||
|
||||
Every comment or issue posted to the issue tracker during triage **must** start with this disclaimer:
|
||||
## AI Disclaimer
|
||||
|
||||
Every comment posted to a backlog system during triage **must** include the following disclaimer at the top, before any other content:
|
||||
|
||||
```
|
||||
> *This was generated by AI during triage.*
|
||||
```
|
||||
|
||||
The backend skill is responsible for prepending it.
|
||||
|
||||
## Reference docs
|
||||
|
||||
- [AGENT-BRIEF.md](AGENT-BRIEF.md) — how to write durable agent briefs
|
||||
- [OUT-OF-SCOPE.md](OUT-OF-SCOPE.md) — how the `.out-of-scope/` knowledge base works
|
||||
|
||||
## Roles
|
||||
## States
|
||||
|
||||
Two **category** roles:
|
||||
The conceptual state vocabulary. The backend skill maps these to its platform's primitives (e.g. `/github` maps each to a GitHub label of the same name).
|
||||
|
||||
- `bug` — something is broken
|
||||
- `enhancement` — new feature or improvement
|
||||
| State | Type | Description |
|
||||
| ----------------- | -------- | ---------------------------------------- |
|
||||
| `bug` | Category | Something is broken |
|
||||
| `enhancement` | Category | New feature or improvement |
|
||||
| `needs-triage` | State | Maintainer needs to evaluate this issue |
|
||||
| `needs-info` | State | Waiting on reporter for more information |
|
||||
| `ready-for-agent` | State | Fully specified, ready for AFK agent |
|
||||
| `ready-for-human` | State | Requires human implementation |
|
||||
| `wontfix` | State | Will not be actioned |
|
||||
|
||||
Five **state** roles:
|
||||
Every issue should have exactly **one** state and **one** category. If an issue has conflicting states (e.g. both `needs-triage` and `ready-for-agent`), flag the conflict and ask the maintainer which is correct before doing anything else. Provide a recommendation.
|
||||
|
||||
- `needs-triage` — maintainer needs to evaluate
|
||||
- `needs-info` — waiting on reporter for more information
|
||||
- `ready-for-agent` — fully specified, ready for an AFK agent
|
||||
- `ready-for-human` — needs human implementation
|
||||
- `wontfix` — will not be actioned
|
||||
## State Machine
|
||||
|
||||
Every triaged issue should carry exactly one category role and one state role. If state roles conflict, flag it and ask the maintainer before doing anything else.
|
||||
| Current State | Can transition to | Who triggers it | What happens |
|
||||
| -------------- | ----------------- | ---------------------- | ------------------------------------------------------------------------------------------------------- |
|
||||
| `unlabeled` | `needs-triage` | Skill (on first look) | Issue needs maintainer evaluation. Apply state after presenting recommendation. |
|
||||
| `unlabeled` | `ready-for-agent` | Maintainer (via skill) | Issue is already well-specified and agent-suitable. Write agent brief, apply state. |
|
||||
| `unlabeled` | `ready-for-human` | Maintainer (via skill) | Issue requires human implementation. Write a brief comment summarizing the task, apply state. |
|
||||
| `unlabeled` | `wontfix` | Maintainer (via skill) | Issue is spam, duplicate, or out of scope. Close with comment (and write `.out-of-scope/` for enhancements). |
|
||||
| `needs-triage` | `needs-info` | Maintainer (via skill) | Issue is underspecified. Post triage notes capturing progress so far + questions for reporter. |
|
||||
| `needs-triage` | `ready-for-agent` | Maintainer (via skill) | Grilling session complete, agent-suitable. Write agent brief, apply state. |
|
||||
| `needs-triage` | `ready-for-human` | Maintainer (via skill) | Grilling session complete, needs human. Write a brief comment summarizing the task, apply state. |
|
||||
| `needs-triage` | `wontfix` | Maintainer (via skill) | Maintainer decides not to action. Close with comment (and write `.out-of-scope/` for enhancements). |
|
||||
| `needs-info` | `needs-triage` | Skill (detects reply) | Reporter has replied. Surface to maintainer for re-evaluation. |
|
||||
|
||||
These are canonical role names — the actual label strings used in the issue tracker may differ. The mapping should have been provided to you - run `/setup-matt-pocock-skills` if not.
|
||||
|
||||
State transitions: an unlabeled issue normally goes to `needs-triage` first; from there it moves to `needs-info`, `ready-for-agent`, `ready-for-human`, or `wontfix`. `needs-info` returns to `needs-triage` once the reporter replies. The maintainer can override at any time — flag transitions that look unusual and ask before proceeding.
|
||||
The maintainer can override any state directly (see Quick State Override below), but the skill should flag if the transition is unusual.
|
||||
|
||||
## Invocation
|
||||
|
||||
The maintainer invokes `/triage` and describes what they want in natural language. Interpret the request and act. Examples:
|
||||
The maintainer invokes `/triage` and describes what they want in natural language. The skill interprets the request, decides the outcome, then hands off to the configured backend skill (`/github` by default) to apply it.
|
||||
|
||||
Example requests:
|
||||
|
||||
- "Show me anything that needs my attention"
|
||||
- "Let's look at #42"
|
||||
- "Move #42 to ready-for-agent"
|
||||
- "What's ready for agents to pick up?"
|
||||
- "Are there any unlabeled issues?"
|
||||
|
||||
## Show what needs attention
|
||||
## Workflow: Show What Needs Attention
|
||||
|
||||
Query the issue tracker and present three buckets, oldest first:
|
||||
When the maintainer asks for an overview, ask the backend skill to fetch issues grouped into three buckets:
|
||||
|
||||
1. **Unlabeled** — never triaged.
|
||||
2. **`needs-triage`** — evaluation in progress.
|
||||
3. **`needs-info` with reporter activity since the last triage notes** — needs re-evaluation.
|
||||
1. **Unlabeled issues** — new, no state at all. These have never been triaged.
|
||||
2. **`needs-triage` issues** — maintainer needs to evaluate or continue evaluating.
|
||||
3. **`needs-info` issues with new activity** — the reporter has commented since the last triage notes comment.
|
||||
|
||||
Show counts and a one-line summary per issue. Let the maintainer pick.
|
||||
Display counts per group. Within each group, show issues oldest first (longest-waiting gets attention first). For each issue, show: identifier, title, age, and a one-line summary of the issue body.
|
||||
|
||||
## Triage a specific issue
|
||||
Let the maintainer pick which issue to dive into.
|
||||
|
||||
1. **Gather context.** Read the full issue (body, comments, labels, reporter, dates). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using the project's domain glossary, respecting ADRs in the area. Read `.out-of-scope/*.md` and surface any prior rejection that resembles this issue.
|
||||
## Workflow: Triage a Specific Issue
|
||||
|
||||
2. **Recommend.** Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the issue. Wait for direction.
|
||||
### Step 1: Gather context
|
||||
|
||||
3. **Reproduce (bugs only).** Before any grilling, attempt reproduction: read the reporter's steps, trace the relevant code, run tests or commands. Report what happened — successful repro with code path, failed repro, or insufficient detail (a strong `needs-info` signal). A confirmed repro makes a much stronger agent brief.
|
||||
Before presenting anything to the maintainer:
|
||||
|
||||
4. **Grill (if needed).** If the issue needs fleshing out, run a `/grill-with-docs` session.
|
||||
- Read the full issue: body, all comments, all states, who reported it, when (ask the backend skill to fetch it)
|
||||
- If there are prior triage notes from previous sessions, parse them to understand what has already been established
|
||||
- Explore the codebase to build context — understand the domain, relevant interfaces, and existing behavior related to the issue. Before exploring, follow [../grill-with-docs/DOMAIN-AWARENESS.md](../grill-with-docs/DOMAIN-AWARENESS.md).
|
||||
- Read `.out-of-scope/*.md` files and check if this issue matches or is similar to a previously rejected concept
|
||||
|
||||
5. **Apply the outcome:**
|
||||
- `ready-for-agent` — post an agent brief comment ([AGENT-BRIEF.md](AGENT-BRIEF.md)).
|
||||
- `ready-for-human` — same structure as an agent brief, but note why it can't be delegated (judgment calls, external access, design decisions, manual testing).
|
||||
- `needs-info` — post triage notes (template below).
|
||||
- `wontfix` (bug) — polite explanation, then close.
|
||||
- `wontfix` (enhancement) — write to `.out-of-scope/`, link to it from a comment, then close ([OUT-OF-SCOPE.md](OUT-OF-SCOPE.md)).
|
||||
- `needs-triage` — apply the role. Optional comment if there's partial progress.
|
||||
### Step 2: Present a recommendation
|
||||
|
||||
## Quick state override
|
||||
Tell the maintainer:
|
||||
|
||||
If the maintainer says "move #42 to ready-for-agent", trust them and apply the role directly. Confirm what you're about to do (role changes, comment, close), then act. Skip grilling. If moving to `ready-for-agent` without a grilling session, ask whether they want to write an agent brief.
|
||||
- **Category recommendation:** bug or enhancement, with reasoning
|
||||
- **State recommendation:** where this issue should go, with reasoning
|
||||
- If it matches a prior out-of-scope rejection, surface that: "This is similar to `.out-of-scope/concept-name.md` — we rejected this before because X. Do you still feel the same way?"
|
||||
- A brief summary of what you found in the codebase that's relevant
|
||||
|
||||
## Needs-info template
|
||||
Then wait for the maintainer's direction. They may:
|
||||
|
||||
- Agree and ask you to apply the outcome → hand off to the backend skill
|
||||
- Want to flesh it out → start a /grill-with-docs session
|
||||
- Override with a different state → apply their choice
|
||||
- Want to discuss → have a conversation
|
||||
|
||||
### Step 3: Bug reproduction (bugs only)
|
||||
|
||||
If the issue is categorized as a bug, attempt to reproduce it before starting a /grill-with-docs session.
|
||||
|
||||
- Read the reporter's reproduction steps (if provided)
|
||||
- Explore the codebase to understand the relevant code paths
|
||||
- Try to reproduce the bug: run tests, execute commands, or trace the logic to confirm the reported behavior
|
||||
- If reproduction succeeds, report what you found — include the specific behavior you observed and where in the code it originates
|
||||
- If reproduction fails, report that too — the bug may be environment-specific, already fixed, or the report may be inaccurate
|
||||
- If the report lacks enough detail to attempt reproduction, note that — this is a strong signal the issue should move to `needs-info`
|
||||
|
||||
The reproduction attempt informs the /grill-with-docs session and the agent brief. A confirmed reproduction with a known code path makes for a much stronger brief.
|
||||
|
||||
### Step 4: /grill-with-docs session (if needed)
|
||||
|
||||
If the issue needs to be fleshed out before it's ready for an agent, interview the maintainer to build a complete specification. Use the /grill-with-docs skill.
|
||||
|
||||
### Step 5: Apply the outcome
|
||||
|
||||
Determine the outcome, then hand off to the configured backend skill to apply it. The triage outcome consists of:
|
||||
|
||||
- **Target state** (one of the states above)
|
||||
- **Category** (bug or enhancement)
|
||||
- **Comment body** to post — varies by outcome:
|
||||
- **ready-for-agent** — an agent brief (see [AGENT-BRIEF.md](AGENT-BRIEF.md))
|
||||
- **ready-for-human** — a comment summarizing the task, what was established during triage, and why it needs human implementation. Same structure as an agent brief but note the reason it can't be delegated (e.g. requires judgment calls, external system access, design decisions, or manual testing).
|
||||
- **needs-info** — triage notes (see Needs Info Output below)
|
||||
- **wontfix (bug)** — a polite comment explaining why; the backend will close the issue
|
||||
- **wontfix (enhancement)** — write to `.out-of-scope/` (see [OUT-OF-SCOPE.md](OUT-OF-SCOPE.md)), then a comment linking to it; the backend will close the issue
|
||||
- **needs-triage** — optional comment if there's partial progress to capture
|
||||
|
||||
End with a handoff hint:
|
||||
|
||||
> Outcome ready. Invoke `/github` (or your configured backend equivalent) to apply state `<state>` to issue `<id>` with the comment above.
|
||||
|
||||
The backend skill maps the state name to its platform primitive, posts the comment, and closes the issue if `wontfix`.
|
||||
|
||||
## Workflow: Quick State Override
|
||||
|
||||
When the maintainer explicitly tells you to move an issue to a specific state (e.g. "move #42 to ready-for-agent"), trust their judgment.
|
||||
|
||||
Show a confirmation of what you're about to do: target state, category, whether a comment will be posted, whether the issue will be closed. Then hand off to the backend skill. Skip the /grill-with-docs session entirely.
|
||||
|
||||
If moving to `ready-for-agent` without a /grill-with-docs session, ask the maintainer if they want to write a brief agent brief comment or skip it.
|
||||
|
||||
## Needs Info Output
|
||||
|
||||
When moving an issue to `needs-info`, the comment body should be:
|
||||
|
||||
```markdown
|
||||
## Triage Notes
|
||||
@@ -96,8 +168,14 @@ If the maintainer says "move #42 to ready-for-agent", trust them and apply the r
|
||||
- question 2
|
||||
```
|
||||
|
||||
Capture everything resolved during grilling under "established so far" so the work isn't lost. Questions must be specific and actionable, not "please provide more info".
|
||||
Include everything resolved during the /grill-with-docs session in "established so far" — this work should not be lost. The questions for the reporter should be specific and actionable, not vague ("please provide more info").
|
||||
|
||||
## Resuming a previous session
|
||||
## Resuming Previous Sessions
|
||||
|
||||
If prior triage notes exist on the issue, read them, check whether the reporter has answered any outstanding questions, and present an updated picture before continuing. Don't re-ask resolved questions.
|
||||
When triaging an issue that already has triage notes from a previous session:
|
||||
|
||||
1. Read all comments to find prior triage notes
|
||||
2. Parse what was already established
|
||||
3. Check if the reporter has answered any outstanding questions
|
||||
4. Present the maintainer with an updated picture: "Here's where we left off, and here's what the reporter has said since"
|
||||
5. Continue the /grill-with-docs session from where it stopped — do not re-ask resolved questions
|
||||
|
||||
@@ -4,4 +4,6 @@ description: Tell the agent to zoom out and give broader context or a higher-lev
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
I don't know this area of code well. Go up a layer of abstraction. Give me a map of all the relevant modules and callers, using the project's domain glossary vocabulary.
|
||||
I don't know this area of code well. Go up a layer of abstraction. Give me a map of all the relevant modules and callers, using the language in `CONTEXT.md`.
|
||||
|
||||
Use [../grill-with-docs/DOMAIN-AWARENESS.md](../grill-with-docs/DOMAIN-AWARENESS.md) as a reference for how to use `CONTEXT.md`.
|
||||
|
||||
Reference in New Issue
Block a user