bmad-module-skill-forge 0.9.0 → 0.10.1-alpha.0

package/src/workflows/verify-stack/steps-c/step-03-integrations.md

@@ -1,195 +0,0 @@
----
-name: 'step-03-integrations'
-description: 'Pass 2 — cross-reference API surfaces between library pairs based on integration claims in the architecture document'
-
-nextStepFile: './step-04-requirements.md'
-integrationRulesData: '../data/integration-verification-rules.md'
-outputFile: '{forge_data_folder}/feasibility-report-{project_name}.md'
----
-
-# Step 3: Integration Verification
-
-## STEP GOAL:
-
-Cross-reference API surfaces between library pairs that the architecture document claims work together. For each integration pair, verify language compatibility, protocol alignment, type compatibility, and documentation cross-references. Produce an evidence-backed verdict for each integration.
-
-## 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 performing integration feasibility analysis
-- ✅ Every verdict must cite evidence from the actual skill content — no speculation
-- ✅ Apply the verification protocol strictly — do not skip compatibility checks
-
-### Step-Specific Rules:
-
-- 🎯 Focus ONLY on integration pair verification using skill API surfaces
-- 🚫 FORBIDDEN to evaluate requirements coverage — that is Step 04
-- 🚫 FORBIDDEN to parse Mermaid diagrams — use prose-based co-mention analysis only
-- 💬 Every verdict MUST include evidence citations from the skills
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Extract integration claims from architecture document prose
-- 💾 Load skill API surfaces and cross-reference each integration pair
-- 📖 Append Integration Verdicts section to {outputFile}
-- 🚫 Only integration analysis — no requirements checking, no synthesis
-
-## CONTEXT BOUNDARIES:
-
-- Available: Architecture document content, skill SKILL.md and metadata.json files, integration verification rules
-- Focus: Pairwise integration compatibility between skills
-- Limits: Only verify pairs explicitly claimed in the architecture document — do not invent integration relationships
-- Dependencies: Step 01 (skill inventory), Step 02 (coverage matrix — only verify skills that exist)
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
-
-### 1. Load Integration Verification Rules
-
-Load `{integrationRulesData}` for the cross-reference verification protocol.
-
-Extract: verification checks (language boundary, protocol compatibility, type compatibility, documentation cross-reference), verdict criteria, and evidence requirements.
-
-### 2. Extract Integration Claims
-
-Parse the architecture document for statements describing two or more technologies working together.
-
-**Detection method — prose-based co-mention analysis:**
-- Identify sentences or paragraphs where two or more technology names appear together
-- Look for integration verbs: "connects to", "communicates with", "wraps", "extends", "consumes", "produces", "bridges", "integrates with", "sits between"
-- Look for data flow descriptions: "{A} sends data to {B}", "{A} results are consumed by {B}"
-- Look for layer boundary descriptions: "{A} at the API layer connects to {B} at the data layer"
-
-**CRITICAL:** Do NOT parse Mermaid diagram syntax. Use only prose text for co-mention detection.
-
-**Build integration pairs list:**
-- Each pair: `{library_a, library_b, architectural_context}`
-- `architectural_context`: the quoted text or paraphrased description of their relationship
-
-**Filter:** Only include pairs where BOTH libraries have a corresponding skill (Covered in Step 02). Skip pairs involving Missing skills — they cannot be verified.
-
-### 3. Load Skill API Surfaces
-
-For each library in an integration pair, load the skill artifacts:
-
-**From SKILL.md, extract:**
-- Exported functions and their signatures
-- Exported types, interfaces, and classes
-- Protocol indicators (HTTP, gRPC, WebSocket, message queue, file I/O, IPC)
-- Data format indicators (JSON, protobuf, CSV, binary, streaming)
-
-**From metadata.json, extract:**
-- `language` — primary programming language
-- `exports` — export names array (populated for individual skills; empty for stack skills)
-- `stats.exports_documented` — export count
-- `confidence_tier` — extraction confidence level
-
-Store loaded API surfaces for cross-referencing.
-
-### 4. Cross-Reference Each Integration Pair
-
-For each integration pair `{library_a, library_b}`, apply the verification protocol from `{integrationRulesData}`:
-
-**Check 1 — Language Boundary:**
-- Same language → compatible
-- Different languages → check for FFI, IPC, or network protocol bridge
-- If no bridge mechanism documented → flag as risk
-
-**Check 2 — Protocol Compatibility:**
-- Both use same protocol (e.g., both HTTP) → compatible
-- Complementary protocols (e.g., HTTP client + HTTP server) → compatible
-- Incompatible protocols with no adapter → flag as risk
-
-**Check 3 — Type Compatibility:**
-- Shared types or compatible serialization formats → compatible
-- Incompatible type systems with no conversion layer → flag as risk
-
-**Check 4 — Documentation Cross-Reference:**
-- Skill A mentions skill B's library (or vice versa) → strong evidence
-- Neither skill mentions the other → weak evidence (plausible but unverified)
-
-**Assign verdict per pair:**
-- **Verified** — all checks pass with evidence from both skills
-- **Plausible** — checks pass but evidence is indirect or incomplete
-- **Risky** — one or more checks flag compatibility concerns
-- **Blocked** — fundamental incompatibility detected (language barrier with no bridge, incompatible protocols)
-
-**Each verdict MUST include:**
-- Which checks passed and which flagged
-- Evidence citations: specific exports, types, or protocol references from the skills
-
-### 5. Display Integration Results
-
-"**Pass 2: Integration Verification**
-
-| Library A | Library B | Context | Verdict | Evidence |
-|-----------|-----------|---------|---------|----------|
-| {lib_a} | {lib_b} | {brief context} | {Verified/Plausible/Risky/Blocked} | {key evidence} |
-
-**Summary:** {verified_count} Verified, {plausible_count} Plausible, {risky_count} Risky, {blocked_count} Blocked
-
-{IF zero integration pairs found:}
-**No integration claims detected in the architecture document prose.** Ensure your architecture document describes relationships between technologies in text form (not exclusively in Mermaid diagrams). Coverage-only analysis was performed.
-
-{IF any Risky:}
-**Risky Integrations — Recommendations:**
-{For each risky pair:}
-- `{lib_a}` ↔ `{lib_b}`: {specific concern}. **Recommendation:** {prescriptive action}
-
-{IF any Blocked:}
-**Blocked Integrations — Action Required:**
-{For each blocked pair:}
-- `{lib_a}` ↔ `{lib_b}`: {fundamental incompatibility}. **Recommendation:** {prescriptive action}"
-
-### 6. Append to Report
-
-Write the **Integration Verdicts** section to `{outputFile}`:
-- Include the full integration verdicts table with evidence
-- Include recommendations for Risky and Blocked pairs
-- Update frontmatter: append `'step-03-integrations'` to `stepsCompleted`
-- Set `integrations_verified`, `integrations_plausible`, `integrations_risky`, `integrations_blocked` counts
-
-### 7. Auto-Proceed to Next Step
-
-**Early halt guard:** If ALL integration pairs are Blocked, present: "**All integrations are Blocked** — fundamental incompatibilities detected across all library pairs. Remaining analysis will produce limited value. **[X] Halt workflow (recommended)** | **[C] Continue anyway**" — wait for user input. If X: halt with: "**Workflow halted — all integrations blocked.** Integration Verdicts saved to `{outputFile}`. Run **[VS]** after applying architectural changes. **Blocked integrations:** {list each blocked pair with reason}." If C: continue.
-
-{IF NOT halted (user selected C, or early halt guard did not trigger):}
-
-"**Proceeding to requirements verification...**"
-
-Load, read the full file and then execute `{nextStepFile}`.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Integration rules loaded from {integrationRulesData}
-- Integration claims extracted from architecture document prose (not Mermaid diagrams)
-- Skill API surfaces loaded for each library in integration pairs
-- All four verification checks applied to each pair
-- Every verdict includes evidence citations from actual skill content
-- Recommendations provided for every Risky and Blocked integration
-- Integration Verdicts section appended to {outputFile}
-- Auto-proceeded to step 04
-
-### ❌ SYSTEM FAILURE:
-
-- Parsing Mermaid diagrams instead of using prose-based co-mention analysis
-- Verdicts without evidence citations from actual skills
-- Inventing integration relationships not described in the architecture document
-- Skipping any of the four verification checks
-- Evaluating requirements coverage (that is Step 04)
-- 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

@@ -1,191 +0,0 @@
----
-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

@@ -1,197 +0,0 @@
----
-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

@@ -1,61 +0,0 @@
----
-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.