Power skills — slash commands
Core skills are templated artefacts you invoke by pasting raw text. Power skills are thirteen automation workflows you run explicitly as slash commands.
Each confirms before saving and exports a PDF automatically where applicable; the full output structure lives in each command file in .claude/commands/.
| Command | What it's for | What you provide |
|---|---|---|
| /generate-module-registry | Builds the module registry Baxter checks module names against in every artefact — folding submodules, CRUD actions, dashboards, and standalone AI features into their parent module, with each module's filename slug included. | Nothing — just run it. Optionally point it at other reference material (notes, a spreadsheet, a prior registry) to reconcile in too. Writes artefacts/module-registry/modules.md. |
| /generate-role-registry | Builds the role registry Baxter checks role names against in every artefact that says who can do what. Reads the codebase's access model — role definitions, seed data, permission enforcement, role-based UI branching, the role-management screen — and lists each built-in role with its code identifier, scope, and out-of-the-box access. Customer-created custom roles, permissions, job titles held as data, account states, service accounts, and subscription tiers are excluded, and the exclusions are recorded in the file rather than dropped silently. | Nothing — just run it. It needs a codebase and has no other source: a BRD or a permissions spreadsheet cannot stand in, so with an empty coderepo/ it stops rather than guessing. Writes artefacts/role-registry/roles.md and context/roles.md. |
| /generate-test-plan | Synthesises a full, structured test plan from a module's saved test cases, plus PDF, written to test-plans/{MODULE}/. Requires test cases first — Baxter mentions the option once they are saved, never runs it automatically. | A module with test cases in test-cases/{MODULE}/, or pick one when prompted. |
| /generate-release-notes | Pre-release notes grouped by module, plus PDF, written to release-notes/. Adds issue and tracker links for whichever integrations are enabled. | A sprint number and the issue numbers to include. |
| /validate-release | Confirms every release-note item is on staging, flags undocumented changes and DB migrations, plus PDF. | Release notes (from release-notes/, or any path), two branch snapshots in coderepo/branches/, and a sprint number. |
| /compare-branches | Diffs two branch snapshots — technical, plain-English, or both — plus PDF, written to branch-comparisons/. | Two branch folders in coderepo/branches/ (folder name becomes the label). |
| /generate-retrospective-brd | Reads a codebase and drafts a client-facing BRD — modules, roles and personas, the Who/Why/What, and each module's high-level features, every module marked Existing. Standalone: no PRD, CR, or module registry required. The document says on its face that it was derived from code, so it is never confused with a BRD written before the build. | A codebase folder path — or nothing, to use coderepo/. Writes artefacts/business-requirements/{date}-{product}-retrospective-BRD.md. |
| /generate-samples Beta | Realistic sample data records derived entirely from your real schema and lookup values. (experimental) | Nothing — add a number 1–3 for more records. Writes JSON to artefacts/sample-data/. |
| /generate-ai-feature-registry | Works out where AI lives in your codebase — model clients, prompts, feature flags — then drafts a registry of every AI feature: trigger, code location, flag, status. No assumed folder layout. | Nothing — just run it. Writes artefacts/product-documentation/ai-feature-review/ai-features.md. |
| /ai-feature-data-audit | Traces exactly what data feeds one AI feature — tables, fields, filters — plus a QA testing guide. | The AI feature name. Presented in the response; saved only if you ask. |
| /generate-ai-feature-dependency-map | Maps which product modules each AI feature depends on, and the impact if one is disabled. | Nothing — just run it (or name a feature). |
| /brainstorm-change | A second-opinion sweep on a CR in any state: cross-module ripple effects, recurring patterns elsewhere in the app, alternative implementations, and UX ideas. | A CR name or path — or none, for a CR still being discussed or drafted in the current conversation. |
| /visualize-change | A single self-contained, clickable HTML prototype demonstrating a CR's behaviour, grounded in the real product — not a design deliverable. | A CR name, path, or "this" for the CR being drafted in the current conversation. Writes to artefacts/change-visualisations/. |
Baxter
The Agentic BA
Ready to work with Baxter?
Open source and free. Drop the harness into any project, open it in Claude Code, Cursor, or GitHub Copilot, and paste your first raw request.