bmad-module-skill-forge 0.6.0 → 0.7.1

package/src/workflows/verify-stack/steps-c/step-04-requirements.md

@@ -0,0 +1,168 @@
+---
+name: 'step-04-requirements'
+description: 'Pass 3 (OPTIONAL) — if PRD/vision document provided, verify the stack covers stated requirements'
+
+nextStepFile: './step-05-synthesize.md'
+outputFile: '{forge_data_folder}/feasibility-report-{project_name}.md'
+---
+
+# Step 4: Requirements Coverage
+
+## STEP GOAL:
+
+If a PRD or vision document was provided in Step 01, verify that the combined capabilities of the generated skills address each stated requirement. If no PRD was provided, skip this pass and auto-proceed. Produce a requirements coverage table with Fulfilled, Partially Fulfilled, or Not Addressed verdicts.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- ⚙️ TOOL/SUBPROCESS FALLBACK: If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a stack verification analyst assessing requirements coverage
+- ✅ Every verdict must reason from actual skill capabilities, not assumptions
+- ✅ "Not Addressed" is a valid and important finding — do not force-fit skills to requirements
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on requirements-to-skills coverage assessment
+- 🚫 FORBIDDEN to re-analyze integrations — that was Step 03
+- 🚫 FORBIDDEN to synthesize or produce overall verdicts — that is Step 05
+- 💬 If no PRD was provided, skip immediately with a clear message
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Extract requirements from PRD/vision document and assess skill coverage
+- 💾 Append Requirements Coverage section to {outputFile}
+- 📖 Auto-proceed to next step after completion or skip
+- 🚫 Only requirements coverage — no synthesis, no overall verdict
+
+## CONTEXT BOUNDARIES:
+
+- Available: PRD/vision document (if provided), skill SKILL.md files, metadata.json files
+- Focus: Mapping requirements to skill capabilities
+- Limits: Do not evaluate skill quality — only whether capabilities match requirements
+- Dependencies: Step 01 (PRD availability flag, skill inventory)
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
+
+### 1. Check PRD Availability
+
+**Check `prd_available` from workflow state (set in Step 01). If `prd_available` is false (no PRD/vision document was provided):**
+
+"**Pass 3: Requirements Coverage — Skipped**
+
+No PRD or vision document was provided. Requirements coverage analysis requires a document describing project capabilities and constraints.
+
+To include this pass, re-run **[VS]** with a PRD or vision document path.
+
+**Proceeding to synthesis...**"
+
+Update {outputFile} frontmatter: append `'step-04-requirements'` to `stepsCompleted`, set `requirements_pass: "skipped"`.
+
+Load, read the full file and then execute `{nextStepFile}`. **STOP HERE — do not execute sections 2-6.**
+
+**If PRD/vision document was provided:** Continue to section 2.
+
+### 2. Extract Requirements
+
+Parse the PRD/vision document for capability requirements.
+
+**Look for:**
+- **Feature descriptions** — explicit capabilities the product must have
+- **Technical requirements** — performance targets, scalability needs, platform support
+- **Non-functional requirements** — offline-first, real-time sync, multi-language support, accessibility, security constraints
+- **Integration requirements** — third-party service dependencies, API contracts
+- **Infrastructure requirements** — deployment targets, CI/CD needs, monitoring
+
+**Build a requirements list** with each entry containing:
+- `requirement_id` — sequential identifier (R1, R2, R3...)
+- `requirement_text` — the stated requirement
+- `category` — feature, technical, non-functional, integration, or infrastructure
+- `source_section` — the PRD section where it was found
+
+### 3. Assess Stack Coverage
+
+For each requirement, evaluate whether the combined capabilities of the generated skills address it.
+
+**Assessment method:**
+- Read each skill's SKILL.md exports, description, and capabilities sections
+- Check if skill exports provide functions, types, or patterns relevant to the requirement
+- Consider combinations of multiple skills that together address a requirement
+- For non-functional requirements, check if skills document relevant configuration or patterns
+
+**Assign verdict per requirement:**
+- **Fulfilled** — one or more skills clearly provide the needed capability, with specific exports or patterns identified
+- **Partially Fulfilled** — skills provide related capability but gaps remain (specify what is covered and what is not)
+- **Not Addressed** — no skill in the stack provides capability relevant to this requirement
+
+**Each verdict MUST include:**
+- Which skills contribute (if any)
+- Specific exports or capabilities from those skills that are relevant
+- For Partially Fulfilled: what gap remains
+
+### 4. Display Requirements Results
+
+"**Pass 3: Requirements Coverage**
+
+| ID | Requirement | Category | Verdict | Contributing Skills |
+|----|-------------|----------|---------|-------------------|
+| {id} | {requirement_text} | {category} | {Fulfilled/Partially Fulfilled/Not Addressed} | {skill_names or '—'} |
+
+**Coverage: {fulfilled_count} Fulfilled, {partial_count} Partially Fulfilled, {not_addressed_count} Not Addressed**
+
+{IF any Not Addressed:}
+**Unaddressed Requirements — Recommendations:**
+{For each not addressed requirement:}
+- **{id}:** {requirement_text} → Evaluate `{category}` libraries that provide this capability, generate a skill with **[CS]** or **[QS]**, then re-run **[VS]**
+
+{IF any Partially Fulfilled:}
+**Partial Coverage — Details:**
+{For each partially fulfilled requirement:}
+- **{id}:** Covered by `{skill_names}` — **Gap:** {what remains unaddressed}"
+
+### 5. Append to Report
+
+Write the **Requirements Coverage** section to `{outputFile}`:
+- Include the full requirements coverage table
+- Include recommendations for Not Addressed and Partially Fulfilled items
+- Update frontmatter: append `'step-04-requirements'` to `stepsCompleted`
+- Set `requirements_pass: "completed"`
+- Set `requirements_fulfilled`, `requirements_partial`, `requirements_not_addressed` counts
+
+### 6. Auto-Proceed to Next Step
+
+"**Proceeding to synthesis...**"
+
+Load, read the full file and then execute `{nextStepFile}`.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- PRD availability checked first — skipped cleanly if not provided
+- All requirements extracted from PRD with source section citations
+- Each requirement assessed against actual skill capabilities (exports, descriptions)
+- Verdicts include contributing skill names and specific capabilities
+- Not Addressed items have actionable recommendations
+- Requirements Coverage section appended to {outputFile}
+- Auto-proceeded to step 05
+
+### ❌ SYSTEM FAILURE:
+
+- Fabricating requirements not stated in the PRD document
+- Force-fitting skills to requirements they do not address
+- Verdicts without evidence from actual skill content
+- Not executing the skip path when no PRD was provided
+- Producing synthesis or overall verdicts (that is Step 05)
+- Hardcoded paths instead of frontmatter variables
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

