Pathmode, GitHub Spec Kit, and BMAD overlap, but their centers of gravity differ. Spec Kit is an extensible, spec-driven process harness; BMAD provides agents and structured workflows across planning and development. Pathmode focuses on the product decision that should govern those workflows: an open IntentSpec in intent.md, a deterministic six-gate preflight, and optional team context for private evidence, human review, and findings.
It is tempting to draw a neat stack in which one tool owns “why” and another owns “how.” The current tools are broader than that. GitHub describes Spec Kit as an extensible, intent-driven process harness with a default Spec → Plan → Tasks → Implement flow. BMAD offers specialized agents and structured workflows spanning ideation, planning, architecture, development, and review.
The honest comparison is not which tool is allowed to think about product intent. It is what artifact each workflow treats as load-bearing and what happens before implementation starts.
Pathmode's narrower job
Pathmode focuses on a portable product-decision artifact:
intent.mdis the repo-bound authority. It travels with the branch and can be read by any coding agent.- IntentSpec is an open format. The objective, outcomes, constraints, scope, edge cases, decisions, and verification are not trapped in one workflow.
- Preflight is deterministic. Six calibrated gates produce the same verdict for the same spec without a model call or account.
- Authorship and authorization are separate. An agent can draft; a human confirms or waives product judgments explicitly.
- The team layer stays behind the file. Private evidence, named guest feedback, signed-in authorization, implementation findings, and cross-repo state can remain outside git while the repo keeps the decision.
Pathmode does not decide what is right to build. It makes the team's decision explicit, reviewable, and ready for an agent.
What each tool emphasizes
| Pathmode | GitHub Spec Kit | BMAD | |
|---|---|---|---|
| Center of gravity | Product-decision artifact and readiness | Extensible spec-driven process harness | Agent roles and structured planning/development workflows |
| Primary repo artifact | Open IntentSpec in intent.md | Linked spec, plan, task, and implementation artifacts | Workflow-specific planning, story, architecture, and delivery artifacts |
| Readiness model | Six deterministic product-intent gates | Templates, checklists, and cross-artifact analysis | Guided workflows, roles, and quality checks |
| Evidence and review | References in repo; private evidence, named guest feedback, and signed-in authorization in connected mode | Can be captured or added through the chosen workflow | Can be developed through research, planning, and facilitation workflows |
| Best reason to add it | You need a portable decision boundary before implementation | You want a broad, customizable spec-driven process | You want a comprehensive agentic planning and delivery method |
Use them together only when the boundary is clear
A practical combination is:
human-authorized intent.md → Spec Kit or BMAD planning artifacts → implementation → verification
The IntentSpec should define the product decision without duplicating every downstream plan. Spec Kit or BMAD can then decompose that decision using their own process. If the downstream workflow exposes a contradiction, feed the finding back into intent.md and have the human re-authorize the changed judgment.
If one workflow already does every job you need, keep it simple. Pathmode is useful when the missing piece is a portable, preflighted product decision—not when it would merely create a second spec to maintain.
Frequently asked questions
- Do I have to choose between Pathmode and Spec Kit or BMAD?
- No. You can use intent.md as the product-decision input to a broader Spec Kit or BMAD workflow. Keep one content authority in the repository, then let the other tools create the planning, architecture, task, and implementation artifacts their processes require.
- Don't Spec Kit and BMAD already capture intent?
- They can capture substantial product context, and it would be inaccurate to describe them as only implementation tools. Pathmode's narrower distinction is the artifact and gate: a portable IntentSpec, read from the repo first, with deterministic readiness semantics and an optional private evidence and review layer.
- When is Spec Kit or BMAD enough on its own?
- When its workflow already captures the product decision with enough rigor for your team and you do not need a separate open IntentSpec, Pathmode preflight, or private evidence trail. Adding another layer without a clear missing job would only create duplication.
- Who decides what is right to build?
- Your team does. An agent in any of these workflows can research, challenge assumptions, and draft a recommendation. Evidence can ground it. A human remains responsible for authorizing the product judgment before implementation begins.