Pathmode operates upstream of spec-kit and BMAD — it authors product intent from real customer evidence, the why behind the work. spec-kit (GitHub's spec-driven toolkit) and BMAD (an agentic agile method) take a decision you've already made and structure how the agent builds it well in the repo. They make the agent build right; Pathmode decides what's right to build. They're complementary, operating at different layers.
A team ran a clean spec-driven workflow. The spec was precise, the agent followed it, the build matched the contract line for line. It shipped on time and passed review. The problem surfaced a month later: the feature solved a problem the team had assumed, not one customers had. The workflow had perfectly executed a decision nobody had pressure-tested against evidence.
The contrast is layer, not quality
spec-kit and BMAD are good at what they do. spec-kit gives you a spec-driven flow that turns a decision into a structured plan an agent can execute. BMAD gives an agentic team a repeatable agile method so the work doesn't sprawl. Both make the agent build well — predictably, with structure, with less drift.
But both begin after the product decision is made. The spec is the point where intent fossilizes into the repo: the technical "how." By then the customer evidence that should have shaped the decision is usually gone — it lived in a ticket, a call, someone's head. The agent inherits a contract, not a reason.
Pathmode operates one layer upstream. It authors intent from that evidence — the friction, the quotes, the metric that motivated the work — so the decision handed downstream is the right one before any spec exists.
They make the agent build well. Pathmode makes it build the right thing.
What sits at each layer
| Pathmode | spec-kit | BMAD-METHOD | |
|---|---|---|---|
| What it captures | Product intent: the why, the outcome to preserve, what must not regress | A technical spec: what the code must do | A structured agile process for agent-driven work |
| Where it lives | Upstream of the repo, anchored to evidence | In the repo, as spec artifacts | In the workflow the agents follow |
| Source of truth | Customer evidence | The authored spec | The method and its plan |
| What it optimizes | The right product decision | Faithful, structured implementation | Repeatable, low-drift execution |
| Who authors it | The builder, from real evidence | Whoever writes the spec | The team running the method |
Use them together, not instead
The honest framing is additive. If your risk is execution — agents going off-plan, regressions, unstructured work — spec-kit and BMAD are the right tools and Pathmode doesn't replace them. If your risk is direction — shipping a clean implementation of the wrong call — that's upstream of any spec, and no build-time method closes it.
Pathmode authors the intent from evidence and hands a clear decision down; spec-kit or BMAD takes it from there and makes the agent build it well. The layers stack: the why feeds the how.
Frequently asked questions
- Do I have to choose between Pathmode and spec-kit or BMAD?
- No — they sit at different layers and stack. Pathmode authors the product intent from evidence, then hands a clear IntentSpec to your spec-kit or BMAD workflow, which structures how the agent implements it. Pathmode decides what to build; they govern how it gets built.
- Isn't a spec-driven workflow already capturing the why?
- It captures the technical contract — what the code must do, how the work is structured. That is genuinely useful and the right tool for build-time rigor. But the spec is downstream of a product decision someone already made; the customer evidence behind it usually isn't in the repo. Pathmode is where that decision is authored.
- When is spec-kit or BMAD enough on its own?
- When the what is already settled and your risk is execution quality — drift, regressions, unstructured agent work. spec-kit and BMAD are strong there. The gap they don't fill is whether the settled decision was the right one, which is the failure Pathmode addresses.
- Where does Pathmode's intent come from?
- From evidence you already have — support tickets, interviews, observed friction, metrics. Pathmode assembles it into an IntentSpec the agent reads at build time, so the customer why travels into the implementation instead of living in someone's head.