package/src/workflows/verify-stack/steps-c/step-05-synthesize.md

@@ -0,0 +1,191 @@
+---
+name: 'step-05-synthesize'
+description: 'Produce overall feasibility verdict, prescriptive recommendations, and diff from previous run'
+
+nextStepFile: './step-06-report.md'
+outputFile: '{forge_data_folder}/feasibility-report-{project_name}.md'
+---
+
+# Step 5: Synthesize Verdict
+
+## STEP GOAL:
+
+Calculate the overall feasibility verdict based on all three analysis passes, generate prescriptive recommendations for every non-verified finding, check for a previous feasibility report to produce a delta, and compile the synthesis section of the report.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- ⚙️ TOOL/SUBPROCESS FALLBACK: If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a stack verification analyst delivering the final synthesis
+- ✅ The overall verdict must follow the decision logic exactly — no subjectivity
+- ✅ Every recommendation must be specific and actionable — not vague advice
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on synthesizing findings from Steps 02-04 into a verdict
+- 🚫 FORBIDDEN to discover new findings or re-analyze skills
+- 🚫 FORBIDDEN to present the final report to the user — that is Step 06
+- 💬 Recommendations must name specific tools, libraries, or actions
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Apply verdict decision logic to produce FEASIBLE / CONDITIONALLY FEASIBLE / NOT FEASIBLE
+- 💾 Append Synthesis & Recommendations section to {outputFile}
+- 📖 Check for previous report and generate delta if found
+- 🚫 Only synthesis — no new analysis, no final presentation
+
+## CONTEXT BOUNDARIES:
+
+- Available: Coverage matrix (Step 02), integration verdicts (Step 03), requirements coverage (Step 04 if applicable)
+- Focus: Verdict calculation, recommendation generation, delta comparison
+- Limits: Do not present the full report — that is Step 06
+- Dependencies: Steps 02-03 must be complete; Step 04 completed or skipped
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
+
+### 1. Calculate Overall Verdict
+
+Apply the following decision logic using findings from all completed passes:
+
+**Evaluate in order — the first matching condition wins. Do not continue once a verdict is determined.**
+
+**NOT FEASIBLE (evaluate first):**
+- Any integration is **Blocked** → overall verdict is NOT FEASIBLE
+- Rationale: a blocked integration represents a fundamental architectural incompatibility. Also note in the rationale any co-occurring Missing skills or Risky integrations so the user understands the full set of problems
+
+**CONDITIONALLY FEASIBLE (evaluate second):**
+If ANY of the following apply, the verdict is CONDITIONALLY FEASIBLE. Include ALL matching conditions in the rationale:
+- Any technology is **Missing** from coverage (no skill exists)
+- Any integration is **Risky** (but none Blocked)
+- Requirements have any **Not Addressed** items
+- Requirements have any **Partially Fulfilled** items
+- Rationale: the stack can work but has gaps, risks, or unverified assumptions that must be addressed
+
+**FEASIBLE (evaluate last):**
+- Coverage is 100% (no Missing skills) AND all integrations are Verified or Plausible AND requirements are all Fulfilled (or requirements pass was skipped) AND no Blocked or Risky integrations → overall verdict is FEASIBLE
+- Rationale: {IF requirements pass completed:} the stack can support the architecture as described — all requirements fully fulfilled. {IF requirements pass was skipped:} the stack can support the architecture as described — requirements were not evaluated (no PRD provided)
+
+**Post-verdict: Zero integration pairs guard (apply after ANY verdict):**
+If zero integration pairs were extracted (all four integration counts are 0) AND the architecture document references 2+ technologies:
+- If the verdict was FEASIBLE, override to CONDITIONALLY FEASIBLE
+- Regardless of verdict, append this note to the rationale: "No integration claims were found in the architecture document prose. Manual review recommended to confirm that technology relationships are not documented exclusively in diagrams or implied without explicit co-mention."
+
+Store the verdict for use in the report.
+
+### 2. Generate Prescriptive Recommendations
+
+For each non-verified finding across all passes, generate an actionable next step:
+
+**Missing skill (from Step 02):**
+- "Run **[CS] Create Skill** or **[QS] Quick Skill** for `{library_name}`, then re-run **[VS]** to verify coverage."
+
+**Risky integration (from Step 03):**
+- If protocol mismatch → "Consider adding a bridge layer between `{lib_a}` and `{lib_b}` (e.g., HTTP adapter, message queue). Document the bridge in the architecture."
+- If type incompatibility → "Add a serialization/conversion layer between `{lib_a}` and `{lib_b}` to resolve the type mismatch identified in their API surfaces."
+- If weak evidence → "Add cross-references between `{lib_a}` and `{lib_b}` skills by re-running **[CS]** with integration context."
+
+**Blocked integration (from Step 03):**
+- If language barrier → "Replace `{lib_a}` with a `{lib_b_language}`-compatible alternative, or introduce an IPC/FFI bridge. Redesign the integration path in the architecture document."
+- If fundamental incompatibility → "Replace `{blocked_lib}` with an alternative that is compatible with `{other_lib}` in the same domain, or redesign the integration path in the architecture document."
+
+**Not Addressed requirement (from Step 04):**
+- "No library in the stack covers `{requirement}`. Evaluate `{category}` libraries that provide this capability, generate a skill, then re-run **[VS]**."
+
+**Partially Fulfilled requirement (from Step 04):**
+- "Gap in `{requirement}`: {what_is_missing}. Consider extending `{contributing_skill}` or adding a dedicated library."
+
+**Zero integration pairs (from Step 03):**
+- If zero integration pairs were found AND the architecture references 2+ technologies: "No integration claims were found in the architecture document prose. Add explicit prose descriptions of how your technologies interact (not only in diagrams), then re-run **[VS]** to verify integrations."
+
+### 3. Check for Previous Report
+
+Check if a `previous_report` path was recorded in the current report's frontmatter. Since the current workflow run overwrites the report starting in Step 01, the delta feature requires the user to have saved a copy before re-running [VS].
+
+**Note:** The delta feature is only available when the user has manually backed up a prior report and provided the path. To enable delta comparisons, instruct the user to copy their feasibility report (e.g., `feasibility-report-{project_name}-v1.md`) before re-running [VS], then provide the backup path when prompted in Step 01.
+
+**If a previous report is found:**
+- Load its verdict, coverage percentage, and integration verdicts
+- Generate a delta comparison:
+  - **Improved items:** findings that were Risky/Blocked/Missing and are now Verified/Covered
+  - **Regressed items:** findings that were Verified/Covered and are now Risky/Blocked/Missing
+  - **New items:** findings not present in the previous report
+  - **Unchanged items:** count of findings with the same verdict
+
+**If no previous report found:**
+- Note: "First verification run — no delta available."
+
+### 4. Compile Synthesis Section
+
+Assemble the following for the report:
+
+**Overall verdict** with rationale citing the decision logic.
+
+**Recommendation list** ordered by priority (count total recommendations as `recommendation_count` — persist this count to `{outputFile}` frontmatter for use in step-06):
+1. Blocked integrations (if any)
+2. Missing skills
+3. Risky integrations
+4. Not Addressed requirements
+5. Partially Fulfilled requirements
+
+**Delta from previous run** (if applicable):
+- Improved, regressed, new, unchanged counts
+- Specific items that changed
+
+**Suggested next workflow:**
+- FEASIBLE → "Proceed to **[RA] Refine Architecture** to produce an implementation-ready architecture, then **[SS]** to compose your stack skill, then **[TS]** to test and **[EX]** to export."
+- CONDITIONALLY FEASIBLE → "Address the {recommendation_count} recommendations above, then re-run **[VS]**. Once all clear, proceed to **[RA]**."
+- NOT FEASIBLE → "Critical blockers must be resolved before proceeding. Apply the recommendations above and re-run **[VS]**."
+
+### 5. Append to Report
+
+Write the **Synthesis & Recommendations** section to `{outputFile}`:
+- Include overall verdict with rationale
+- Include prioritized recommendation list
+- Include delta from previous run (if applicable)
+- Include suggested next workflow
+- **Replace the body placeholder** in the `## Overall Verdict` section: replace `{FEASIBLE / CONDITIONALLY FEASIBLE / NOT FEASIBLE}` and `{1-2 sentence summary}` with the actual calculated verdict and rationale text
+- Update frontmatter: append `'step-05-synthesize'` to `stepsCompleted`
+- Set `overall_verdict` to the calculated verdict
+- Set `recommendation_count` to the total number of recommendations
+- If delta was computed (section 3), set `delta_improved`, `delta_regressed`, `delta_new`, `delta_unchanged` in frontmatter to the respective counts
+- Verify that `integrations_verified`, `integrations_plausible`, `integrations_risky`, `integrations_blocked` in frontmatter match the counts from Step 03 (these were set in Step 03). If a discrepancy is found, overwrite the frontmatter counts with the values from Step 03 — the report file is the system of record
+
+### 6. Auto-Proceed to Next Step
+
+"**Proceeding to final report presentation...**"
+
+Load, read the full file and then execute `{nextStepFile}`.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Overall verdict calculated using the exact decision logic (not subjective judgment)
+- Every non-verified finding has a specific, actionable recommendation
+- Recommendations name concrete tools ([CS], [QS], [VS], [RA]) and specific libraries
+- Previous report delta generated if applicable
+- Synthesis section appended to {outputFile} with verdict, recommendations, and next workflow
+- Frontmatter updated with overall_verdict and metric counts
+- Auto-proceeded to step 06
+
+### ❌ SYSTEM FAILURE:
+
+- Subjective or vague overall verdict not following the decision logic
+- Recommendations without specific actions ("improve the integration")
+- Not checking for previous report
+- Discovering new findings or re-analyzing skills
+- Presenting the full report to the user (that is Step 06)
+- Hardcoded paths instead of frontmatter variables
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

