Developers

Use when the user is designing a new HTTP or GraphQL endpoint, reviewing an API for consistency, or asking how to version, paginate, or error from a public interface. Produces a resource model, an endpoint table, and an OpenAPI 3.1 spec fragment (or a GraphQL SDL fragment) that follows REST best practice.

Use when a user asks for a review of a diff, pull request, patch, or staged changes. Produces a structured review covering security, correctness, performance, style, and tests with severity-labelled findings and concrete fix suggestions tied to file and line.

Use when the user asks to write a commit message, draft a commit, or finalise a commit for a staged diff. Produces a Conventional Commits subject, optional body explaining the why, and BREAKING CHANGE footer when the diff changes a public contract.

Use when the user reports a bug, a failing test, an unexpected output, a production incident, or a behaviour that diverges from expectation. Runs a structured session — reproduce, isolate, hypothesise, verify, fix, and add a regression test — and never ships a "fix that coincidentally works".

Use when the user asks for a README, API docs, an ADR, a changelog, a runbook, or any structured technical write-up. Generates the requested artifact from the codebase and git history, following widely-adopted conventions (Keep a Changelog, MADR ADRs, OpenAPI-driven API docs).

Use when the user asks to scaffold a new project, start a repo from scratch, or set up a greenfield service in TypeScript/Node, Python/FastAPI, Go, or Rust. Produces a working layout with linting, formatting, tests, pre-commit hooks, GitHub Actions CI, a Dockerfile, a .gitignore, a README skeleton, and a license file.

Use when the user asks to clean up, simplify, rename, extract, inline, or restructure code without changing behaviour. Performs Fowler-style refactorings in small steps, running the test suite after every step; never proceeds when tests fail.

Use when the user asks to "write tests for", "add unit tests", "cover this function", or needs a regression test for a bug. Reads existing tests to infer the repo's conventions (framework, file layout, naming, setup/teardown, fixtures), then generates AAA-style tests for a target file or function, including deterministic edge cases.

Use when a developer has written code for a single feature and wants a full pre-commit gate (tests generated, code reviewed, commit message drafted) in one pass. Chains test-writer, code-review, and commit-message end-to-end and produces a single report summarising the run.