BMAD vs Spec Kit vs Kiro vs Superpowers: What Transfers

BMAD, GitHub's Spec Kit, Amazon's Kiro, and Superpowers are four spec-driven development frameworks with nothing in common on the surface - except four invariants none of them advertise. Here's what put me onto them: BMAD's own documentation gives away the thing most frameworks would rather you not notice. It has no execution engine of its own. The Large Language Model (LLM), running inside whatever agent harness you're using, is the runtime. What BMAD actually ships is a set of markdown files whose job is to tell that model which file to open next and what to do with it. That's not my read of the framework. It's how BMAD describes its own architecture.

If that is true, what exactly are you installing?

Whatever it is, teams pay for not knowing the difference. I've watched a team install one of these frameworks wholesale, inherit a PRD requirement they never asked for, and burn two days getting a two-line config change through a review gate built for six-month projects - then abandon the framework and go back to the exact unstructured prompting that caused the problem the framework was bought to fix. They didn't lose two days to spec-driven development. They lost two days to ceremony they could have skipped, while quietly and permanently discarding four mechanics they actually needed. Knowing which four is the difference between those outcomes, and it's the reason this article exists.

I read four spec-driven development frameworks in full this month looking for the answer: BMAD, GitHub's Spec Kit, Amazon's Kiro, and Superpowers (the Claude Code skills framework from obra). OpenSpec solves the same constraint with its own ceremony and would fit this comparison too, but it's another open-source, CLI-first tool in the same shape as Spec Kit - it wouldn't add a structurally distinct data point the way Kiro's proprietary, IDE-native, phase-gated design does. Kiro earns its place precisely because it's the odd one out: built by AWS, sold as a product, run inside an IDE with human approval gates between phases, with no CLI-first or open-source lineage in common with the other three at all. What I found was not one dominant framework and three imitators. It was four tools with almost nothing in common at the surface, and a small set of structural agreements underneath that none of them advertise as the point - agreements that turn out not to be a coincidence of good taste, but a forced consequence of the thing all four are built on top of.

The thesis: four spec-driven development frameworks, built by people who don't appear to have compared notes, converge on the same four structural mechanics because all four are solving the same constraint - an LLM's context window is not memory - and they disagree, productively, about a fifth thing that constraint doesn't dictate. The four agreements are mechanical - you could implement them without adopting any of the four frameworks, because the constraint that forces them doesn't care which framework you use, or who built it, or whether it's open source. The disagreement is philosophical, and it does not resolve cleanly. Everything else - personas, installers, vocabulary, ceremony - is packaging on top of a core the underlying medium requires.

The consensus belief this challenges: that adopting a spec-driven framework is how you get disciplined AI-assisted development. Most of what these frameworks sell is ritual bolted onto a small portable core, and the core transfers without the framework, the installer, or the vocabulary - because the core was never really the framework's invention to begin with.

Here is the falsifiability condition, stated plainly: if a frontier model's context window becomes large and reliable enough that externalizing state, compiling context, and resetting between steps stop paying for themselves, this argument weakens - because the invariants would no longer be forced by the constraint that currently makes them close to unavoidable. That is a real future condition, not a hypothetical one - frontier context windows have grown from low thousands of tokens to over a million in a few years, and it is a fair question whether they eventually grow past the point where these invariants matter. I should be honest about what Kiro is and isn't evidence of here: it's one of the four frameworks this argument is built from, not an independent test run after the fact, so it can't function as proof the prediction came true. What it is, honestly, is a fourth data point from a source with no overlap in lineage, tooling, or vendor with the other three - and a framework built by a company with every incentive to solve this its own way still landing on the same four mechanics is a modest increase in confidence, not a validated prophecy. The real test is whichever framework gets built next.

BMAD vs. Spec Kit vs. Kiro vs. Superpowers: Why Spec-Driven Development Converges

