Meet Baxter.
Agentic Business Analysis Demystified.
Baxter is an agentic framework and harness for SDLC knowledge management — running directly inside Claude Code, Cursor, or GitHub Copilot. Paste any raw client request — email, Slack message, voice note — and Baxter classifies it, drafts the artefact, and runs multi-dimensional sanity checking against your codebase before you review a single word. No forms. No commands. No artefact that contradicts 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 is an agentic framework and harness for SDLC knowledge management. Paste any raw client request and it classifies, drafts, and sanity-checks the artefact against your actual code before saving it to git — your single source of truth, version-controlled, and always in sync with what was actually built.
Just say what you need. Baxter figures out the rest.
No commands. No slash prefixes. No template names to memorise. Paste anything — Baxter classifies it and confirms before writing.
BRD — written before development
Defines what to build and why. Written from a raw client request before any code exists. Baxter does not check the codebase for BRDs — there is nothing to check yet.
PD — written after development
Documents what was built and how it works. Baxter reads the codebase to verify every module, role, and rule described in the document is accurate.
| Artefact | Say something like… | Saved to |
|---|---|---|
| 🐛 Bug Report BR | "The login page returns a 500 after the user submits without a password" | artefacts/issues/bugs/ |
| 🔄 Change Request CR | "Add a bulk delete option to the todos list view" | artefacts/issues/changes/ |
| 🤖 AI Feature AI | "We need AI to auto-suggest tags based on the todo title" | artefacts/issues/ai-features/ |
| 📋 Business Requirements BRD | "Write up the BRD for recurring todos" | artefacts/other/requirements/ |
| 📖 Product Documentation PD | "Document the todos module — how it works and who can access it" | artefacts/other/product-docs/ |
| 🏗️ Implementation Plan TIP | "Write an implementation plan for the bulk import feature" | artefacts/other/implementation/ |
| 🧪 Test Cases TC | "I need test cases for the authentication module — mandatory fields and role access" | artefacts/other/test-suites/ |
| 📐 Diagram DIA | "Diagram the todo creation flow from draft to completed" | artefacts/other/diagrams/ |
Baxter always confirms the artefact type before writing. Reply with the code, a number, or proceed.
Requirements are the most important artefact in software. They are also the most neglected.
Scattered across tools
BRDs in Confluence. User stories in Jira. Design decisions in Notion. Meeting notes in Google Docs. Test cases in a spreadsheet nobody can find. There is no single source of truth.
Decisions disappear
The reasoning behind a requirement lives in a standup call or a Slack thread from six months ago. Six months later, nobody remembers why it was built that way. The decision gets made again — usually wrong.
AI can't reach your docs
AI agents are powerful — but only when they can read your artefacts. Confluence pages, Jira tickets, and Word documents are locked in formats that AI can't reliably consume or produce. The tooling blocks the opportunity.
Markdown + git + Baxter is the stack your SDLC has been waiting for.
Not because it is clever. Because it works the way software development actually works.
Markdown is the universal format
Every AI reads it. Every developer writes it. Every tool renders it. No export, no import, no conversion. A BRD in Markdown is readable in a terminal, a browser, a code editor, and an AI prompt — simultaneously.
Git is the perfect audit trail
Every requirement change is a commit. Every decision has a diff. Every author is recorded. You can see exactly what changed, when, and why — going back to day one. No compliance tool in the world gives you that for free.
Baxter does the drafting
A raw client request becomes a structured BRD in seconds. A BRD becomes test cases. Baxter reads your codebase to verify every artefact is grounded in reality. Humans approve — the revision history records it.
"Baxter generates. You verify. Git records everything. No tool owns your data."
The BA is no longer just a translator. They are an orchestrator.
For decades, business analysts sat between the business and the technical team. Requirements went in one end. Code came out the other. The gap in between was where projects failed.
That model is over. Every non-technical team member — BAs, product managers, QA leads, clinical leads — now orchestrates Baxter to produce artefacts that are verified against real code. Not just documented. Verified.
You do not need to read code. You need to work with Baxter — who does — and who verifies every artefact against your real codebase: feasibility, logic consistency, data model, roles, permissions, and naming. If it cannot be built as written, Baxter flags it before anyone sees the draft.
Before
The BA writes requirements in Confluence.
The developer discovers three of the module names do not exist. The field "completion_date" is actually "date_completed". The scope creep happens silently. Nobody finds out until QA.
After
The BA pastes a request. Baxter drafts the BRD and checks it against coderepo/.
Every artefact is verified against the real codebase — feasibility, logic, data model, roles, naming. Anything invented or contradictory is flagged before the BA even reads the draft. The developer receives a requirement they can build from immediately.
The new expectation
Non-technical team members who use Baxter to produce code-verified artefacts are now more effective than technical team members who do not. Tooling is no longer the barrier. Using it is.
Every SDLC artefact. One conversation with Baxter.
From raw client request to verified, saved artefact — no forms, no structure, no commands.
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
Every artefact is put through multi-dimensional sanity checking before you see it — feasibility, logic consistency, data model, roles, permissions, edge cases, and UX challenges. Not name-checking. A critical review across seven dimensions, surfaced as a structured report.
Business Requirements (BRD)
Full BRDs with user stories, functional requirements, acceptance criteria, field specs, NFRs, and open items — structured so developers and QA can build and test from them directly.
Technical Implementation Plan (TIP)
TIPs break requirements into implementation tasks by layer — backend, API, frontend, infrastructure — with API contracts, data model changes, risks, and effort sizing.
Test Cases (TC)
Numbered test cases with explicit preconditions, step/input/expected-result tables, and postconditions. One file per test case. Ready for QA to execute immediately.
Product Requirements Document (PRD)
Assemble a complete PRD across all features — composes BRDs, links TIPs and test suites, adds stakeholder personas, NFRs, release plan, and a glossary appendix.
Product Documentation (PD)
Document any module as it exists today — roles, permissions, business rules, known limitations, and key concepts — verified against the real codebase.
Bug Reports (BR)
Structured bug reports with reproduction steps, role context, environment checklists, and media links. Baxter verifies the behaviour is a genuine bug — not expected functionality.
Change Requests (CR)
Change requests with user story, in-scope checklist, acceptance criteria, and technical notes. Verified against the codebase for feasibility and conflicts with existing functionality.
AI Feature Specs
Dedicated AI feature template covering prompt design, model selection, input data scope, execution settings, grounding data, and AI-specific acceptance criteria.
Diagrams (DIA)
Mermaid-based flow diagrams, sequence diagrams, ER diagrams, and state machines — generated from a linked CR or BRD and verified against the real system flows.
Multi-dimensional sanity checking — before your human review.
Every artefact Baxter crafts (except initial BRDs) is put through a full verification against your codebase before you ever see it. Not name-checking. A critical, seven-dimensional review — feasibility, logic, data model, roles, permissions, edge cases, and UX — surfaced as a structured report, ready for your sign-off.
Names
Module names, field names, role names, and route paths are checked against your codebase and context/modules.md. Anything invented is corrected or flagged.
Technical feasibility
Can what is described actually be built given the current codebase, data model, and architecture? Anything requiring significant undocumented rework is flagged.
Logic consistency
Do the requirements contradict each other — or contradict existing functionality in the codebase? Conflicts are surfaced before the developer reads a word.
Data model
If new fields, tables, or relationships are implied, are they consistent with the existing schema? Missing migrations and conflicts are flagged explicitly.
Roles & permissions
Role-based rules are checked against how roles and permissions are actually implemented — not how they are assumed to work.
Gaps & edge cases
Missing scenarios that would cause problems in development or testing are identified and flagged for the BA to address before handover.
UX challenges
Potential design and front-end challenges are surfaced for the design team — before the artefact reaches a developer sprint.
✅ Module "Todos" 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 — a plan cannot be both "submitted" and "draft" ℹ️ No edge case defined for mid-form navigation — recommend adding to open items ℹ️ Multi-step form flow may need loading state design — flag for UX review
Findings are reported after the artefact — never inside it. Nothing is saved until you approve.
Review requirements the same way you review code.
A BRD is a pull request. Comments are review feedback. Approvals are merges. The same workflow your team already uses for code — applied to the documents that drive it.
Raise a PR for a new feature BRD — developers and QA review before a line of code is written
Diff a requirement change — see exactly what acceptance criteria changed and when
Branch per epic — keep requirements for parallel workstreams isolated and mergeable
Git blame on a test case — know who wrote it, when, and what request triggered it
a3f9c12 Approved BRD: recurring todos — Sarah (Product) b12e441 QA review: added 3 edge case test steps — James c88d209 TIP updated: data migration risk flagged — Dev Lead d4a7f01 BRD draft: recurring todos — Baxter (AI) e99b330 Intake: recurring todos request logged f110da2 Bug fixed: todo submit on mobile — closed ...
Drop it into any project
The entire harness is a folder. No databases, no accounts, no integrations to configure.
├── CLAUDE.md # Baxter's brain — routing + rules ├── templates/ # Nine artefact templates — edit freely │ ├── issues/ # BR, CR, AI │ └── other/ # BRD, PD, TIP, TC, DIA ├── artefacts/ # All generated output — committed to git │ ├── issues/ # bugs/, changes/, ai-features/ │ └── other/ # requirements/, product-docs/, implementation/, … └── coderepo/ # Your codebase (Baxter reads this)
Spread the word
Know a team that's writing requirements from memory?
Share Baxter with them.
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.