refactor: friendlier setup flow + one-file-per-ticket local tracker

Rework /setup-matt-pocock-skills to ask fewer, friendlier questions and
align the local-markdown issue tracker with the current spec.

- Triage labels: asked 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: no longer a setup question. The
  GitHub/GitLab templates still carry the flag, defaulted off; 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: one file per ticket under
  .scratch/<feature>/issues/<NN>-<slug>.md, never a single combined
  tickets.md. /to-tickets, ask-matt, and the local template now agree, and
  the spec file is spec.md (not PRD.md) to match /to-spec.
- Re-sync docs pages for setup-matt-pocock-skills and to-tickets; changeset.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Matt Pocock
2026-07-10 09:37:25 +01:00
co-authored by Claude Opus 4.8
parent d574778f94
commit 44eed54518
7 changed files with 51 additions and 56 deletions
+1 -1
View File
@@ -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/<feature>/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.