BMAD and Spec Kit both descend from the Scrum branch of agile: Product Requirements Documents (PRDs), epics, tasks, sprints, a Scrum Master role compiling context into story files. Superpowers descends from a different branch - its test-driven-development skill and its mandatory design-before-code brainstorming are straight out of Extreme Programming (XP), agile's other major lineage, wired into a skills-native, Claude-Code-first structure with no PRD, no sprint, no epic, no product-manager persona. Kiro doesn't come from either camp of practitioner tooling at all: it's a proprietary product built by a cloud vendor, shipped inside an IDE, with human approval gates as the default rather than something you opt into. That's not a third methodology lineage so much as a third kind of origin entirely - not an open-source framework descended from a named process at all, but a commercial product built by a company with no stated allegiance to Scrum, XP, or anything else in the agile family.

So we have two agile branches and one framework with no agile lineage to speak of, and the honest version of the lineage argument has to start there - not from a false claim that Superpowers or Kiro are outsiders owing nothing to any tradition. But the fact that a commercial product with no agile pedigree at all lands on the same mechanics sharpens the finding instead of undoing it: nothing in Scrum and nothing in XP dictates "write your state to a file instead of a chat," "hand the executor exact file paths instead of a pointer," or "dispatch a fresh subagent with no memory of the conversation that produced its task" - and neither does whatever AWS's own product process looks like internally, because Kiro built the same mechanics anyway. Those responses exist because every one of these traditions, adapted to point at an LLM, ran into the same wall - a context window that forgets what falls out of it, cannot audit itself against what it was never handed, and drifts if you let one conversation run long enough. That constraint is the actual shared ancestor here, and it isn't Scrum, XP, or whatever AWS's product team calls its own process. Two Scrum-lineage frameworks, one XP-lineage framework, and one framework with no agile lineage at all bent toward the same four mechanics because the medium, not the methodology, is what's forcing the shape.

That is why the convergence is the finding and not the framework comparison. If BMAD and Spec Kit agreed and the other two didn't, the honest reading would be "Scrum habit, not a real constraint." Four frameworks landing on the same four mechanics, with one of them owing nothing to agile at all, is what makes the constraint-driven reading more credible than the methodology-driven one.

Here is the grid, reproduced in full because the shape of it is the argument:

Notice the grid is not all green, and once Kiro is in it, both gaps land in the same place: Superpowers is the lone holdout on invariant 5 (ceremony scaling), and it's also the only one of the four missing invariant 3 (the filesystem answering "where am I"). That's not a coincidence worth glossing over. Superpowers is the framework that goes hardest on invariants 2 and 4 - the smallest, most tightly isolated work units and the strictest context resets in the grid - and it's the same framework that skips tracking its own position and refuses to scale its ceremony down. Three frameworks independently decided position-tracking and ceremony-scaling were both worth having. One framework, built around aggressive minimalism at every other layer, decided neither was. That's a more coherent story than "two separate gaps that happen to exist" - it looks like a single design stance showing up twice.

The Wrong Way: Ceremony as the Product

Here is the failure mode I keep watching teams walk into. A team adopts one of these frameworks, inherits its full ceremony as shipped, and applies it uniformly - PRD included - to a two-line configuration change. Writing the two-line fix takes ten minutes. Writing the PRD to justify it takes an afternoon, and getting it reviewed takes two days, because now there's a document in the pull request that a reviewer feels obligated to actually read. The process resents them back: three sign-offs and a requirements document for something that took ninety seconds to describe out loud. They abandon the framework within a sprint and conclude, out loud, in a retro, that spec-driven development doesn't work for a team their size.

The diagnosis is not that the framework was wrong. It's that they adopted the packaging and never isolated the four things underneath it that were actually load-bearing. Ceremony that doesn't scale to the size of the task is not spec-driven development failing - it's spec-driven development never having been unbundled from the agile ritual it arrived wearing.

The Right Way: Four Invariants, Not One Framework

Invariant 1 - State lives on disk, never only in the conversation

An AI coding agent's context window is not memory. It is a rolling window that forgets what fell off the back of it, and every one of these frameworks solves this by refusing to let anything that matters live only in the chat. BMAD writes per-phase artifacts to an output folder. Spec Kit's spec, plan, and tasks markdown files are the source of truth the moment they're written - not a record of what was said. Kiro writes requirements.md, design.md, and tasks.md to .kiro/specs/, and treats them as permanent project artifacts rather than scratch output - the guidance is to check them into version control right there next to whatever code they end up producing. Superpowers chains a design document into a plan into a set of tasks, where each file is the next step's actual input, not a summary of a prior conversation.

