ask-matt

name	ask-matt
description	Ask which skill or flow fits your situation. A router over the skills in this repo.
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. /grill-with-docs — sharpen the idea by interview. Start here whenever you are working in a working directory: it's stateful, retaining what it learns in CONTEXT.md and ADRs. (No working directory? Use /grill-me — see Standalone. Both run the same /grilling primitive; grill-with-docs is the one that leaves a paper trail, which makes it the better of the two whenever a repo is there to leave it in.)

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 /handoff in both directions (a prototype lives in its own directory, which is exactly what /handoff is for — see Phase boundaries):

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

3. Branch — how should implementation cross the context boundary?

   • Small, already clear, no durable spec needed → /implement right here, in the same context window.
   • The approved spec fits one execution session and this thread is coherent → /to-spec, then run /execute-spec-in-fork in Codex App. It creates a same-directory fork, launches /spec-executor, routes decisions back here, validates the returned receipt, and archives a clean completion. Without Codex App task tools or Codex Task Messenger, fork manually from the final SPEC READY, run /spec-executor, and paste its receipt back.
   • Multi-session, parallel, cross-agent, delayed, or context already noisy → /to-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/<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. Run /to-goal on the current frontier ticket and execute that goal in a clean session, regenerating from the next frontier after each slice. Use /to-goal --all only for a persistent harness that must renew context across tickets.

   Both /implement and /spec-executor drive /tdd internally — one red-green slice at a time — then close out with /code-review, a two-axis review (Standards + Spec) of the diff, before committing. /spec-executor preserves the fork contract and receipt; /execute-spec-in-fork owns the Codex task lifecycle around it. 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.

Context hygiene

Keep steps 1–3 in one unbroken context window — don't compact or clear until the final SPEC READY, /to-tickets, or /to-goal boundary — so the grilling, spec, and tickets all build on the same thinking. Fork only from the final marker, never from a half-settled draft. Each execution session then starts from the ticket or the goal.

A fork isolates future conversation, not the filesystem. Parallel implementation threads still need separate worktrees, branches, and ownership boundaries. The fork also inherits a snapshot: later product changes in the planning thread must be sent to the executor explicitly. When the inherited history is already noisy or contradictory, prefer /to-goal, which compresses the approved evidence into a clean contract instead of carrying the mess forward.

The limit on this is the smart zone: the window (~150k tokens on state-of-the-art models) within which the model still reasons sharply. If a session approaches it before SPEC READY or /to-tickets, don't push on degraded — /compact at the nearest phase boundary and carry on (see Phase boundaries).

On-ramps

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

• Bugs and requests piling up → /triage. It moves issues through triage roles and produces agent-ready issues. Run /to-goal on the selected ready issue, then execute it in a fresh session — or pick it up with /implement directly when the context is already clean.

  Triage is only for issues you didn't create — bug reports, incoming feature requests, anything that arrives raw. Tickets that /to-tickets produced are already agent-ready, so don't triage them. /to-goal consumes either kind of ready ticket without repeating triage or re-interviewing you.

• Something's broken → /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 /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 → /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 /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 /to-spec, which collapses the map's linked decisions into a buildable plan, then /to-tickets, /to-goal, and a fresh execution session as usual. Looping the map straight into /implement skips that collapse and throws the linked detail away — go straight to /implement only when the effort turned out genuinely small.

Crossing the context boundary

Four skills move settled work from a planning thread into an execution thread without re-deciding anything.

• /to-goal — compile an approved spec, agent-ready ticket, or tracker frontier into a verifiable execution goal: current state, execution order, completion criteria, constraints, context. Read-only — it never implements, mutates the tracker, or creates a branch. Reach for it when the work is cross-day, cross-agent, parallel, or the current history is too noisy to fork from.
• /goal-crafter — the vocabulary and rules underneath /to-goal: what makes a goal verifiable and how to format it for the target harness. It also runs standalone when you just want a goal written from a fresh interview.
• /execute-spec-in-fork — the Codex App adapter. It creates and names the fork, establishes the Messenger return path, resumes decisions, validates the final receipt, and archives only a correlated clean completion.
• /spec-executor — the implementation side of a fork. It locks onto the inherited SPEC READY contract, its fixed point and its external-action permissions, implements, and returns a SPEC EXECUTION RECEIPT; it stays usable manually and across harnesses.

