/ask-matt

name: ask-matt
description: Recommends the skill or flow that fits the user's situation. A router over the skills in this repo. Use when the user asks which skill to use, is unsure what fits, or needs a pointer to the right workflow.
disable-model-invocation: true

Ask Matt

You don't remember every skill, so ask.

A **flow** is a path through the skills. Most paths run along one **main flow**, and two **on-ramps** merge onto it. Everything else is standalone, or a vocabulary layer that runs underneath.

The main flow: idea → ship

The route most work travels. You have an idea and want it built.

1. **`/mattpocock:grill-with-docs`** sharpens the idea by interview. Start here when you **have a codebase**: it's stateful, retaining what it learns in `CONTEXT.md` and ADRs. (No codebase? Use `/mattpocock:grill-me` instead, covered under Standalone. Both run the same `/mattpocock:grilling` primitive; `grill-with-docs` is the one that leaves a paper trail.) 2. **Branch: can you settle every question in conversation?** If a question needs a runnable answer (state, business logic, a UI you have to see), detour through a prototype, bridged by **`/mattpocock:handoff`** in both directions (see Crossing sessions):

• **`/mattpocock:handoff`** out, then open a fresh session against that file,
• **`/mattpocock:prototype`** to answer the question with throwaway code,
• **`/mattpocock:handoff`** back what you learned, and reference it from the original idea thread.

3. **Branch: is this a multi-session build?**

• **Yes** → **`/mattpocock:to-spec`** (turn the thread into a spec), then **`/mattpocock: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/<feature>/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 **`/mattpocock:implement`** per ticket, **clearing context between each one**.
• **No** → **`/mattpocock:implement`** right here, in the same context window.

Either way, **`/mattpocock:implement`** builds each issue by driving **`/mattpocock:bdd`** internally (Discovery → Formulation, then Automation delegated to `/mattpocock:tdd`) (one vertical slice at a time), then closes out by running **`/mattpocock:code-review`**, a two-axis review (Standards + Spec) of the diff, before committing. Reach for **`/mattpocock:bdd`** on its own when you want to define Gherkin scenarios for a feature, and **`/mattpocock:tdd`** on its own when you want to write tests within the BDD Automation phase. Reach for **`/mattpocock:code-review`** on its own whenever you want to review a branch or PR against a fixed point.

Context hygiene

Keep steps 1–3 in **one unbroken context window** (don't compact or clear until after `/mattpocock:to-tickets`) so the grilling, spec, and tickets all build on the same thinking. Each `/mattpocock:implement` then starts fresh, working from the ticket.

The limit on this is the **[smart zone](https://www.aihero.dev/ai-coding-dictionary/smart-zone)**: the window (~120k tokens on state-of-the-art models) within which the model still reasons sharply. If a session approaches it before `/mattpocock:to-tickets`, don't push on degraded; `/mattpocock:handoff` and continue in a fresh thread.

CRITICAL: Route by scenario, not by habit

Wayfinder is only for work too big for one session — never a well-scoped feature. Triage is only for issues the user didn't create — never for the tickets `/mattpocock:to-tickets` produced. Keep steps 1–3 in one unbroken context window: no compact or clear until after `/mattpocock:to-tickets`.

On-ramps

A starting situation that generates work, then merges onto the main flow.

• **Bugs and requests piling up** → **`/mattpocock:triage`**. It moves issues through triage roles and produces agent-ready issues, which **`/mattpocock:implement`** later picks up.

Triage is only for issues **you didn't create**: bug reports, incoming feature requests, anything that arrives raw. Tickets that `/mattpocock:to-tickets` produced are already agent-ready, so **don't triage them**.

• **Something's broken** → **`/mattpocock:diagnosing-bugs`**. For the hard ones: the bug that resists a first glance, the intermittent flake, the regression that crept in between two known-good states. It refuses to theorise until it has a **tight feedback loop** (one command that already goes red on *this* bug), then fixes with a regression test. Its post-mortem hands off to **`/mattpocock:improve-codebase-architecture`** when the real finding is that there's no good seam to lock the bug down.

• **A huge, foggy effort: a greenfield project or a huge feature build, too big for one session** → **`/mattpocock:wayfinder`**, the most cognitively demanding flow here. When the way from here to the destination isn't visible yet, it charts a **shared map** of **decision tickets** on the issue tracker and resolves them one at a time, producing **decisions, not deliverables**, until the fog is pushed back and the way is clear. Where **`/mattpocock:grill-with-docs`** sharpens an idea you can hold in one session, wayfinder is for the idea you can't, and it's slower and denser, so save it for exactly that, never a well-scoped feature.

When the map clears, **it hands off, it doesn't build**: merge onto the main flow at **`/mattpocock:to-spec`**, which collapses the map's linked decisions into a buildable plan, then `/mattpocock:to-tickets` and `/mattpocock:implement` as usual. Looping the map straight into `/mattpocock:implement` skips that collapse and throws the linked detail away, so go straight to `/mattpocock:implement` only when the effort turned out genuinely small.

Codebase health

Not feature work, just upkeep.

• **`/mattpocock:improve-codebase-architecture`** runs whenever you have a spare moment to keep the codebase good for agents to operate in.