What breaks without this: an agent five steps into a task loses the reasoning behind a decision made in step one, because the reasoning was never anywhere except a conversation turn that's since scrolled out of the context window. It doesn't ask you to reconstruct the decision. It quietly re-derives its own answer, and that answer doesn't have to agree with the one you already made. This is the same failure mode covered in more depth in state management for agentic systems - checkpointing exists precisely because conversation memory isn't durable memory.

Invariant 2 - Work units carry compiled context, not references

This is the invariant most people get half right on their own, because it looks like it should be enough to just point the agent at the file. It isn't. A reference ("see the auth module") costs the agent a search, a read, and an inference about what's relevant before it can act - and every one of those steps is a place for it to infer wrong. A compiled work unit hands over the exact file paths, the actual code involved, and the specific verification steps, pre-resolved, so the agent spends its context budget on the task instead of on rediscovering what it needs to do the task.

BMAD's Scrum Master agent compiles epic-level context directly into story files before handing them to the developer agent. Spec Kit's tasks carry the exact file paths they touch. Superpowers implements this hardest: tasks are deliberately sized to two to five minutes of work, each one shipped with complete code and explicit verification steps, so there is nothing left for the executing agent to go infer on its own.

Kiro is where this invariant stopped looking like a single mechanism. Its tasks.md items reference requirement IDs, not exact file paths or inlined code - which looks, at first glance, like a weaker version of what Spec Kit and Superpowers do. But Kiro compensates a different way: it keeps the entire spec - requirements, design, and tasks together - loaded into the agent's context for every task, and resolves the specifics at execution time against that live document instead of pre-compiling them into the task card itself. That's still compiled context, in the sense that nothing forces the agent to go search for what it needs. It's just compiled once, for the whole spec, rather than distilled fresh per task. Whether that's a better or worse tradeoff probably depends on how large the spec gets - a small spec loaded in full costs little; a sprawling one starts to look like the same context-bloat problem invariant 2 exists to avoid in the first place.

What breaks without this: an agent given a reference instead of compiled context will, under time or complexity pressure, guess at what the reference meant - and a guess that reads as confident prose is indistinguishable from a correct answer until someone checks the diff. This is the same tradeoff context engineering for production agents covers from the retrieval side: a pointer costs a lookup, and every lookup is a place for the agent to infer wrong.

Invariant 3 - The filesystem answers "where am I," not the conversation

This is where reading four frameworks instead of one earned its keep, though not in the direction I first expected. My first pass at this invariant was "there's one state file" - because that's what BMAD has, cleanly, and it was tempting to stop there. Then Spec Kit's workflow layer turned out to have its own explicit run-state file, state.json, tracking exactly where a run is - created, running, paused at a named review gate (review-spec after the spec step, review-plan after the plan step), failed, resumable - which is functionally the same mechanism as BMAD's status file, just named differently. Two frameworks, independently, converged on "write a file that answers the question so nobody has to scroll back through the chat to answer it."

Kiro doesn't have a dedicated file for this, and my first instinct was to score it the same "no" as Superpowers. That instinct was wrong. Kiro's tasks.md - the same file that carries the task list - uses checkbox state to mark what's done, and that file is committed to the repo, not held only in an IDE session. A fresh agent picking the work back up can read the checkboxes and know exactly where the last one left off, with no conversation and no live human required. That's the invariant, satisfied by a lighter-weight mechanism than a dedicated status file: the position lives in the same file as the content, instead of a separate one, but it still lives on disk, not in the conversation.

