Unless you give it a reason to.
Bob is a structured plugin for Claude Code that loads the right principles at the right moment, enables honest review across sessions, and makes context persist in git — so AI actually helps you build well, not just build fast.
These aren't edge cases. They're the default — and they compound. The longer you work with AI without structure, the worse they get.
It knows BDD, DDD, clean architecture — it was trained on all of it. But when you just ask it to solve a problem, it falls back to the patterns most common in its training data. Competent code. Not principled code.
It agrees with you. Applauds your thinking. The longer the conversation, the less likely it pushes back on a bad idea. You opened a session expecting a thinking partner. You got an enthusiastic assistant.
For an AI, it's day one in your project every session. Decisions lost. Conventions forgotten. If you re-introduce your codebase manually every time, you've already lost the productivity benefit. Projects degrade quietly over time.
For an AI, it's day one in your project.
Every single session.
You know that feeling. The AI does too — except it never gets past it.
You know how it is to land in a new project. You're not productive from day one. Reading the code isn't enough. The documentation is either too verbose about things that don't matter to you — or out of date on the things that do. So you guess. You ask questions that feel obvious. You slowly piece together why things were built the way they were, where to find things, which architectural decisions are already settled.
For an AI, that's every session. New conversation, new employee. If you have to manually re-introduce your project every time you open Claude — explaining context, repeating decisions, re-establishing conventions — you've already lost most of the productivity benefit.
It has always been a good idea to keep documentation in git alongside your code. Now it's essential. Not because AI needs it to function, but because you need it to stay productive.
Bob isn't ambient magic. It's explicit commands you invoke deliberately — each one engineered to solve a specific failure mode.
Commands load thinking frameworks on demand — BDD when planning tests, DDD when decomposing a problem. The AI applies what it already knows instead of what's most common in training data. Principled, not just competent.
A plan written in one session is reviewed in another — by a fresh context with no memory of the conversation that produced it. No emotional investment. No polite agreement. Genuine critique by design.
Everything persists in git — vision, plans, decisions, guidelines. Close the laptop. Come back in a month. Hand off to a colleague. The project remembers. The AI doesn't need to.
Most developers build
the wrong thing very well.
Jumping straight to code before you've validated the problem, defined who you're building for, or worked out the design direction is how you end up with great software that solves the wrong problem.
Bob covers the upstream work too — thinking through the problem space, sharpening the product vision, understanding who the users actually are, translating that into design direction. The same thinking frameworks a product team would use, available to a solo developer in an afternoon.
But the real payoff is the connection. When your vision, personas, and design brief live as docs in your git repo, they don't disappear when you open your IDE. They become the context that feeds every development session. Bob reviewing your code already knows what the product is for and who it's for. That changes the quality of every decision downstream.
Validate the problem. Define the product. Understand the users. Establish the design frame.
Every decision made against the same context. No disconnect between what you're building and why.
/bob:product-coach will guide you
through the whole process — problem space, vision, personas, business model, design brief.
One step at a time, in plain conversation. Just don't expect it to tell you your idea is great
if it isn't.
From first idea to shipped, tested, documented code — Bob shows up as whatever expert you need right now. Same character. Different expertise.
Each phase has its own command. Each command ends with a file. The next command reads that file. Context never disappears. You made every significant decision.
DDD principles loaded. Hard questions asked. You push back. It pushes back harder. A direction committed to a file.
Self-contained. Anyone could pick it up and execute it. Tests planned before code is written.
Fresh context re-reads the codebase. No memory of the session that made the plan. Honest critique only.
Step by step. Tests after every change. Stops when something needs a human call.
Code checked against guidelines. System health assessed. A handoff doc so anyone can own what was built.
Most AI tooling optimises for the feeling of productivity. Responses that make you feel heard. Outputs that look thorough. Agreement that feels collaborative.
Bob is built on a different bet: that the developers who care about quality — who've felt the frustration of AI drift, context loss, and sycophancy — want a partner that actually pushes back. Not one that always makes them feel right.
Bob makes AI more reliable. Not reliable.
It's still an LLM underneath. That means it can miss things, misread your codebase, or produce something confidently wrong. It doesn't reason from first principles — it recognizes patterns. Sometimes that looks like insight. Sometimes it's fluent nonsense.
Your judgment isn't optional. Bob is a structure that supports it, not a substitute for it.
Works with any project. Any language. Any stack. Requires Claude Code — run both commands inside it.
Then open Claude Code and say:
Hi Bob, where do I start?
Bob knows the entire toolkit. Ask it anything about your project or the workflow — it'll tell you exactly what to do and why. Use /bob:pm when you want a structured project status report.