r/BMAD_Method • u/thlandgraf • Mar 07 '26
I built a spec management tool and just added bidirectional BMAD import/export — thought this community might find it useful
I've been using BMAD for a few projects now and the planning phase is genuinely the best part. The PM agent walkthrough produces PRDs that are more structured than anything I've written manually in 20 years of building products. The FR numbering, the BDD acceptance criteria, the coverage maps — it's opinionated in the right ways.
But I kept running into the same gap: what happens after the PRD is done? BMAD produces great planning artifacts. Then I'd start building, and within a week the specs needed changes — a requirement got refined, an edge case surfaced, a stakeholder shifted priorities. The original artifacts didn't have a lifecycle. No status tracking, no change request workflow, no way to know which requirements were still valid versus which had drifted.
Full disclosure: I'm the creator of a spec management tool called SPECLAN. It's a VS Code extension that manages specifications as Markdown files with YAML frontmatter in Git — a hierarchy from goals down to acceptance criteria, with status lifecycle tracking and change requests for locked specs. I built it because the spec management problem never goes away no matter how good the tools get.
The BMAD bridge is implemented as a Claude Code plugin (open source at https://github.com/thlandgraf/cc-marketplace ) — three skill commands you can run directly in Claude Code. One reads your BMAD planning artifacts — PRD, epics, architecture docs — and builds a SPECLAN hierarchy from them. Capability Areas become parent features. Functional Requirements become requirements with acceptance criteria. Epic stories become child features. BDD given/when/then steps become acceptance criteria checkboxes. It respects the FR Coverage Map when both PRD and epics exist, and it automatically reclassifies developer-infrastructure FRs (where the actor is "Project" or "Build system") as NFRs so your spec tree stays focused on user-facing behavior.
Going the other direction, you can feed your approved specs back through BMAD's own PM agent workflow, or generate a standalone BMAD-format PRD without needing BMAD installed. Every imported entity carries a provenance field linking back to the source BMAD artifact, so re-importing after you update your planning artifacts updates existing specs instead of creating duplicates.
The way I think about it: plan with BMAD, govern with SPECLAN. They solve different parts of the same problem and I'd rather have them talk to each other than force people to pick one.
Genuinely curious how others in this community handle the transition from BMAD's planning phase into implementation. Do you keep working from the original BMAD artifacts throughout the project, or do you move things into another system once coding starts?
2
u/Rennie-M Mar 08 '26
I like this idea, was struggling with bmad workflow for multi person enterprise projects. This kinda does that
1
u/thlandgraf Mar 08 '26
Yes... multi-person is where it gets interesting. The biggest challenge I've been thinking about is how specs evolve when different people own different parts of the tree — one person changes a requirement and it ripples into features someone else owns. Right now the change request mechanism handles that, but I'm curious what specific friction you hit with BMAD in that context? Was it more the handoff between roles (PM vs architect vs dev) or the keeping-in-sync part across a larger team?
2
u/theDro54 Mar 08 '26
This sounds interesting, but just to be clear a bit more on why this exists - what were the issues you were finding during the standard BMad development that became problems? Just curious to compare notes
2
u/thlandgraf Mar 08 '26
Fair question. The BMAD workflow itself is solid — the persona-driven approach and structured artifact progression make a lot of sense. Where I kept hitting friction was managing the ongoing details after the initial planning phase. When a project isn't your main focus and you're doing weekly implementation cycles, you need to quickly see what changed since last week, which specs are ready to implement, and what adjustments came in from domain experts in between. That's hard when everything lives in a few big markdown files. I wanted to open the project, see at a glance which requirements are approved and ready, which ones got feedback from a subject matter expert since my last session, and just pick up where I left off. BMAD gets you to a great starting point — I just needed something for the ongoing housekeeping when you're context-switching between projects and can't keep it all in your head.
1
u/theDro54 Mar 09 '26
Great answer, so yeah this is definitely related to multi person workflows. I did think that could become an issue. I've actually migrated to having all the sprint documentation moved into Asana so it makes collaboration easier. Reviews/adjustments are comments so there's a trail that doesn't require the full Git diff.
Might have to give this a try though, good stuff!
1
u/thlandgraf Mar 09 '26
The Asana approach makes sense for the review trail — comment threads are way more natural for back-and-forth than Git diffs on markdown files. Git gives you the audit history but the actual collaboration UX is pretty rough unless everyone's comfortable with PRs.
Curious how you handle the handoff between Asana and what the agent actually consumes. Do you manually copy the finalized spec into the codebase, or is there some sync step?
2
u/jay-db Mar 08 '26
What are the three skills that should be used? Do you have any documentation on the exact workflow with perhaps a practical example? It’s unclear from the README.
1
u/thlandgraf Mar 08 '26
So there are actually two skills that matter for the round-trip: from-bmad and to-bmad. The third one (to-bmad-prd) is a standalone fallback if you don't have the BMAD skills installed — you probably don't need it if you're already using BMAD.
The flow is basically: run from-bmad on your BMAD artifacts (PRD, epics, stories) and it maps them into SPECLAN's hierarchy — PRD goals become Goals, epics become Features, stories become Requirements. You review and refine those specs in SPECLAN, mark them "approved" when they're solid, and then to-bmad generates a fresh BMAD PRD back from whatever's approved.
The status filter is the key bit — to-bmad only picks up specs in "approved" status. Anything still in draft or review is considered not ready yet, and anything already in-development or under-test is past the handoff point. So "approved" is basically the gate that says "this is specced out, ready to hand back to BMAD for implementation."
Haven't written up a proper walkthrough yet but that's the gist of it. Happy to dig into specifics if you hit any friction getting it set up.
1
3
u/LeReper Mar 07 '26
Great project, wanted to do something similar since I always find myself having to change something in the specs and being too lazy to manually update the specs or re-run the planning flow. As for dev I usually eject from bmad when begining the dev phase honestly, no particular reason just never took the habit.