Superpowers is the one that actually lacks this. Its worktree holds the files a task is working with, but nothing in it tracks phase or position - there's no file anywhere, dedicated or otherwise, that says "paused at review," "step 3 of 5," or "failed, resumable." Once Kiro is scored correctly, this stops being an even split and becomes the same lopsided pattern as invariant 5: three frameworks have it, one doesn't. And it's the same one. The framework most committed to isolating each step's context (invariants 2 and 4, at their strongest) is also the only framework with no infrastructure at all for answering "where am I" from outside that step. That's not two unrelated gaps - it's one design stance, aggressive minimalism, showing up as a gap in two different places. It's also the same disk-versus-conversation distinction behind checkpoint complacency: a commit answers "where am I" whether or not anyone asks; a chat transcript only answers it for as long as someone remembers to scroll up.

Invariant 4 - Fresh context window per step

BMAD runs a fresh chat per workflow phase. Superpowers goes further and dispatches a fresh subagent per individual task, with zero access to the parent conversation, specifically so nothing from one step's detours contaminates the next. Kiro's "Run all Tasks" feature also dispatches independent tasks to their own subagents with isolated context windows, though the stated motivation is different - it's framed as a parallelism feature (run non-dependent tasks side by side, faster) more than a contamination-hygiene one, with the context isolation as a side effect rather than the point. Worth being honest that isolated subagent dispatch is close to a default pattern for parallel agentic work by now, so two more tools landing on it isn't a shock the way the state-on-disk convergence is - but it's still one more data point in the same direction, for a different reason than Superpowers has for it. Spec Kit is the one framework that doesn't enforce it: its slash commands - /specify, /plan, /tasks, /implement - run by default inside one continuous session, accumulating whatever came before.

What breaks without this: context doesn't just get consumed, it gets contaminated. An agent that watched itself make three wrong turns in the same session carries the residue of those wrong turns into the next step, even after you've corrected course out loud. A fresh window has no memory of the detour - it only has the compiled work unit, which is exactly what invariant 2 exists to make sufficient. It's the same mechanism behind running work through parallel subagents inside a session: every subagent burns its own isolated context so the parent conversation doesn't have to carry the residue.

The Live Argument: Should Ceremony Scale With the Stakes?

BMAD and Spec Kit both scale ceremony to the size of the task - a quick track for small work, a full gate chain for anything production-bound. Kiro goes further than either: it offers a Quick Plan mode that collapses all three phases - requirements, design, tasks - into one pass and drops the approval checkpoints between them, reserved for work whose shape is already well understood. Its own guidance goes further still, telling you not to open a spec at all for the smallest changes - the kind of one-line fix or obvious typo where writing a requirements document would take longer than the bug itself did - and to just make the edit directly instead. Three frameworks, independently, concluded that mandatory ceremony on trivial work is exactly how frameworks get abandoned in a single sprint, which is the wrong-way failure mode above.

Superpowers is the one holdout, and not by oversight. Its brainstorming skill mandates the same process - Socratic questioning through design before any code gets written - for every project regardless of size, with a stated rationale: "simple" projects are precisely where unexamined assumptions do the most damage, because nobody thought they needed to be examined. Being outvoted three to one doesn't make Superpowers wrong here - but it does mean the burden of proof sits more squarely on its side of the argument than a two-against-one split would have suggested.

I'm not going to resolve this cleanly, because I don't think it resolves cleanly, and I want to be honest about where my own reframe below is a measured claim versus a hunch.

Here's the hunch: the disagreement might be less about whether ceremony has value and more about what a specific framework's ceremony costs to run. Superpowers' brainstorming skill mandates a round of Socratic design questions before any code - if that round genuinely costs a few minutes of back-and-forth, mandating it for every project is cheap insurance. A PRD is a different order of cost - hours of writing, a review cycle, a document sitting in a pull request a reviewer feels obligated to actually read, which is the same cost that made teams abandon the framework in the wrong-way scenario above. Kiro's own guidance draws the line at exactly this cost distinction: skip the ceremony when the fix is well-understood and cheap to verify, keep it when the work carries real design risk. If that cost gap is real, all four frameworks are optimizing the same tradeoff - process cost against the risk of unexamined work - from different cost bases, and none of them is wrong about its own math.

