mirror of
https://github.com/mattpocock/skills.git
synced 2026-04-30 14:03:53 +07:00
Add setup-matt-pocock-skills; rename github-triage to triage; migrate engineering skills to vague prose
Engineering skills no longer hard-code GitHub or specific label strings. A new setup skill scaffolds an `## Agent skills` block in AGENTS.md/CLAUDE.md plus `docs/agents/` so each repo can declare its own backlog backend, triage label vocabulary, and domain doc layout. Skills that need the mapping (to-issues, to-prd, triage) point at the setup skill; skills that only soften with it (diagnose, tdd, improve-codebase-architecture, zoom-out) stay vague. ADR-0001 records the split. Closes #88, #89. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Matt Pocock
@@ -3,8 +3,9 @@
|
||||
"skills": [
|
||||
"./skills/engineering/diagnose",
|
||||
"./skills/engineering/grill-with-docs",
|
||||
"./skills/engineering/github-triage",
|
||||
"./skills/engineering/triage",
|
||||
"./skills/engineering/improve-codebase-architecture",
|
||||
"./skills/engineering/setup-matt-pocock-skills",
|
||||
"./skills/engineering/tdd",
|
||||
"./skills/engineering/to-issues",
|
||||
"./skills/engineering/to-prd",
|
||||
|
||||
@@ -141,8 +141,9 @@ 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.
|
||||
- **[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.
|
||||
- **[github-triage](./skills/engineering/github-triage/SKILL.md)** — Triage GitHub issues through a label-based state machine.
|
||||
- **[triage](./skills/engineering/triage/SKILL.md)** — Triage backlog 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 (backlog backend, 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.
|
||||
|
||||
@@ -0,0 +1,10 @@
|
||||
# Explicit `/setup-matt-pocock-skills` pointer only for hard dependencies
|
||||
|
||||
Engineering skills depend on per-repo config (backlog backend, 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 backlog 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.
|
||||
@@ -4,8 +4,9 @@ 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.
|
||||
- **[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.
|
||||
- **[github-triage](./github-triage/SKILL.md)** — Triage GitHub issues through a label-based state machine.
|
||||
- **[triage](./triage/SKILL.md)** — Triage backlog 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 (backlog backend, 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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
## Phase 1 — Build a feedback loop
|
||||
|
||||
|
||||
@@ -1,168 +0,0 @@
|
||||
---
|
||||
name: github-triage
|
||||
description: Triage GitHub issues through a label-based state machine. 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.
|
||||
---
|
||||
|
||||
# GitHub Issue Triage
|
||||
|
||||
Triage issues in the current repo using a label-based state machine. Infer the repo from `git remote`. Use `gh` for all GitHub operations.
|
||||
|
||||
## AI Disclaimer
|
||||
|
||||
Every comment or issue posted to GitHub during triage **must** include the following disclaimer at the top of the comment body, before any other content:
|
||||
|
||||
```
|
||||
> *This was generated by AI during triage.*
|
||||
```
|
||||
|
||||
## 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
|
||||
|
||||
## Labels
|
||||
|
||||
| Label | 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 |
|
||||
|
||||
Every issue should have exactly **one** state label and **one** category label. If an issue has conflicting state labels (e.g. both `needs-triage` and `ready-for-agent`), flag the conflict and ask the maintainer which state is correct before doing anything else. Provide a recommendation.
|
||||
|
||||
## State Machine
|
||||
|
||||
| Current State | Can transition to | Who triggers it | What happens |
|
||||
| -------------- | ----------------- | ---------------------- | -------------------------------------------------------------------------------------------------------------------- |
|
||||
| `unlabeled` | `needs-triage` | Skill (on first look) | Issue needs maintainer evaluation. Skill applies label after presenting recommendation. |
|
||||
| `unlabeled` | `ready-for-agent` | Maintainer (via skill) | Issue is already well-specified and agent-suitable. Skill writes agent brief comment, applies label. |
|
||||
| `unlabeled` | `ready-for-human` | Maintainer (via skill) | Issue requires human implementation. Skill writes a brief comment summarizing the task, applies label. |
|
||||
| `unlabeled` | `wontfix` | Maintainer (via skill) | Issue is spam, duplicate, or out of scope. Skill closes with comment (and writes `.out-of-scope/` for enhancements). |
|
||||
| `needs-triage` | `needs-info` | Maintainer (via skill) | Issue is underspecified. Skill posts triage notes capturing progress so far + questions for reporter. |
|
||||
| `needs-triage` | `ready-for-agent` | Maintainer (via skill) | Grilling session complete, agent-suitable. Skill writes agent brief comment, applies label. |
|
||||
| `needs-triage` | `ready-for-human` | Maintainer (via skill) | Grilling session complete, needs human. Skill writes a brief comment summarizing the task, applies label. |
|
||||
| `needs-triage` | `wontfix` | Maintainer (via skill) | Maintainer decides not to action. Skill closes with comment (and writes `.out-of-scope/` for enhancements). |
|
||||
| `needs-info` | `needs-triage` | Skill (detects reply) | Reporter has replied. Skill surfaces to maintainer for re-evaluation. |
|
||||
|
||||
An issue can only move along these transitions. 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 `/github-triage` then describes what they want in natural language. The skill interprets the request and takes the appropriate action.
|
||||
|
||||
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?"
|
||||
|
||||
## Workflow: Show What Needs Attention
|
||||
|
||||
When the maintainer asks for an overview, query GitHub and present a summary grouped into three buckets:
|
||||
|
||||
1. **Unlabeled issues** — new, no labels 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. Check comment timestamps to determine this.
|
||||
|
||||
Display counts per group. Within each group, show issues oldest first (longest-waiting gets attention first). For each issue, show: number, title, age, and a one-line summary of the issue body.
|
||||
|
||||
Let the maintainer pick which issue to dive into.
|
||||
|
||||
## Workflow: Triage a Specific Issue
|
||||
|
||||
### Step 1: Gather context
|
||||
|
||||
Before presenting anything to the maintainer:
|
||||
|
||||
- Read the full issue: body, all comments, all labels, who reported it, when
|
||||
- If there are prior triage notes comments (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
|
||||
|
||||
### Step 2: Present a recommendation
|
||||
|
||||
Tell the maintainer:
|
||||
|
||||
- **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
|
||||
|
||||
Then wait for the maintainer's direction. They may:
|
||||
|
||||
- Agree and ask you to apply labels → do it
|
||||
- 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. This will vary by codebase, but do your best:
|
||||
|
||||
- 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 to the maintainer — 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
|
||||
|
||||
Depending on the outcome:
|
||||
|
||||
- **ready-for-agent** — post an agent brief comment (see [AGENT-BRIEF.md](AGENT-BRIEF.md))
|
||||
- **ready-for-human** — post a comment summarizing the task, what was established during triage, and why it needs human implementation. Use the same structure as an agent brief but note the reason it can't be delegated to an agent (e.g. requires judgment calls, external system access, design decisions, or manual testing).
|
||||
- **needs-info** — post triage notes with progress so far and questions for the reporter (see Needs Info Output below)
|
||||
- **wontfix (bug)** — post a polite comment explaining why, then close the issue
|
||||
- **wontfix (enhancement)** — write to `.out-of-scope/`, post a comment linking to it, then close the issue (see [OUT-OF-SCOPE.md](OUT-OF-SCOPE.md))
|
||||
- **needs-triage** — apply the label. Optionally leave a comment if there's partial progress to capture.
|
||||
|
||||
## 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 and apply the label directly.
|
||||
|
||||
Still show a confirmation of what you're about to do: which labels will be added/removed, and whether you'll post a comment or close the issue. But 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`, post a comment that captures the interview progress and tells the reporter what's needed:
|
||||
|
||||
```markdown
|
||||
## Triage Notes
|
||||
|
||||
**What we've established so far:**
|
||||
|
||||
- point 1
|
||||
- point 2
|
||||
|
||||
**What we still need from you (@reporter):**
|
||||
|
||||
- question 1
|
||||
- question 2
|
||||
```
|
||||
|
||||
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 Previous Sessions
|
||||
|
||||
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
|
||||
@@ -32,7 +32,7 @@ This skill is _informed_ by the project's domain model. The domain language give
|
||||
|
||||
### 1. Explore
|
||||
|
||||
Before exploring, follow [../grill-with-docs/DOMAIN-AWARENESS.md](../grill-with-docs/DOMAIN-AWARENESS.md) — read `CONTEXT.md` and relevant ADRs first.
|
||||
Read the project's domain glossary and any ADRs in the area you're touching 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:
|
||||
|
||||
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
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 backlog backend (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 backlog, triage labels, or domain docs.
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
# Setup Matt Pocock's Skills
|
||||
|
||||
Scaffold the per-repo configuration that the engineering skills assume:
|
||||
|
||||
- **Backlog** — where issues/tickets 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 backlog convention is already in use
|
||||
|
||||
### 2. Present findings and ask
|
||||
|
||||
Summarise what's present and what's missing. Then walk the user through three decisions:
|
||||
|
||||
**Backlog backend.** Default posture: these skills were designed for GitHub. If a `git remote` points at GitHub, propose that. Otherwise (or if the user prefers), offer:
|
||||
|
||||
- **Local markdown** — issues live as files under `.scratch/<feature>/` in this repo
|
||||
- **Other** (Jira, Linear, etc.) — ask the user to describe the workflow in one paragraph; the skill will record it as freeform prose
|
||||
|
||||
**Triage label vocabulary.** Five canonical roles need to be mapped to whatever string the user wants to use in their backlog:
|
||||
|
||||
- `needs-triage` — maintainer needs to evaluate
|
||||
- `needs-info` — waiting on reporter
|
||||
- `ready-for-agent` — fully specified, AFK-ready
|
||||
- `ready-for-human` — needs human implementation
|
||||
- `wontfix` — will not be actioned
|
||||
|
||||
Default: each role's string equals its name. Let the user override any of them.
|
||||
|
||||
**Domain docs.** Confirm the layout — single-context (`CONTEXT.md` + `docs/adr/` at root) or multi-context (`CONTEXT-MAP.md` at root, `CONTEXT.md` per context). Most repos are single-context.
|
||||
|
||||
### 3. Confirm and edit
|
||||
|
||||
Show the user a draft of:
|
||||
|
||||
- The `## Agent skills` block to add to AGENTS.md (or CLAUDE.md if AGENTS.md is absent and CLAUDE.md is present)
|
||||
- The contents of `docs/agents/backlog.md`, `docs/agents/triage-labels.md`, `docs/agents/domain.md`
|
||||
|
||||
Let them edit before writing.
|
||||
|
||||
### 4. Write
|
||||
|
||||
**Prefer AGENTS.md over CLAUDE.md.** It's a cross-tool standard. If neither exists, create AGENTS.md.
|
||||
|
||||
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
|
||||
|
||||
### Backlog
|
||||
|
||||
[one-line summary of where the backlog lives]. See `docs/agents/backlog.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:
|
||||
|
||||
- [backlog-github.md](./backlog-github.md) — GitHub backlog
|
||||
- [backlog-local.md](./backlog-local.md) — local-markdown backlog
|
||||
- [triage-labels.md](./triage-labels.md) — label mapping
|
||||
- [domain.md](./domain.md) — domain doc consumer rules + layout
|
||||
|
||||
For "other" backlog backends, write `docs/agents/backlog.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 backlog backends or restart from scratch.
|
||||
@@ -0,0 +1,22 @@
|
||||
# Backlog: 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 backlog"
|
||||
|
||||
Create a GitHub issue.
|
||||
|
||||
## When a skill says "fetch the relevant ticket"
|
||||
|
||||
Run `gh issue view <number> --comments`.
|
||||
@@ -0,0 +1,19 @@
|
||||
# Backlog: 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 backlog"
|
||||
|
||||
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.
|
||||
+2
-2
@@ -1,6 +1,6 @@
|
||||
# Domain Awareness
|
||||
# Domain Docs
|
||||
|
||||
Consumer rules for any skill that explores a codebase. Producer rules (writing `CONTEXT.md`, offering ADRs) live in [SKILL.md](./SKILL.md).
|
||||
How the engineering skills should consume this repo's domain documentation when exploring the codebase.
|
||||
|
||||
## Before exploring, read these
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
# 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 backlog.
|
||||
|
||||
| Label in mattpocock/skills | Label in our backlog | 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
|
||||
|
||||
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`.
|
||||
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 writing any code:
|
||||
|
||||
|
||||
@@ -1,21 +1,23 @@
|
||||
---
|
||||
name: to-issues
|
||||
description: Break a plan, spec, or PRD into independently-grabbable GitHub issues 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 on the project backlog using tracer-bullet vertical slices. 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 GitHub issues using vertical slices (tracer bullets).
|
||||
Break a plan into independently-grabbable backlog issues using vertical slices (tracer bullets).
|
||||
|
||||
The backlog backend and triage label vocabulary should have been provided to you — run `/setup-matt-pocock-skills` if not.
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Gather context
|
||||
|
||||
Work from whatever is already in the conversation context. If the user passes a GitHub issue number or URL as an argument, fetch it with `gh issue view <number>` (with comments).
|
||||
Work from whatever is already in the conversation context. If the user passes a backlog ticket reference (issue number, URL, or path) as an argument, fetch it from the backlog and read its full body and comments.
|
||||
|
||||
### 2. Explore the codebase (optional)
|
||||
|
||||
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 descriptions should use the project's `CONTEXT.md` vocabulary.
|
||||
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.
|
||||
|
||||
### 3. Draft vertical slices
|
||||
|
||||
@@ -47,16 +49,16 @@ Ask the user:
|
||||
|
||||
Iterate until the user approves the breakdown.
|
||||
|
||||
### 5. Create the GitHub issues
|
||||
### 5. Publish the issues to the backlog
|
||||
|
||||
For each approved slice, create a GitHub issue using `gh issue create`. Use the issue body template below.
|
||||
For each approved slice, publish a new issue to the backlog. Use the issue body template below. Apply the `needs-triage` triage label so each issue enters the normal triage flow.
|
||||
|
||||
Create issues in dependency order (blockers first) so you can reference real issue numbers in the "Blocked by" field.
|
||||
Publish issues in dependency order (blockers first) so you can reference real issue identifiers in the "Blocked by" field.
|
||||
|
||||
<issue-template>
|
||||
## Parent
|
||||
|
||||
#<parent-issue-number> (if the source was a GitHub issue, otherwise omit this section)
|
||||
A reference to the parent ticket on the backlog (if the source was a backlog ticket, otherwise omit this section).
|
||||
|
||||
## What to build
|
||||
|
||||
@@ -70,7 +72,7 @@ A concise description of this vertical slice. Describe the end-to-end behavior,
|
||||
|
||||
## Blocked by
|
||||
|
||||
- Blocked by #<issue-number> (if any)
|
||||
- A reference to the blocking ticket (if any)
|
||||
|
||||
Or "None - can start immediately" if no blockers.
|
||||
|
||||
|
||||
@@ -1,13 +1,15 @@
|
||||
---
|
||||
name: to-prd
|
||||
description: Turn the current conversation context into a PRD and submit it as a GitHub issue. Use when user wants to create a PRD from the current context.
|
||||
description: Turn the current conversation context into a PRD and publish it to the project backlog. 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 backlog backend and triage label vocabulary should have been provided to you — run `/setup-matt-pocock-skills` if not.
|
||||
|
||||
## Process
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
@@ -15,7 +17,7 @@ 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 and submit it as a GitHub issue.
|
||||
3. Write the PRD using the template below, then publish it to the project backlog. Apply the `needs-triage` triage label so it enters the normal triage flow.
|
||||
|
||||
<prd-template>
|
||||
|
||||
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
name: triage
|
||||
description: Triage backlog 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.
|
||||
---
|
||||
|
||||
# Triage
|
||||
|
||||
Move issues on the project backlog through a small state machine of triage roles.
|
||||
|
||||
Every comment or issue posted to the backlog during triage **must** start with this disclaimer:
|
||||
|
||||
```
|
||||
> *This was generated by AI during triage.*
|
||||
```
|
||||
|
||||
## 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
|
||||
|
||||
Two **category** roles:
|
||||
|
||||
- `bug` — something is broken
|
||||
- `enhancement` — new feature or improvement
|
||||
|
||||
Five **state** roles:
|
||||
|
||||
- `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
|
||||
|
||||
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.
|
||||
|
||||
These are canonical role names — the actual label strings used on the backlog 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.
|
||||
|
||||
## Invocation
|
||||
|
||||
The maintainer invokes `/triage` and describes what they want in natural language. Interpret the request and act. Examples:
|
||||
|
||||
- "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?"
|
||||
|
||||
## Show what needs attention
|
||||
|
||||
Query the backlog and present three buckets, oldest first:
|
||||
|
||||
1. **Unlabeled** — never triaged.
|
||||
2. **`needs-triage`** — evaluation in progress.
|
||||
3. **`needs-info` with reporter activity since the last triage notes** — needs re-evaluation.
|
||||
|
||||
Show counts and a one-line summary per issue. Let the maintainer pick.
|
||||
|
||||
## Triage a specific issue
|
||||
|
||||
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.
|
||||
|
||||
2. **Recommend.** Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the issue. Wait for direction.
|
||||
|
||||
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.
|
||||
|
||||
4. **Grill (if needed).** If the issue needs fleshing out, run a `/grill-with-docs` session.
|
||||
|
||||
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.
|
||||
|
||||
## Quick state override
|
||||
|
||||
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.
|
||||
|
||||
## Needs-info template
|
||||
|
||||
```markdown
|
||||
## Triage Notes
|
||||
|
||||
**What we've established so far:**
|
||||
|
||||
- point 1
|
||||
- point 2
|
||||
|
||||
**What we still need from you (@reporter):**
|
||||
|
||||
- question 1
|
||||
- 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".
|
||||
|
||||
## Resuming a previous session
|
||||
|
||||
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.
|
||||
@@ -4,6 +4,4 @@ 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 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`.
|
||||
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.
|
||||
|
||||
Reference in New Issue
Block a user