supermatt plugin

• ask-supermatt

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

• babysit-pr

  Watch a pull request until it is ready to merge: open it when the branch has none, handle review feedback before CI, recover CI within a bounded budget, keep the branch current, and stop without merging.

• code-review

  Review the changes since a fixed point (commit, branch, tag, or merge-base) along three axes: Standards (does the code follow this repo's documented coding standards?), Spec (does the code match what the originating issue/spec asked for?), and Adversarial (how does the change fail in production?). Runs each axis in an independent host reader and applies the repository external-peer policy. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".

• codebase-design

  Shared vocabulary for designing deep modules. Use when designing interfaces, data contracts, state transitions, shared mutable state, or retryable effects; deepening a module; choosing test seams; or consulting the deep-module vocabulary.

• commit

  Commit all changes on the current branch, main included.

• dependency-vetting

  Verify a package or tool is authentic before installing, adding, upgrading, or recommending it. Use whenever a task would add a dependency to a project, suggest a CLI tool, or pull a package from npm, PyPI, crates.io, Go modules, RubyGems, Homebrew, or any other registry. Also use when a registry page, install command, or installed artifact looks inconsistent with the project that supposedly publishes it.

• diagnosing-bugs

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

• domain-modeling

  Build and sharpen a project's domain model. Use when discussing codebase terminology, resolving a vague or overloaded word, stress-testing how domain concepts relate, writing or editing a GLOSSARY.md, or recording or editing an ADR.

• fix-findings

  Apply every finding from the most recent review, audit, verification, or check in this session.

• grill-me

  A relentless interview to sharpen a plan or design.

• grill-with-docs

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

• grilling

  Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, says "grill me", or asks to poke holes in, challenge, or be interviewed about a plan or design, even without the word "grill".

• handoff

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

• ideate

  Generate grounded ideas for what to build next, critique every one, and rank the survivors in a Markdown file.

• implement

  Implement a piece of work based on a spec, tickets, or triaged issues.

• implement-spec

  Implement a whole spec through parallel ticket worktrees on one integration branch.

• improve-architecture

  Assess a codebase's architecture, stop when it is healthy, otherwise find deepening opportunities, design the chosen one, and hand a plan to /implement.

• improve-file-structure

  Assess project file organization and prepare a behavior-preserving migration plan for /implement when reorganization is justified.

• improve-tests

  Cut a test suite to the tests that catch real bugs and its run time to the minimum: measure first, delete or demote low-value tests, fix slow setup, and prove every cut keeps the checks that matter.

• jury

  Put a question or decision to a jury of 3 or 5 subagents: blind independent votes, one anonymized review round, and a verdict with the vote, dissent, and first action when at least one blind vote succeeds.

• orchestrate

  Work through GitHub issues or local Markdown tickets unattended in parallel lanes, with workers in Herdr panes and git worktrees.

• pr

  The shape of a pull request body: a summary diagram, before/after evidence, and merge danger. Use when opening a PR, writing or rewriting a PR description, or when another flow needs a PR body.

• prototype

  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.

• qa

  QA a change in the running program, the way its user meets it: drive a CLI or terminal UI through tmux, a web app through a browser, and check every requested behavior against what you observe. Use after implementing a change and before code review, or when the user asks for a QA pass, a smoke test, or a click-through of a change, or asks whether it actually works.

• recover-ci

  Diagnose and recover a failed CI check or workflow run within a bounded budget of two repair cycles and one transient rerun, with counters the caller holds. Use when a pull request check or a post-merge workflow fails and a caller such as ship-pr or babysit-pr needs it diagnosed, rerun, or repaired. Never merges.

• refactor

  Refactor code at method, file, or project scope. Assesses first and stops when the code is already clean, routes architecture problems elsewhere, and gates edits on test coverage. Language-agnostic.

• research

  Investigate a question against high-trust primary sources and capture the findings as a Markdown file in the repo. Use when the user wants a topic researched, docs or API facts gathered, or reading legwork delegated to a background agent.

• resolving-merge-conflicts

  Resolves an in-progress git merge or rebase conflict by tracing why each side changed, reconciling every conflicted hunk, running the project's checks, and finishing the merge or rebase. Use when a merge, rebase, or pull stops on conflicts, or the user asks to resolve conflicts in an active merge or rebase. Not for standalone conflict-marker cleanup.

• retro

  Conduct a retrospective on a coding session.

• setup-supermatt-skills

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

• ship-pr

  Commit, push, open a pull request, repair CI within bounded attempts, then squash merge and verify post-merge workflows.

• tdd

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

• teach

  Teach the user a new skill or concept, within this workspace.

• to-questionnaire

  Turn a decision you can't fully answer into a questionnaire for someone else to fill in.

• to-spec

  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.

• to-tickets

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

• triage

  Move issues and external PRs through a state machine of triage roles, categorise, verify, grill if needed, and write agent-ready briefs.

• wait-what

  Stop. That last message did not land: re-pitch it.

• wayfinder

  Plan a huge chunk of work (more than one agent session can hold) as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.

• what-would-you-do

  Explain the question you just asked and recommend an answer, with the case for and against each option.

+1