But notice what I haven't done: I haven't measured the brainstorming round's actual cost against a PRD's on the same axis, and until someone does, this is a plausible account, not a settled one. There's also a harder problem with letting Superpowers off easily here: a mandatory round of design questions before a two-line config change is still a gate on trivial work, which is exactly the failure mode the wrong-way section condemns. "No document gets produced" is not the same claim as "no time gets spent" - and if the questioning round genuinely takes real back-and-forth on something that took ninety seconds to describe, Superpowers hasn't escaped the wrong-way failure mode, it's just paying a smaller toll for the same mistake. The honest version of this argument is a hypothesis worth testing against your own team's timing, not a verdict that Superpowers has already won.

Why the Four Invariants Aren't Independent

The four invariants above are not a checklist you can satisfy independently. They interlock around a keystone - one invariant that justifies itself on its own, and three more that only work because it's already in place:

• State on disk (1) is the keystone. It pays for itself independent of anything else on this list: crash recovery, an audit trail, a human reviewing what happened last week, a context window that overflows mid-session without anyone choosing a reset. None of that requires the other three invariants to exist.
• Compiled context (2) depends on the keystone. There has to be something durable to compile from. Without state already externalized, there's nothing stable enough to extract exact file paths and verification steps out of - you'd be compiling from a conversation, which is the thing invariant 1 exists to get away from.
• The filesystem answering "where am I" (3) also depends on the keystone, and is really a special case of it - a state file whose specific job is tracking position instead of content.
• Fresh context per step (4) depends on both 2 and 3. A reset is only survivable if the executor has compiled context to act on (2) and something to reorient against on wake (3). Pull either one out and a fresh window resets into a void - it has nothing to pick up.

Pull the keystone (1) out, and 2, 3, and 4 all sag at once, because none of them has anything durable left to draw from. Pull 3 out on its own - as Superpowers does - and only 4 loses its ability to answer "which step is this," not its ability to act; that is a real degradation, but a narrower one than losing the keystone, which is why Superpowers still functions with invariant 3 missing while a framework missing invariant 1 would not function at all.

I'm calling this the Invariant Interlock - not a closed loop, but a keystone-and-dependents structure, where one invariant is load-bearing for the rest and pulling it collapses more than itself. It clears prior-art verification against the closest adjacent terms (an unrelated AI-infrastructure circuit-breaker project also named "Interlock," and an "Invariant AI" guardrails company) - distinct concepts, not the same claim under a different name.

The contested fifth invariant - ceremony scaling - sits outside this structure entirely. It's a design choice made about the interlock, not a piece of it. That's a cleaner way to state why it doesn't resolve the way the other four do: you can disagree about how much ceremony to wrap around the interlock without touching the keystone or its dependents.

What BMAD, Spec Kit, Kiro, and Superpowers Add Beyond the Core Invariants

Here's the honest inventory of what you're actually buying when you install one of these: personas (Analyst, Product Manager, Scrum Master, Architect, Developer), an installer, a help agent, a project-specific vocabulary, platform compatibility matrices, in BMAD's case a directory of community-contributed modules, and in Kiro's case an IDE-native approval-gate UI and integration with the rest of AWS's tooling. None of that is fraudulent. For a team, ceremony is coordination - a shared vocabulary for what a "story" is, a persona structure that maps to who reviews what, a PRD that gives a non-technical stakeholder something to sign off on. That coordination value is real, and I'd be overstating the case to pretend otherwise.

The concession is that for a single practitioner working with a capable coding agent, that coordination buys much less, because there's no second person to coordinate with. What's left, once you strip away the persona layer and the vocabulary, is the four invariants - and those transfer to a solo workflow without needing a PRD, a Scrum Master persona, or an installer at all. Superpowers gets there through Agent Skills as a production knowledge layer rather than a spec-driven process at all - which is itself evidence for the thesis: the invariants showed up without anyone setting out to build a spec-driven framework.

One more finding belongs here, distinct from the four-invariant grid because it hasn't converged yet: Superpowers has an idea none of the other three implement. Process must be enforced, not instructed. An instruction sitting in a project's context file is a suggestion an agent follows when convenient and drops under pressure - a long context window, a hard problem, a test quietly skipped under deadline urgency. Superpowers' test-driven-development skill instead mandates the discipline structurally: it treats "I'll write the test after" as grounds to delete the implementation and start over, rather than accept it with a promise to backfill. That's a speed bump, not a speed limit sign - one physically prevents the violation, the other just posts a rule next to the road.

