diff --git a/.changeset/friendlier-setup-and-local-tickets.md b/.changeset/friendlier-setup-and-local-tickets.md new file mode 100644 index 0000000..c74af24 --- /dev/null +++ b/.changeset/friendlier-setup-and-local-tickets.md @@ -0,0 +1,12 @@ +--- +"mattpocock-skills": patch +--- + +Make `/setup-matt-pocock-skills` friendlier and align the local-markdown tracker with the current spec. + +- **Triage labels** are now asked about only when the `triage` skill is installed, and then as a single recommended-yes question ("keep the default triage labels?") instead of an override interrogation. When `triage` isn't installed, the section — and `docs/agents/triage-labels.md` — are skipped. +- **External PRs as a request surface** is no longer a setup question. The GitHub/GitLab templates still carry the flag, defaulted off; a user can flip it in `docs/agents/issue-tracker.md` later. +- **Domain docs** default to single-context without asking; multi-context is only offered when the repo shows monorepo signals. +- **Local-markdown tickets** are now one file per ticket under `.scratch//issues/-.md` — never a single combined `tickets.md`. `/to-tickets` and the local issue-tracker template now agree, and the spec file is `spec.md` (not `PRD.md`) to match `/to-spec`. + +Docs pages for `setup-matt-pocock-skills` and `to-tickets` re-synced. diff --git a/docs/engineering/setup-matt-pocock-skills.md b/docs/engineering/setup-matt-pocock-skills.md index 47d793e..003b8b6 100644 --- a/docs/engineering/setup-matt-pocock-skills.md +++ b/docs/engineering/setup-matt-pocock-skills.md @@ -24,17 +24,17 @@ Reach for it **once per repo, before the first use of any other engineering skil ## The three decisions -It walks you through three choices, one at a time, each with a plain-language explainer (it assumes you don't already know the terms): +It leads each with a recommended answer you can accept in a word, and skips whatever it can already infer — so most runs are a couple of quick confirmations: -- **Issue tracker** — where work is tracked, so `triage`/`to-spec`/`to-tickets` know whether to call `gh`, `glab`, write markdown under `.scratch/`, or follow a workflow you describe. GitHub, GitLab, local markdown, or other. -- **Triage labels** — the strings behind the five canonical roles (`needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix`), mapped to labels you've actually configured so `triage` applies real ones instead of creating duplicates. -- **Domain docs** — whether the repo has one `CONTEXT.md` or a multi-context map, so skills that read domain language look in the right place. +- **Issue tracker** — where work is tracked, so `triage`/`to-spec`/`to-tickets` know whether to call `gh`, `glab`, write markdown under `.scratch/`, or follow a workflow you describe. GitHub, GitLab, local markdown, or other. (It proposes the one that matches your `git remote`.) +- **Triage labels** — asked only if the `triage` skill is installed, and then just: keep the default labels (`needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix`)? Say no only if your tracker already uses other names, so `triage` applies real ones instead of creating duplicates. +- **Domain docs** — assumed single-context (one `CONTEXT.md` + `docs/adr/` at the root), which fits almost every repo; it only raises a multi-context map when it spots monorepo signals. -The output is three files — `docs/agents/issue-tracker.md`, `docs/agents/triage-labels.md`, `docs/agents/domain.md` — plus an `## Agent skills` block pointing to them in whichever of `CLAUDE.md` / `AGENTS.md` the repo already uses. Those files are the shared substrate the rest of the toolkit stands on. +The output is a set of files under `docs/agents/` — `issue-tracker.md`, `domain.md`, and `triage-labels.md` when `triage` is installed — plus an `## Agent skills` block pointing to them in whichever of `CLAUDE.md` / `AGENTS.md` the repo already uses. Those files are the shared substrate the rest of the toolkit stands on. ## It's working if -- Three files land under `docs/agents/`, and an `## Agent skills` section appears in your `CLAUDE.md` or `AGENTS.md`. +- `issue-tracker.md` and `domain.md` land under `docs/agents/` (plus `triage-labels.md` when `triage` is installed), and an `## Agent skills` section appears in your `CLAUDE.md` or `AGENTS.md`. - The tracker it proposes matches your real `git remote`, and the labels match strings that already exist in your repo. - Afterwards, `triage` and `to-tickets` act on the right place with the right labels instead of asking or guessing. diff --git a/docs/engineering/to-tickets.md b/docs/engineering/to-tickets.md index 113f891..f061b02 100644 --- a/docs/engineering/to-tickets.md +++ b/docs/engineering/to-tickets.md @@ -30,7 +30,7 @@ Reach for it once you have an agreed plan or a written spec and you want it spli The blocking edges are the whole point. They make one set of tickets read two ways, depending on the tracker: -- **Local files** → a single `tickets.md` in the repo root, the edges written as text. You work it top-to-bottom, by hand, staying in the loop. +- **Local files** → one file per ticket under `.scratch//issues/`, numbered blockers-first, the edges written as text. You work them top-to-bottom, by hand, staying in the loop. - **A real tracker (GitHub, Linear)** → one issue per ticket, the edges as native blocking links (or sub-issues). Any ticket whose blockers are all done is on the **frontier** and can be grabbed — so several agents can run at once. The edges live in the ticket regardless of medium; the medium only decides whether anything acts on them in parallel. `to-tickets` produces the artifact — how you run it (sequential by hand, or a parallel fleet) is up to you. diff --git a/skills/engineering/ask-matt/SKILL.md b/skills/engineering/ask-matt/SKILL.md index cc1866a..0c2a530 100644 --- a/skills/engineering/ask-matt/SKILL.md +++ b/skills/engineering/ask-matt/SKILL.md @@ -20,7 +20,7 @@ The route most work travels. You have an idea and want it built. - **`/prototype`** to answer the question with throwaway code, - **`/handoff`** back what you learned, and reference it from the original idea thread. 3. **Branch — is this a multi-session build?** - - **Yes** → **`/to-spec`** (turn the thread into a spec), then **`/to-tickets`** to split it into tracer-bullet tickets, each declaring its **blocking edges**. On a local tracker that's an ordered `tickets.md` you work by hand; on a real tracker the edges become native blocking links, so any ticket whose blockers are done can be grabbed — kick off **`/implement`** per ticket, **clearing context between each one**. + - **Yes** → **`/to-spec`** (turn the thread into a spec), then **`/to-tickets`** to split it into tracer-bullet tickets, each declaring its **blocking edges**. On a local tracker that's one file per ticket under `.scratch//issues/`, worked blockers-first by hand; on a real tracker the edges become native blocking links, so any ticket whose blockers are done can be grabbed — kick off **`/implement`** per ticket, **clearing context between each one**. - **No** → **`/implement`** right here, in the same context window. Either way, **`/implement`** builds each issue by driving **`/tdd`** internally — one red-green slice at a time — then closes out by running **`/code-review`**, a two-axis review (Standards + Spec) of the diff, before committing. Reach for **`/tdd`** on its own when you just want to build a concrete behaviour test-first without a full spec, and **`/code-review`** on its own whenever you want to review a branch or PR against a fixed point. diff --git a/skills/engineering/setup-matt-pocock-skills/SKILL.md b/skills/engineering/setup-matt-pocock-skills/SKILL.md index 612dfe5..aecf855 100644 --- a/skills/engineering/setup-matt-pocock-skills/SKILL.md +++ b/skills/engineering/setup-matt-pocock-skills/SKILL.md @@ -26,12 +26,14 @@ Look at the current repo to understand its starting state. Read whatever exists; - `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 +- Is the `triage` skill installed? (a `triage` skill folder alongside this one, or `triage` in your available skills.) This decides whether Section B runs at all. +- Monorepo signals — a `pnpm-workspace.yaml`, a `workspaces` field in `package.json`, or a populated `packages/*` with its own `src/`. Present only in a genuinely large multi-package repo; their absence means single-context, which is almost every repo. ### 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. +Summarise what's present and what's missing. Then take the sections in order — one section, one answer, then the next. -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. +Lead each section with the recommended answer so the user can accept it in a word. Give a one-line explainer only when the choice genuinely branches; skip the section entirely when exploration already settled it (Section B when `triage` isn't installed, Section C when there's no monorepo). **Section A — Issue tracker.** @@ -44,41 +46,26 @@ Default posture: these skills were designed for GitHub. If a `git remote` points - **Local markdown** — issues live as files under `.scratch//` 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 -If — and only if — the user picked **GitHub** or **GitLab**, ask one follow-up: +Record the choice in `docs/agents/issue-tracker.md`. The GitHub and GitLab templates carry a "PRs as a request surface" flag, defaulted **off** — leave it off and don't raise it; a user who wants external PRs in the triage queue can flip the flag in the file later. -> Explainer: Open-source repos often receive feature requests as pull requests, not just issues — a PR is an issue with attached code. If you turn this on, `/triage` pulls *external* PRs into the same queue and runs them through the same labels and states as issues (collaborators' in-flight PRs are left alone). Leave it off if PRs aren't a request surface for you. +**Section B — Triage label vocabulary.** Skip this section entirely if the `triage` skill isn't installed (exploration told you) — an uninstalled skill needs no labels. -- **PRs as a request surface** — yes / no (default: no). Record the answer in `docs/agents/issue-tracker.md`. For local-markdown and other trackers, skip this question — there are no PRs. +If it is installed, ask exactly one question: -**Section B — Triage label vocabulary.** +> Do you want to keep the default triage labels? (recommended: **yes**) -> 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 defaults are the five canonical roles, each label string equal to its name: `needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix`. On **yes**, write them as-is. Only if the user says no — usually because their tracker already uses other names (e.g. `bug:triage` for `needs-triage`) — collect the overrides so `triage` applies existing labels instead of creating duplicates. -The five canonical roles: +**Section C — Domain docs.** Default to **single-context** — one `CONTEXT.md` + `docs/adr/` at the repo root. This fits almost every repo; write it without asking. -- `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`, `diagnosing-bugs`, `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). +Offer **multi-context** — a root `CONTEXT-MAP.md` pointing to per-context `CONTEXT.md` files — only when exploration found monorepo signals. Then confirm which layout they want. ### 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` +- The contents of `docs/agents/issue-tracker.md`, `docs/agents/domain.md`, and `docs/agents/triage-labels.md` (the last only when `triage` is installed) Let them edit before writing. @@ -101,7 +88,7 @@ The block: ### Issue tracker -[one-line summary of where issues are tracked, plus whether external PRs are a triage surface]. See `docs/agents/issue-tracker.md`. +[one-line summary of where issues are tracked]. See `docs/agents/issue-tracker.md`. ### Triage labels @@ -112,12 +99,14 @@ The block: [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: +Include the `### Triage labels` sub-block, and write `docs/agents/triage-labels.md`, only when `triage` is installed and Section B ran. When it isn't, both are omitted. + +Then write the docs files using the seed templates in this skill folder as a starting point: - [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 +- [triage-labels.md](./triage-labels.md) — label mapping (only if `triage` is installed) - [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. diff --git a/skills/engineering/setup-matt-pocock-skills/issue-tracker-local.md b/skills/engineering/setup-matt-pocock-skills/issue-tracker-local.md index 5f09fde..6b124b3 100644 --- a/skills/engineering/setup-matt-pocock-skills/issue-tracker-local.md +++ b/skills/engineering/setup-matt-pocock-skills/issue-tracker-local.md @@ -1,12 +1,12 @@ # Issue tracker: Local Markdown -Issues and PRDs for this repo live as markdown files in `.scratch/`. +Issues and specs (you may know a spec as a PRD) for this repo live as markdown files in `.scratch/`. ## Conventions - One feature per directory: `.scratch//` -- The PRD is `.scratch//PRD.md` -- Implementation issues are `.scratch//issues/-.md`, numbered from `01` +- The spec is `.scratch//spec.md` +- Implementation issues are one file per ticket at `.scratch//issues/-.md`, numbered from `01` — never a single combined tickets file - 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 diff --git a/skills/engineering/to-tickets/SKILL.md b/skills/engineering/to-tickets/SKILL.md index dceaa73..3b91c92 100644 --- a/skills/engineering/to-tickets/SKILL.md +++ b/skills/engineering/to-tickets/SKILL.md @@ -1,6 +1,6 @@ --- name: to-tickets -description: Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker — edges as text in a local file, or native blocking links on a real tracker. +description: Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker — edges as text in one file per ticket locally, or native blocking links on a real tracker. disable-model-invocation: true --- @@ -59,33 +59,27 @@ Iterate until the user approves the breakdown. Publish the approved tickets. **How** depends on the tracker `/setup-matt-pocock-skills` configured — the tickets are the same either way, only the shape of the blocking edges changes: -- **Local files** → write one `tickets.md` in the repo root, all tickets in dependency order (blockers first), each with its "Blocked by" listing the titles it depends on. Use the file template below. +- **Local files** → write one file per ticket under `.scratch//issues/-.md`, numbered from `01` in dependency order (blockers first). Each file's "Blocked by" lists the numbers/titles it depends on. Use the per-ticket file template below — one ticket per file, never a single combined file. - **A real issue tracker (GitHub, Linear, …)** → publish one issue per ticket in dependency order (blockers first) so each ticket's blocking edges can reference real identifiers. Use the platform's native blocking / sub-issue relationship where it has one; otherwise set each ticket's "Blocked by" to the blocking issues. Apply the `ready-for-agent` triage label unless instructed otherwise — the tickets are agent-grabbable by construction. -Do NOT close or modify any parent issue. - - - -# Tickets: - -A one-line summary of what these tickets build. Reference the source spec if there is one. - Work the **frontier**: any ticket whose blockers are all done. For a purely linear chain that means top to bottom. -## +Do NOT close or modify any parent issue. + + + +# — **What to build:** the end-to-end behaviour this ticket makes work, from the user's perspective — not a layer-by-layer implementation list. -**Blocked by:** the titles of the tickets that gate this one, or "None — can start immediately". +**Blocked by:** the numbers/titles of the tickets that gate this one, or "None — can start immediately". + +**Status:** ready-for-agent - [ ] Acceptance criterion 1 - [ ] Acceptance criterion 2 -## - -... - - +