Fork compresses nothing and inherits everything; /to-goal inherits nothing and compresses everything. Prefer the fork for continuous work, the goal when the context must be left behind.

Codebase health

Not feature work — upkeep.

• /improve-codebase-architecture — run whenever you have a spare moment to keep the codebase good for agents to operate in. It surfaces deepening opportunities; picking one generates an idea you can take into the main flow at /grill-with-docs. It's the survey that finds the candidates; /codebase-design (below) is the bench you design the chosen one on.

Vocabulary underneath

Two model-invoked references that run beneath the other skills — each the single source of truth for its vocabulary. Reach for them directly when the words, not the process, are the problem; or let the skills above pull them in.

• /domain-modeling — sharpen the project's domain language: challenge a fuzzy term, resolve an overloaded word ("account" doing three jobs), record a hard-to-reverse decision as an ADR. It's the active discipline /grill-with-docs drives to keep CONTEXT.md a clean glossary.
• /codebase-design — the deep-module vocabulary (module, interface, depth, seam, adapter, leverage, locality) for designing a module's shape: a lot of behaviour behind a small interface at a clean seam. /tdd and /improve-codebase-architecture both speak it.

Phase boundaries

A phase is a chunk of work inside a session — the grilling, the implementation, the QA. At the boundary between two of them you have five options, and picking between them is the fuzziest decision in this whole map:

• Continue — stay put. Costs nothing, loses nothing.
• /clear — empty the window, when nothing here matters to what's next.
• /handoff — write a portable markdown file. Narrow: only for a new harness, a new directory, a colleague, or forking a side task mid-phase. What it buys is portability. When both sides are existing same-directory Codex App tasks, it can also record the source task so /codex-task-messenger remains available for targeted clarification without making live coordination a requirement.
• Subagent — send a tightly-scoped task to its own window and get a report back.
• /compact — compress this context and seed a fresh session with it. The default, at the bottom of the tree rather than the first reach.

Read PHASE-BOUNDARIES.md for the ordered tree — the five questions, the reasoning behind each branch, and why the primary-source cost makes Continue the one to rule out first. Make the decision at a boundary; mid-phase, continue or split the rest into subagents.

Standalone

Off the main flow entirely.

• /grill-me — the same relentless interview as /grill-with-docs, but stateless: it saves nothing locally and builds no CONTEXT.md. Reach for it when you are not working in a working directory — sharpening a plan, a design, a piece of writing, anything with no repo under it. If you are in a working directory, use /grill-with-docs instead: it runs the same interview and leaves a paper trail, so it is strictly the better one.
• /grilling — the interview primitive itself: rounds, the frontier, facts are the agent's job and decisions are yours. /grill-me and /grill-with-docs are the two named ways in, and /triage, /wayfinder and /improve-codebase-architecture all run it internally. Reach for it directly only when you want the interview with no wrapper around it.
• /roundtable — pressure-test an already-formed decision, plan, or proposal by convening parallel sub-agents that argue it from opposed perspectives — independent statements, anonymous cross-review, then a chaired verdict that preserves dissent. The complement of grilling: grilling interrogates you to sharpen an idea that isn't formed yet; the roundtable takes a settled motion and has model perspectives attack it. They chain naturally — grill until a one-sentence motion exists, then convene the table. Decisions and designs only: reviewing a diff is /code-review's job.
• /resolving-merge-conflicts — work an in-progress merge or rebase conflict hunk by hunk, resolving by intent traced to each side's primary source rather than by picking lines, then finish the operation. It never runs --abort. Standalone and off every flow: reach for it when you are already mid-conflict.
• /prototype — a small, throwaway program that answers one design question: does this state model feel right, or what should this UI look like. Throwaway is a constraint on how the code is written, not a promise to destroy it: the answer folds into the real code, and the prototype itself is kept as a primary source on a prototype/<name> branch out of main, pointed at from the implementation issue. It's the detour in step 2 of the main flow, but reach for it any time a design question is hard to settle on paper.
• /research — delegate reading legwork to a : it investigates a question against , then leaves a cited Markdown file in the repo. Keep working while it reads. The file it produces is something to take the main flow at — research feeds the thinking, it doesn't replace it.

Precondition

/setup-matt-pocock-skills — run before your first engineering flow to configure the issue tracker, triage labels, and doc layout the other skills assume. Custom issue trackers also work.