I made a version of this same argument in a previous piece on spec-code coupling: that a spec survives only if something automated will fail when the code drifts from it, and that most teams under-invest in that enforcement because writing a document feels like progress in a way wiring a contract test never does. The mechanism here is a sibling, not a repeat. That piece was about coupling a specification to a build-time check - a contract test that fails CI when the code no longer matches the spec. This is about coupling a process instruction to an agent-level rule that fails at write-time, before the code is even committed - deleting an implementation for skipping its test, not waiting for a pipeline to catch the drift after the fact. Enforcement-over-instruction turns out to be one mechanism showing up at two different layers: the code-to-spec layer and the agent-to-process layer. One framework out of four has found the second layer. That's too thin a sample to call it a fifth invariant - but it's the strongest candidate for what converges next, and worth watching for in whatever framework comes after these four.

What Sags When One Piece Is Missing

flowchart TD
    A["1. State on Disk<br/>THE KEYSTONE"]
    B["2. Compiled Context<br/>in every work unit"]
    C["3. Filesystem Answers<br/>'where am I'"]
    D["4. Fresh Context<br/>per step"]
    E["5. Ceremony Scales<br/>with stakes<br/>(contested - outside the structure)"]

    A -->|"gives compiled context<br/>something durable to pull from"| B
    A -->|"is what a position file<br/>is actually tracking"| C
    B -->|"gives the fresh window<br/>enough to act on alone"| D
    C -->|"gives the fresh window<br/>somewhere to reorient on wake"| D

    E -.->|"a design choice made<br/>about the structure"| A

    style A fill:#4A90E2,color:#FFFFFF
    style B fill:#7B68EE,color:#FFFFFF
    style C fill:#6BCF7F,color:#2C2C2A
    style D fill:#4A90E2,color:#FFFFFF
    style E fill:#95A5A6,color:#2C2C2A,stroke-dasharray: 5 5

This is the Invariant Interlock drawn out as a graph rather than a list. State on disk is the keystone: it justifies itself through crash recovery and audit alone, with no help from the other three. Compiled context and the filesystem's position-answer both draw on that same externalized state - one extracts content from it, the other extracts position from it. Fresh context per step is the invariant furthest from the keystone, and the most exposed one: it needs both of the middle two in place to be survivable, which is exactly why Superpowers, missing invariant 3, still functions - invariant 4 loses its position-tracking, not its ability to act - while a framework missing invariant 1 outright would lose everything downstream of it. The contested fifth sits outside, dotted, because it's a decision about how much ceremony to wrap around the structure - not a piece the structure depends on.

Decision Guide: What Transfers to Your Own Workflow

Given a task, here's what to keep regardless of which framework - or no framework - you're using. It's the same choose-the-right-mechanism problem that shows up one layer up when picking which Claude Code layer actually solves your problem - the answer isn't "adopt the whole stack," it's "know which piece you actually need." The Invariant Interlock tells you the order these actually have to happen in, not just the list: the keystone first, then whatever depends on it. If you install nothing else from this article, do these four things in your next agent-driven task, in that order: write the task's exact file paths, code, and verification steps into a file before you hand it to the agent, not a pointer to where those things live. Write the current step's status to that same file the moment you start it, not after. If the agent will run more than one step without you checking in, start each step in a fresh session instead of continuing the same one. And if the task is trivial, skip everything else - the ceremony question below is the only invariant that's actually optional.

