Meet Baxter
Agentic Business Analysis is here!
Baxter is your AI business analyst, built on the Agentic Business Analysis Framework (ABAF) — working right inside Claude Code, Cursor, or GitHub Copilot. Paste any raw request — an email, a Slack message, a voice note — and Baxter drafts the right artefact and checks every word against your real codebase before you see it. Templated change requests, bug reports and much more: verified, version-controlled, and never at odds with your own code.
Most dev teams waste time building the wrong things.
Not because their developers aren't good — because the requirements were written from memory, never checked against the codebase, and nobody caught the contradiction until QA. Baxter closes that gap: paste any raw client request and it classifies, drafts, and checks the artefact against your actual code before anything gets saved.
What's a "harness" — and why should a non-technical BA care?
A harness isn't an app you log into. It's the layer that makes an AI give you ridiculously better results — the instructions, rules, templates, and worked samples that turn a generic model into a disciplined specialist. Baxter is a business-analysis harness: you clone it, drop your codebase into coderepo/, and point the AI coding assistant your dev team already runs — Claude Code, Cursor, or GitHub Copilot — at it. It becomes a business analyst that reads your code before it writes a word. No new account. No server. Nothing to subscribe to — just the discipline of a senior BA, running on the tool that's already open on someone's laptop.
Just a folder
Clone the harness, then drop your codebase into coderepo/. Nothing to install, host, or maintain.
Works inside tools you already use
Claude Code, Cursor, GitHub Copilot. No separate app to context-switch into — you write to Baxter the same place you already work.
Verified, not just generated
Every artefact is checked against your real codebase before you see it — so what a non-technical BA produces is something a developer can build from immediately.
New to the term? Read the full definition of an AI harness →
Requirements are the most important artefact in software. They're also the most neglected.
Scattered across Confluence, Jira, Notion, and Slack — no single source of truth.
Decisions live in a standup or a six-month-old thread, then get made again — usually wrong.
Locked in proprietary tools an AI agent can't read, verify, or build on.
Read why this breaks SDLC delivery — and how Markdown + git fixes it →
Just say what you need. Baxter figures out the rest.
Paste anything — no commands, no template names, no forms. Core skills turn raw text into a templated, verified artefact. Power skills are slash-command automations for the work around them.
BRD — before development
Answers who the product is for, why it exists, and what each module does — features one line each, nothing technical. From a raw client request, before any code exists.
For: clients & leadership — the business case
PRD — before development
Consolidates every CR touching one module into a single requirements picture — what should happen, not what the code does. All the detail a BRD deliberately leaves out.
For: teams
PD — after development
Documents how a module is actually implemented, read straight from the real codebase once its CRs are built.
For: teams
PRD = requirements, before implementation. PD = documentation, after implementation. Confused which one you need? Audience is the fastest test: going in front of a client or leadership for sign-off is a BRD; a module's consolidated internal detail is a PRD. The two never overlap — a BRD carries no functional requirements, acceptance criteria, or rules, because all of that lives in the PRD.
Product already built without a BRD? /generate-retrospective-brd writes one from the codebase — labelled retrospective throughout, so it is never mistaken for a BRD written before the build.
| Artefact | Say something like… |
|---|---|
| 🐛 Bug Report BR | "The login page returns a 500 after the user submits without a password" |
| 🔄 Change Request CR | "Add a bulk export option to the reports list view" |
| 🤖 AI Feature AI | "We need AI to auto-suggest categories based on the item description" |
| 📋 Business Requirements BRD | "Write up the BRD for recurring invoices" |
| 📑 Product Requirements PRD | "Consolidate the requirements for the billing module" |
| 📖 Product Documentation PD | "Document the billing module — how it works and who can access it" |
| 🏗️ Implementation Plan TIP | "Write an implementation plan for the bulk import feature" |
| 🧪 Test Cases TC | "I need test cases for the authentication module" |
| 📐 Diagram / ERD DIA · ERD | "Diagram the checkout flow from cart to confirmation" |
| ✉️ Client Clarification CLQ | "Offered automatically when the sanity check finds a ❌ blocker" |
Baxter always confirms the artefact type before writing. Reply with the code, a number, or proceed.
Every one of these is checked against your codebase — that is the point, and a partly-built codebase is completely normal: whatever is there gets analysed as it is. The single exception is a BRD, which is written before code exists, so a project that has not started yet begins there. Where are you starting from? →
Twelve slash-command workflows for the automation around your artefacts.
Confirms every release note item is on staging and catches undocumented changes going to production.
Scans your codebase — and any other reference material you point it at — into one consolidated module table, filename slug included, ready to verify every other artefact.
Point it at a codebase and get a client-facing BRD — modules, roles, and high-level features inferred from the code. Runs standalone, and the document says on its face that it was derived from code.
Realistic JSON sample records derived from your real data model — ready to seed or test with.
Synthesises a full test plan from a module's saved test cases, with a matching PDF, into its own folder. Needs test cases first — Baxter mentions it once they exist, never runs it automatically.
Pre-release notes built from a sprint number and a list of issue numbers, grouped by module.
A technical diff or a plain-English features summary between two branch snapshots.
Scans the codebase and lists every AI feature — trigger type, code location, flag, status.
Traces exactly what data feeds one AI feature, plus a QA testing guide.
Maps which product modules each AI feature depends on.
A second-opinion sweep on a CR, saved or still in the conversation — ripple effects, recurring patterns, alternative approaches, UX ideas.
A clickable HTML prototype of a CR — every in-scope behaviour and acceptance criterion, grounded in the real product.
Any language, any framework, any folder layout — Baxter reads your codebase to work out where things live rather than assuming a structure. Your issue tracker and GitHub are switched on in preferences.json and off on a fresh clone; without them a skill notes what it skipped and produces the artefact anyway.
Why teams choose Baxter
Beyond the templates themselves, four things make it genuinely different to work with.
Paste. Baxter does the rest.
Drop in any raw client request — email, Slack message, voice note, Google Doc excerpt. Baxter classifies it, confirms the template, and produces a polished artefact. No forms, no commands, no structure imposed on the client.
Codebase verification built in
Before writing a single line, Baxter automatically reads your codebase — every time, without being asked. Every artefact is put through a critical seven-dimensional review, surfaced as a structured report before you ever see the draft.
Configurable by default
Drop a preferences.json file in the project root to control how Baxter behaves — push to remote after every commit, skip the confirmation step, turn off sanity checks for quick drafts, or switch language. No code required.
Open source — no vendor lock-in
Everything lives in Markdown files in your own git repo. No proprietary format, no hosted service holding your requirements hostage. Fork it, edit the templates, self-host forever.
Multi-dimensional sanity checking — before your human review.
Before writing a single line, Baxter automatically reads your codebase — every time, without being asked. Every artefact goes through a structured verification report you review before you ever see the draft.
Names
Module, field, and role names checked against your codebase — anything invented is corrected or flagged.
Technical feasibility
Can this actually be built given the current codebase, data model, and architecture?
Logic consistency
Do the requirements contradict each other — or existing functionality in the codebase?
Data model
Are new fields, tables, or relationships consistent with the existing schema?
+ roles & permissions, gaps & edge cases, and UX challenges — see all seven dimensions →
✅ Module "Orders" verified in coderepo ✅ Role "Admin" verified ⚠️ Field "completion_date" not found — closest match is "completed_at" (corrected) ⚠️ FR-03 requires a new join table — no migration referenced in the TIP ❌ FR-05 contradicts existing logic — an order cannot be both "submitted" and "draft" ℹ️ No edge case defined for mid-form navigation — recommend adding to open items
Findings are reported after the artefact — never inside it. Nothing is saved until you approve.
Review requirements the same way you review code.
Every artefact Baxter drafts is a Markdown file in your own git repo — not a page in a tool an AI can't read. A BRD becomes a pull request. Comments are review feedback. Approval is a merge. Because it's just git, you get a full audit trail for free: who changed a requirement, when, and why.
"Baxter generates. You verify. Git records everything. No tool owns your data."
This changes what a business analyst is expected to do. You don't need to read code — you need to work with an agent that does, one that flags a wrong module name before a developer ever sees the draft.
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.