Feature Request: Stakeholder-readable rendering of Acceptance Criteria
Problem
As a system built with BMAD grows in scope and complexity, the Acceptance Criteria produced by create-story and quick-dev drift toward increasingly technical and implementation-oriented language — at least that is our consistent observation across multiple teams. They work well as input for the dev agent, but they stop being reviewable by the people who actually own the business outcome: domain experts, product owners, and end users.
In practice this breaks the "human in the loop" assumption. A story gets signed off because nobody on the business side can realistically parse the AC set, not because the AC set is correct. The result is exactly the review paradox described in #2003 and the specification bloat described in #1818, but seen from a different angle: it is not only too much spec, it is spec in the wrong language for the audience that has to approve it.
This matters especially in enterprise rollouts where BMAD is introduced to mixed teams (BA, PO, QA, Dev) and where formal acceptance by a non-technical role is part of the process. In our rollout (12 teams, enterprise context), trainers consistently hit this wall: the ACs are technically sound and the dev agent executes them well, but the business-side review step collapses.
Proposal
Add a dedicated rendering layer — a skill or workflow step — that produces a second, read-only view of the ACs in language tuned for non-technical reviewers. The technical AC set remains the source of truth for dev-story / quick-dev. The rendered view exists purely for human review and sign-off.
How it could work
- New skill, working name
bmad-translate-acs or bmad-review-lens, that takes a story file as input.
- For each AC, produce a business-language equivalent:
- No file paths, class names, API routes, or infrastructure terms.
- Written from the user's or business outcome's perspective.
- Given/When/Then is a good default shape, but plain declarative sentences are fine too.
- Output one artifact per story (e.g.
story-X.Y-review.md) that is self-contained and readable without opening any other BMAD artifact.
- Keep the original technical ACs untouched and authoritative. The review artifact links back to them by ID.
- Optional second pass: flag ACs that cannot be translated without losing meaning. These are usually implementation tasks masquerading as ACs and should be surfaced for rewrite.
Where it fits in the workflow
- After
create-story / quick-dev has produced the spec.
- Before the human review / sign-off step.
- Can be re-run idempotently after story updates.
Why a separate layer and not "just write simpler ACs"
Rewriting create-story to produce business-readable ACs directly would either weaken the input to the dev agent (which benefits from precision) or produce ACs that satisfy neither audience. A translation layer keeps the two concerns separate: one artifact for machines, one for humans, both traceable to the same story.
Related issues
Current workaround
We are running an in-house prompt today to do this translation manually after each story is generated. Happy to share it as a starting point for the implementation and to test any official implementation against our rollout.
Out of scope for this issue
- Replacing or changing the technical AC format used by the dev agent.
- Changing how
create-story itself generates ACs.
- Localization / translation between human languages (separate concern).
Feature Request: Stakeholder-readable rendering of Acceptance Criteria
Problem
As a system built with BMAD grows in scope and complexity, the Acceptance Criteria produced by
create-storyandquick-devdrift toward increasingly technical and implementation-oriented language — at least that is our consistent observation across multiple teams. They work well as input for the dev agent, but they stop being reviewable by the people who actually own the business outcome: domain experts, product owners, and end users.In practice this breaks the "human in the loop" assumption. A story gets signed off because nobody on the business side can realistically parse the AC set, not because the AC set is correct. The result is exactly the review paradox described in #2003 and the specification bloat described in #1818, but seen from a different angle: it is not only too much spec, it is spec in the wrong language for the audience that has to approve it.
This matters especially in enterprise rollouts where BMAD is introduced to mixed teams (BA, PO, QA, Dev) and where formal acceptance by a non-technical role is part of the process. In our rollout (12 teams, enterprise context), trainers consistently hit this wall: the ACs are technically sound and the dev agent executes them well, but the business-side review step collapses.
Proposal
Add a dedicated rendering layer — a skill or workflow step — that produces a second, read-only view of the ACs in language tuned for non-technical reviewers. The technical AC set remains the source of truth for
dev-story/quick-dev. The rendered view exists purely for human review and sign-off.How it could work
bmad-translate-acsorbmad-review-lens, that takes a story file as input.story-X.Y-review.md) that is self-contained and readable without opening any other BMAD artifact.Where it fits in the workflow
create-story/quick-devhas produced the spec.Why a separate layer and not "just write simpler ACs"
Rewriting
create-storyto produce business-readable ACs directly would either weaken the input to the dev agent (which benefits from precision) or produce ACs that satisfy neither audience. A translation layer keeps the two concerns separate: one artifact for machines, one for humans, both traceable to the same story.Related issues
quick-devdrops parent-artifact requirements during AC decomposition (same AC-handling area)Current workaround
We are running an in-house prompt today to do this translation manually after each story is generated. Happy to share it as a starting point for the implementation and to test any official implementation against our rollout.
Out of scope for this issue
create-storyitself generates ACs.