• Never optional: state on disk (1) and compiled context in the work unit (2). These are the two invariants with no viable alternative in the grid - every framework that skipped either one would fail silently, not loudly, which is the worst way for a discipline to fail.
• Non-negotiable once tasks run unattended: fresh context per step (4). If an agent executes multiple steps without you checking in between, contaminated context is not a risk, it's a certainty over enough steps.
• Worth having, and easy to skip without noticing: something that tracks phase or position on disk - a dedicated status file, or checkbox state inside whatever task file you're already committing, as long as it's the kind of thing a fresh agent picking the work back up could read cold. A worktree or a Git branch alone doesn't answer "which step am I on, and did it pass"; you need something more specific than "the files exist." BMAD's status file, Spec Kit's state.json, and Kiro's checked-off tasks.md all do this a different way, but they all do it. It's the one invariant here that's genuinely optional to skip without anything visibly breaking in the moment, which is exactly why it's the one most likely to get skipped.
• Your call, and it's genuinely a call: how much ceremony wraps around the four invariants (5). If you're solo with a capable agent, favor Superpowers' cost basis - keep the ceremony cheap enough that mandating it isn't a burden, and mandate it. If you're coordinating a team, favor BMAD, Spec Kit, and Kiro's cost basis - scale the ceremony to the stakes, because your ceremony is more expensive than a round of clarifying questions.

The Unsolved Problem: What Compiled Context Leaves Out

Three of the four frameworks describe "compile the relevant context into the work unit" as though it were a step you complete and move on from - Kiro's version is "keep the relevant context loaded," which turns out to be the same problem wearing different clothes. It isn't a step. It's the whole unsolved problem wearing a to-do list item's clothes.

This is not a new problem in the abstract - it's a relocated one. Retrieval-Augmented Generation (RAG) systems have lived with retrieval-completeness failure for years: a retriever can't tell you what it failed to retrieve, because the evidence of the gap is, by definition, not in what it returned. What's actually new here is narrower, and it's this: the agent executing a compiled work unit has no way to see what was left out of its own slice, and unlike a RAG system reaching out to a corpus it could in principle re-query, a subagent dispatched with a fixed work unit often has no path back to the rest of the context at all. Ask it whether what it was handed is complete, and it can only answer from inside the slice it already has - it cannot check that slice against everything that didn't make the cut, because the thing that would let it check is exactly the context it doesn't have.

Superpowers' fresh-subagent-per-task pattern doesn't dodge this - it makes the blindness a deliberate design choice rather than an accident of context-window limits. The subagent sees only its slice, on purpose, precisely so it can't get confused by the rest of the conversation. Which means the framework that goes furthest on invariants 2 and 4 is also the framework that has, by construction, the least visibility into what it might be missing - not because it failed to solve the problem, but because solving invariants 2 and 4 well is what creates the problem in this specific, structural form.

Kiro's whole-spec-in-context approach gives it a narrow exemption from this, and it's worth being precise about how narrow. An agent working a Kiro task can at least see the entire design document, not just its own slice of it - so it has more to check its work against than a subagent handed a pre-compiled fragment does. But that only pushes the blindness out one layer, it doesn't remove it: the agent can now audit itself against the spec, but it still has no way to audit the spec against everything that isn't in the spec - the requirements nobody wrote down, the edge case nobody considered when requirements.md was drafted. Seeing more of your own slice isn't the same as seeing what's outside it.

Naming a relocated version of a known problem isn't solving it. None of the four frameworks I read has a mechanism for it, and I don't have one either. It's where the interesting follow-up work lives - probably in whatever eventually lets an agent reason about the boundary of its own context, not just the contents inside it.

References

• BMAD Method - Official documentation and BMAD-METHOD repository. Accessed July 2026.
• GitHub Spec Kit - Official documentation and spec-kit repository, including the workflows reference. Accessed July 2026.
• Superpowers - obra/superpowers repository. Accessed July 2026.
• AWS Kiro - Specs documentation, CLI specs reference, Quick Plan documentation, specs best practices, and Run all Tasks. Accessed July 2026.
• OpenSpec - Official site and Fission-AI/OpenSpec repository. Named for scope, not analyzed in depth here. Accessed July 2026.
• Ranjan Kumar, "Spec-Driven Development: Coupling Beats Writing", ranjankumar.in, July 2026.

Related Articles

Agentic AI

• Spec-Driven Development: Coupling Beats Writing
• Agent Skills Are Not Prompts. They Are Production Knowledge Infrastructure.
• Four Habits from the Creator of Claude Code That Will Change How You Ship
• Claude Code Guide: Build Agentic Workflows with Commands, MCP, and Subagents