package/src/workflows/verify-stack/steps-c/step-06-report.md

@@ -0,0 +1,197 @@
+---
+name: 'step-06-report'
+description: 'Present the final feasibility report to the user with verdict, findings, and next steps'
+
+outputFile: '{forge_data_folder}/feasibility-report-{project_name}.md'
+---
+
+# Step 6: Present Report
+
+## STEP GOAL:
+
+Present the complete feasibility report to the user. Display the overall verdict prominently, walk through key findings from each analysis pass, present actionable next steps based on the verdict, and offer the user options to review the full report or exit.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 📖 CRITICAL: Read the complete step file before taking any action
+- ⚙️ TOOL/SUBPROCESS FALLBACK: If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a stack verification analyst delivering the final report
+- ✅ Present findings clearly and concisely — the user needs to make decisions
+- ✅ Next step recommendations must match the verdict exactly
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on presenting the completed report — no new analysis
+- 🚫 FORBIDDEN to discover new findings, re-analyze skills, or change verdicts
+- 🚫 FORBIDDEN to modify the report content — only read and present
+- 📋 This is the FINAL step — no nextStepFile
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Load and present the complete feasibility report
+- 💾 No new content written — report was finalized in Step 05
+- 📖 Present summary, detailed findings, and next steps clearly
+- 🚫 Read-only presentation — do not alter report data
+
+## CONTEXT BOUNDARIES:
+
+- Available: Complete {outputFile} with all sections from Steps 01-05
+- Focus: Clear, actionable presentation of findings
+- Limits: Do not add new analysis or change any verdicts
+- Dependencies: All previous steps must be complete (Steps 01-05)
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
+
+### 1. Load Complete Report
+
+Read the entire `{outputFile}` to have all data available for presentation.
+
+Verify all expected sections are present: Coverage Matrix, Integration Verdicts, Requirements Coverage (or skipped notation), Synthesis & Recommendations.
+
+**Extract metrics from frontmatter:** Read `skills_analyzed`, `coverage_percentage`, `integrations_verified` (as `verified_count`), `integrations_plausible` (as `plausible_count`), `integrations_risky` (as `risky_count`), `integrations_blocked` (as `blocked_count`), `requirements_fulfilled` (as `fulfilled_count`), `requirements_partial` (as `partial_count`), `requirements_not_addressed` (as `not_addressed_count`), `requirements_pass`, `overall_verdict`, and `recommendation_count`. Use these mapped display names in the summary table and next steps below.
+
+### 2. Present Summary
+
+"**Verify Stack — Feasibility Report**
+
+---
+
+**Overall Verdict: {FEASIBLE / CONDITIONALLY FEASIBLE / NOT FEASIBLE}**
+
+| Metric | Value |
+|--------|-------|
+| **Skills Analyzed** | {skills_analyzed} |
+| **Coverage** | {coverage_percentage}% |
+| **Integrations Verified** | {verified_count} |
+| **Integrations Plausible** | {plausible_count} |
+| **Integrations Risky** | {risky_count} |
+| **Integrations Blocked** | {blocked_count} |
+| **Requirements Fulfilled** | {fulfilled_count or 'N/A — no PRD'} |
+| **Requirements Partially Fulfilled** | {partial_count or 'N/A — no PRD'} |
+| **Requirements Not Addressed** | {not_addressed_count or 'N/A — no PRD'} |
+
+{IF delta_improved is not null (delta from previous run exists):}
+**Delta from Previous Run:**
+- Improved: {delta_improved} items
+- Regressed: {delta_regressed} items
+- New: {delta_new} items
+- Unchanged: {delta_unchanged} items
+
+---"
+
+### 3. Present Detailed Findings
+
+Walk through each section briefly, focusing on items that need attention:
+
+"**Coverage Highlights:**
+{IF 100% coverage:}
+- All referenced technologies have a matching skill
+
+{IF any missing:}
+- **Missing:** {list of missing technology names}
+
+**Integration Verdicts:**
+{IF all Verified/Plausible:}
+- All integration pairs verified or plausible — no blockers
+
+{IF any Risky:}
+- **Risky:** {list of risky pairs with brief concern}
+
+{IF any Blocked:}
+- **Blocked:** {list of blocked pairs with brief incompatibility}
+
+{IF requirements pass completed:}
+**Requirements Gaps:**
+{IF all Fulfilled:}
+- All stated requirements addressed by the stack
+
+{IF any Partially Fulfilled:}
+- **Partially Fulfilled:** {list of partially covered requirements with gap description}
+
+{IF any Not Addressed:}
+- **Not Addressed:** {list of unaddressed requirements}"
+
+### 4. Present Next Steps
+
+Based on the overall verdict, present the appropriate recommendation:
+
+**IF FEASIBLE:**
+"**Your stack is verified.** All technologies are covered, integrations are compatible, and requirements are all fulfilled (or requirements pass was skipped).
+
+**Recommended next steps:**
+1. **[RA] Refine Architecture** — Produce an implementation-ready architecture document enriched with skill-backed API details
+2. **[SS] Create Stack Skill** — compose your individual skills into a unified stack skill, providing the refined architecture doc when prompted
+3. **[TS] Test Skill** → **[EX] Export Skill** — Verify completeness and package for distribution"
+
+**IF CONDITIONALLY FEASIBLE:**
+"**Your stack is conditionally feasible.** There are {recommendation_count} items to address before proceeding.
+
+**Required actions:**
+{List the specific recommendations from Step 05 synthesis}
+
+**After addressing these items:** Re-run **[VS] Verify Stack** to confirm resolution, then proceed to **[RA]**."
+
+**IF NOT FEASIBLE:**
+"**Critical blockers must be resolved.** The stack cannot support the architecture as described.
+
+**Critical actions:**
+{List the blocked integration recommendations and missing skill actions from Step 05}
+
+**After resolving blockers:** Re-run **[VS] Verify Stack**. Repeat until verdict improves to FEASIBLE or CONDITIONALLY FEASIBLE."
+
+### 5. Present Menu
+
+Display: "**[R] Review full report** | **[X] Exit verification**"
+
+#### Menu Handling Logic:
+
+- **IF R:** Walk through the report section by section, presenting each section's content from {outputFile} in a readable format. After completing the walkthrough, redisplay the menu. (Note: the R walkthrough loop terminates only when the user selects X.)
+- **IF X:** "**Feasibility report saved to:** `{outputFile}`
+
+Re-run **[VS] Verify Stack** anytime after making changes to your skills or architecture document.
+
+**Verification workflow complete.**"
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input after presenting the menu
+- R may be selected multiple times — always walk through the full report
+- X ends the workflow
+
+## CRITICAL STEP COMPLETION NOTE
+
+This is the final step of the verify-stack workflow. When the user selects X, the workflow is complete. The feasibility report at `{outputFile}` contains the full analysis: Coverage Matrix, Integration Verdicts, Requirements Coverage, and Synthesis & Recommendations.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Complete report loaded and verified for section completeness
+- Overall verdict displayed prominently with key metrics
+- Delta from previous run shown if applicable
+- Detailed findings presented with focus on risky/blocked/missing items
+- Next steps match the verdict exactly (FEASIBLE/CONDITIONALLY FEASIBLE/NOT FEASIBLE)
+- Menu presented with R and X options
+- Report walkthrough available on R selection
+- Workflow exits cleanly on X with saved file path
+
+### ❌ SYSTEM FAILURE:
+
+- Discovering new findings or changing verdicts in this step
+- Modifying the report content
+- Next step recommendations that do not match the verdict
+- Not presenting the menu
+- Not displaying the report save path on exit
+- Hardcoded paths instead of frontmatter variables
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

