Meet Baxter
Agentic Business Analysis Demystified.
Baxter is your AI business analyst — 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. Requirements, test cases, bug reports, plans: verified, version-controlled, and never at odds with your own code. No forms. Nothing to learn. Access advanced features using commands.
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 tools are slash-command automations for the work around them.
BRD — written before development
Defines what to build and why, from a raw client request, before any code exists.
PD — written after development
Documents what was built and how it works, verified against the real codebase.
| 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 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.
Six 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 drafts a module table Baxter uses to verify every other artefact.
Realistic JSON sample records derived from your real data model — ready to seed or test with.
Synthesises a full test plan from an existing test suite folder, with a matching PDF.
Pre-release notes built from a sprint number and a list of GitHub issues.
A technical diff or a plain-English features summary between two branch snapshots.
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.