Bmad analyze
Runs the BMAD analysis phases to produce structured project artefacts: brief, PRD, and architecture. Activates the appropriate BMAD agent for each phase. Each phase requires explicit user validation before the next begins. Produces files consumed by /ironforge:bmad-to-sudocode.From its SKILL.md
npx -y skills add RomainDECOSTER/ironforge --skill bmad-analyzeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
7.1 KB, as published. Nobody here has run it
BMAD Analysis
You are executing the Ironforge BMAD analysis phases. Produce structured artefacts that will feed
into Sudocode via /ironforge:bmad-to-sudocode. Each phase ends with user validation — do not
proceed to the next phase without explicit confirmation.
Task
$ARGUMENTS
If $ARGUMENTS is empty and no prior context exists in the conversation, ask the user to describe
the feature or project before starting.
Step 0 — Resolve input
Before anything else, check what $ARGUMENTS contains:
If $ARGUMENTS looks like a file path (ends in .md, .txt, or the path exists on disk):
- Read the file
- Use its content as the raw context for the BMAD analyst in Step 2
- Tell the user: "I'll use [filename] as input for the brief phase."
- Do not treat the file as a BMAD brief — it is raw notes, not a structured artefact
If $ARGUMENTS is a text description: use it directly as context for Step 2.
If $ARGUMENTS is empty: proceed to Step 1 normally.
Step 1 — Determine which phases to run
Check which artefacts already exist:
| File | Path |
|---|---|
| Brief | docs/briefs/brief.md |
| PRD | docs/prd/prd.md |
| Architecture | docs/arch/architecture.md |
- If a file exists, ask the user whether to regenerate it or skip to the next missing phase.
- Default: skip existing artefacts, run only what is missing.
Also check the workflow mode from context. The mode determines the depth of each phase:
| Mode | Brief | PRD | Architecture |
|---|---|---|---|
| FEATURE | Short (1 page max) | Focused on the feature only | Component-level only |
| FULL | Complete | Full product scope | System-wide |
If mode is unknown, ask before continuing.
Step 2 — Brief (skip if docs/briefs/brief.md exists and user confirms)
Graph context (if available):
If graphify-out/ exists in the project root, invoke the ironforge:graph-explore skill before
activating the agent:
Skill({ skill: "ironforge:graph-explore", args: "Quels modules et features existent déjà dans le codebase ?" })
If the skill returns content, prepend it to the agent context as:
## Contexte graphe
{graph_context}
If graphify-out/ is absent or ironforge:graph-explore returns empty, continue without graph context.
Activate @bmad-agent-analyst.
Produce a structured brief covering:
- Problem: what pain is being solved and for whom
- Objective: the measurable outcome
- Scope: what is in and explicitly out of scope
- Constraints: technical, time, or resource constraints
- Open questions: unresolved decisions that will affect design
FEATURE mode: keep to a conversational summary, 1 page max. No need for full stakeholder analysis. FULL mode: complete brief with context, user personas, success metrics.
On completion, write the output to docs/briefs/brief.md (create docs/briefs/ if it does not exist).
Present the brief to the user.
Gate: wait for explicit validation ("looks good", "approved", etc.) before continuing. If the user requests changes, apply them and re-present. Do not continue until approved.
Step 3 — PRD (skip if docs/prd/prd.md exists and user confirms)
Graph context (if available):
If graphify-out/ exists, invoke ironforge:graph-explore:
Skill({ skill: "ironforge:graph-explore", args: "Quelles sont les interfaces publiques et les points d'entrée existants ?" })
Prepend any returned content as ## Contexte graphe\n{graph_context} to the agent context.
Activate @bmad-agent-pm.
Produce a PRD from the validated brief covering:
- Features: each distinct capability with a clear title
- User stories: for each feature, who does what and why
- Acceptance criteria: specific, testable conditions for each feature
- Priority: MoSCoW or simple P0/P1/P2 labelling
- Non-goals: explicitly excluded from this release
FEATURE mode: one feature, focused acceptance criteria, no priority matrix needed. FULL mode: complete feature set with priorities and non-goals.
Write the output to docs/prd/prd.md (create docs/prd/ if it does not exist).
Present the PRD to the user.
Gate: wait for explicit validation before continuing. Changes requested → apply → re-present → wait again.
Step 4 — Architecture (skip if docs/arch/architecture.md exists and user confirms)
Graph context (if available):
If graphify-out/ exists, invoke ironforge:graph-explore:
Skill({ skill: "ironforge:graph-explore", args: "Quels patterns architecturaux sont utilisés ? Quelles dépendances du module cible ?" })
Prepend any returned content as ## Contexte graphe\n{graph_context} to the agent context.
Activate @bmad-agent-architect combined with @engineering-software-architect.
Brainstorming first
Before converging on a design, explore multiple approaches:
- Explore at least 3 distinct architectural approaches
- For each: describe the trade-offs (complexity, performance, maintainability, reversibility)
- Present the options to the user with a recommendation and reasoning
Do not proceed to the architecture doc until the user has chosen an approach (or confirmed the recommendation).
Architecture document
From the chosen approach, produce:
- Components: each major module or service with its responsibilities
- Interfaces: how components communicate (APIs, events, data contracts)
- Data model: key entities and their relationships (if applicable)
- Technology choices: specific libraries/frameworks with version constraints
- Cross-cutting concerns: auth, error handling, observability, security boundaries
- Implementation sequence: suggested order to build components, with rationale
FEATURE mode: component-level only. Skip data model and cross-cutting concerns unless directly relevant. FULL mode: full system-wide architecture.
For every library or framework mentioned, use Context7 to verify the API exists in the current version:
use context7— fetch documentation for [library@version]
Write the output to docs/arch/architecture.md (create docs/arch/ if it does not exist).
Present the architecture to the user.
Gate: wait for explicit validation before continuing. Changes requested → apply → re-present → wait again.
Step 5 — Handoff
Once all required phases are validated, output:
## BMAD Analysis — Done
**Artefacts produced:**
- [✓ / skipped] docs/briefs/brief.md
- [✓ / skipped] docs/prd/prd.md
- [✓ / skipped] docs/arch/architecture.md
**Next step:** /ironforge:bmad-to-sudocode