matt-loop

Ask which skill or flow fits your situation. A router over the skills in this repo.

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".

Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.

Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a CONTEXT.md, or recording or editing an ADR.

A relentless interview to sharpen a plan or design.

A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.

Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.

Compact the current conversation into a handoff document for another agent to pick up.

Implement a piece of work based on a spec or set of tickets.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

Turns a completed grilling interview log (question → decision → rationale triples) into a single self-contained, Notion-style light-theme HTML file anyone can skim and understand. Called by matt-auto right after its interview stage finishes — do not trigger this standalone on a bare grill-me/grill-with-docs session; matt-auto is what pulls it in.

Use when the user explicitly invokes matt-auto to take an already-discussed idea through Matt Pocock's full engineering flow — interview, spec, tickets, implementation. A decision delegate answers implementation-level questions on the user's behalf; OpenCode routes work to task-appropriate models automatically, while other platforms retain the effort picker. Material decisions still escalate immediately. Invoke with `--yolo` to skip the pre-publish confirm and run unattended to completion, or `--free` to use free-only OpenCode routing.

Use when the user hands you a queue of already-open PRs (numbers, plus the branch they land on) and wants them merged cleanly. Most PR queues turn painful because each merge moves the target branch out from under everyone still waiting, so what should be one sitting becomes merge, conflict, merge, conflict, on repeat. This skill preps every PR in parallel using isolated git worktrees, then lands them one at a time, re-checking each against the moving target right before it merges. Trigger on "merge these PRs", "clear the PR queue", requests to batch-merge or untangle a stack of conflicting PRs, or a plain list of PR numbers plus a target branch — even without the words "skill" or "queue".

Use when the user wants you to babysit, watch, monitor, or shepherd one open GitHub PR until it is merge-ready by handling its checks, review feedback, and PR-caused failures. Does not merge unless explicitly requested. On OpenCode, direct invocation automatically routes work by complexity.

Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.

Interactive QA session where user reports bugs or issues conversationally, and the agent files GitHub issues. Explores the codebase in the background for context and domain language. Use when user wants to report bugs, do QA, file issues conversationally, or mentions "QA session".

Create a detailed refactor plan with tiny commits via user interview, then file it as a GitHub issue. Use when user wants to plan a refactor, create a refactoring RFC, or break a refactor into safe incremental steps.

Use when you need to resolve an in-progress git merge/rebase conflict. On OpenCode, direct invocation automatically routes semantic conflict resolution to a deep model.

Configure this repo for the engineering skills: set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.

Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

Turn the current conversation into a spec and publish it to the project issue tracker: no interview, just synthesis of what you've already discussed.

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).