butler

Scaffold a new golden case for @butler/evals — validate and append the case to golden.jsonl, re-capture the baseline, and confirm the eval gate still passes. Use when a real agent failure or escaped bug should become a regression benchmark.

Work the Butler ready-for-agent issue queue in priority order — select the highest-priority unblocked issue (P0 > P1 > P2) and run /implement-issue on it, looping up to a per-run cap. Use ONLY when explicitly asked to "work the queue" / "implement the next issue(s)", or when fired by the scheduled routine. Do not auto-run.

Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.

Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context.

End-to-end implementation of a GitHub issue — from reading the issue through TDD, code review, PR creation, CI monitoring, and merge. Use when the user says "implement issue

Phase 9 retrospective — read a window or set of recently-merged PRs, classify each harness/run finding with the eval-failure taxonomy, and append tagged learnings to docs/retro/learnings.md. Propose-only — writes ONLY under docs/retro/. Use when explicitly asked to "run a retrospective", "retro the last N PRs", or to review a batch of merged work for harness lessons. Do not auto-run.

Triage issues through a state machine driven by triage roles. Use when user wants to create an issue, triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.

Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.

Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.

Build a throwaway prototype to flesh out a design before committing to it. Routes between two branches — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route. Use when the user wants to prototype, sanity-check a data model or state machine, mock up a UI, explore design options, or says "prototype this", "let me play with it", "try a few designs".

Investigate domain fit, prior art, and technical options before committing to a PRD. Use when evaluating a new feature, library, architecture pattern, or integration approach.

Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.

Generate a QA checklist from PRD and issues, then guide manual verification with triage routing for findings. Use after code review passes (Phase 7) for final human judgment.

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

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/PRD asked for?) — and run an adversarial "devil's advocate" pass (the pr-review-toolkit agents) before human review. All three run as parallel sub-agents and report side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X". This is Phase 7 of docs/WORKFLOW.md.

Provision a complete demo Club graph into the local/dev Supabase for Phase-8 manual QA and Playwright e2e — 1 Club, 1 Admin, 1 Staff, 4 Members across 2 Membership Types, tee-sheet settings, sample Bookings (including a Guest with marketing consent), and one Block.

Generate or refresh the OpenAPI 3.1 spec for @butler/api from the live Hono routes and the @butler/shared Zod schemas, so the API has a single source of truth. Use when an endpoint or its request/response schema changes, or when you need an up-to-date API spec.

Deploy Butler to production (Cloudflare Workers API + Pages frontend) with pre-flight checks and a post-deploy /health smoke check

Scaffold a new accessible frontend component (shadcn/Radix/CVA/Tailwind) plus a test stub, following Butler's UI and a11y conventions

Start the butler dev environment (API + frontend). Use when asked to run, start, or launch the app, or to verify a change works in the browser.

Bootstrap the local development environment — checks prerequisites, starts Supabase, generates env files, launches dev servers

Scaffold a new timestamped Supabase migration file in supabase/migrations/