package/src/workflows/verify-stack/workflow.md

@@ -0,0 +1,61 @@
+---
+name: verify-stack
+description: Validate tech stack feasibility against architecture and PRD documents
+web_bundle: true
+installed_path: '{project-root}/_bmad/skf/workflows/skillforge/verify-stack'
+---
+
+# Verify Stack
+
+**Goal:** Cross-reference generated skills against architecture and PRD documents to produce a feasibility report with evidence-backed integration verdicts, coverage analysis, and requirements mapping.
+
+**Your Role:** In addition to your name, communication_style, and persona, you are also a stack feasibility analyst and integration verifier operating in Ferris Audit mode. You bring expertise in API surface analysis, cross-library compatibility assessment, and architecture validation, while the user brings their architecture vision and generated skills. Execute with analytical precision — every verdict must cite evidence from the generated skills.
+
+---
+
+## WORKFLOW ARCHITECTURE
+
+This uses **step-file architecture** for disciplined execution:
+
+### Core Principles
+
+- **Micro-file Design**: Each step is a self-contained instruction file that must be followed exactly
+- **Just-In-Time Loading**: Only the current step file is in memory — never load future step files until told to do so
+- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
+- **Read-Only Analysis**: This workflow never modifies skills or input documents — it only reads and produces a feasibility report
+- **Evidence-Backed Verdicts**: Every integration verdict must cite specific APIs, types, or function signatures from the generated skills
+
+### Step Processing Rules
+
+1. **READ COMPLETELY**: Always read the entire step file before taking any action
+2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
+3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
+4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
+5. **LOAD NEXT**: When directed, load, read entire file, then execute the next step file
+
+### Critical Rules (NO EXCEPTIONS)
+
+- 🛑 **NEVER** load multiple step files simultaneously
+- 📖 **ALWAYS** read entire step file before execution
+- 🚫 **NEVER** skip steps or optimize the sequence
+- 🎯 **ALWAYS** follow the exact instructions in the step file
+- ⏸️ **ALWAYS** halt at menus and wait for user input
+- 📋 **NEVER** create mental todo lists from future steps
+- ⚙️ **TOOL/SUBPROCESS FALLBACK**: If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- 🔒 **READ-ONLY**: This workflow NEVER modifies skills, architecture docs, or PRD files
+
+---
+
+## INITIALIZATION SEQUENCE
+
+### 1. Module Configuration Loading
+
+Load and read full config from {project-root}/_bmad/skf/config.yaml and resolve:
+
+- `project_name`, `user_name`, `communication_language`
+- `skills_output_folder`, `forge_data_folder`, `document_output_language`
+
+### 2. First Step Execution
+
+Load, read the full file and then execute `./steps-c/step-01-init.md` to begin the workflow.