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

package/src/workflows/update-skill/steps-c/step-06-write.md

@@ -1,265 +0,0 @@
----
-name: 'step-06-write'
-description: 'Write updated SKILL.md, provenance-map.json, evidence-report.md, and stack reference files'
-
-nextStepFile: './step-07-report.md'
----
-
-# Step 6: Write Updated Files
-
-## STEP GOAL:
-
-Write all updated skill artifacts to disk: the merged SKILL.md, updated provenance-map.json with new timestamps and mappings, updated evidence-report.md with the update operation trail, and for stack skills, all affected reference files.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- ⚙️ 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 precision code analyst operating in Surgeon mode
-- ✅ File writes must be atomic — complete all writes or none
-- ✅ Every write must be verified after completion
-- ✅ Provenance metadata must accurately reflect the update operation
-
-### Step-Specific Rules:
-
-- 🎯 Focus ONLY on writing files — all merge and validation is complete
-- 🚫 FORBIDDEN to modify merged content during write — write exactly what was produced
-- 🚫 FORBIDDEN to skip provenance map update — this is critical for future audits
-- 💬 Verify each file after writing to confirm integrity
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Follow MANDATORY SEQUENCE exactly
-- 💾 Write all files in the correct locations
-- 📖 Update provenance map with current timestamps
-- 🚫 FORBIDDEN to proceed if any write fails
-
-## CONTEXT BOUNDARIES:
-
-- Available: merged content from step 04, validation results from step 05, extraction results from step 03, change manifest from step 02
-- Focus: file I/O operations — write and verify
-- Limits: write only to skill output and forge data directories
-- Dependencies: steps 02-05 must all be complete
-- Path resolution: See `knowledge/version-paths.md` for canonical path templates (`{skill_package}`, `{skill_group}`, `{forge_version}`, `{forge_group}`)
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
-
-### 1. Write Updated SKILL.md
-
-Write the merged SKILL.md content to `{skill_package}/SKILL.md`:
-- Overwrite the existing file with merged content
-- Preserve file encoding (UTF-8)
-- Verify write by reading back and confirming [MANUAL] section count matches expected
-
-If the version changed (source version differs from the previous metadata version), write to the new `{skill_package}` (creating the version directory if needed). The previous version's directory is preserved on disk.
-
-### 2. Write Updated metadata.json
-
-Update `{skill_package}/metadata.json`:
-- Update `version`: if a source version was detected during re-extraction and differs from the current metadata version, use the source version; otherwise increment patch version
-- Update `generation_date` timestamp to current ISO-8601 date
-- Update `exports` array to reflect current export list
-- Update `stats` from re-extraction results:
-  - `exports_documented`: count of exports with documentation in the merged skill
-  - `exports_public_api`: count of exports from public entry points (`__init__.py`, `index.ts`, `lib.rs`, or equivalent)
-  - `exports_internal`: count of all other non-underscore-prefixed exports
-  - `exports_total`: `exports_public_api` + `exports_internal`
-  - `public_api_coverage`: `exports_documented / exports_public_api` (`null` if `exports_public_api` is 0)
-  - `total_coverage`: `exports_documented / exports_total` (`null` if `exports_total` is 0)
-- Update `confidence_distribution` from re-extraction results:
-  - `confidence_distribution.t1`, `confidence_distribution.t1_low`, `confidence_distribution.t2`, `confidence_distribution.t3`: update counts from re-extraction results
-  - `scripts_count`, `assets_count`: update from re-extraction results if scripts/assets changed
-- For stack skills: update `library_count`, `integration_count` if changed
-
-### 3. Write Updated provenance-map.json
-
-Write to `{forge_version}/provenance-map.json`:
-
-**For each export in the updated skill:**
-- Update `export_name` if renamed
-- Update `params[]` array if parameters changed (add, remove, or modify individual entries)
-- Update `return_type` if changed
-- Update `source_file` if moved
-- Update `source_line` from fresh extraction
-- Update `confidence` from extraction results
-- Update `extraction_method` and `ast_node_type` if re-extracted with different tools
-
-**For deleted exports:**
-- Remove entry from provenance map
-
-**For new exports:**
-- Add new entry with full structured fields: `export_name`, `export_type`, `params[]`, `return_type`, `source_file`, `source_line`, `confidence`, `extraction_method`, `ast_node_type`
-
-**For script/asset file changes (if `file_entries` exists):**
-- MODIFIED_FILE: copy updated file to `scripts/` or `assets/`, update `content_hash` in `file_entries`
-- DELETED_FILE: remove file from `scripts/` or `assets/`, remove entry from `file_entries`
-- NEW_FILE: copy file to `scripts/` or `assets/`, add entry to `file_entries` with `file_name`, `file_type`, `source_file`, `confidence: "T1-low"`, `extraction_method: "file-copy"`, `content_hash`
-
-**Add update operation metadata:**
-```json
-{
-  "last_update": "{current_date}",
-  "update_type": "{incremental if normal mode | full if degraded_mode}",
-  "files_changed": {count},
-  "exports_affected": {count},
-  "confidence_tier": "{tier}",
-  "manual_sections_preserved": {count}
-}
-```
-
-### 4. Write Updated evidence-report.md
-
-Append update operation section to `{forge_version}/evidence-report.md` (create the file with a standard header if it does not yet exist):
-
-```markdown
-## Update Operation — {current_date}
-
-**Trigger:** {manual / audit-skill chain}
-**Forge Tier:** {tier}
-**Mode:** {normal / degraded}
-
-### Changes Detected
-- Files modified: {count}
-- Files added: {count}
-- Files deleted: {count}
-- Exports affected: {total}
-
-### Merge Results
-- Exports updated: {count}
-- Exports added: {count}
-- Exports removed: {count}
-- [MANUAL] sections preserved: {count}
-- Conflicts resolved: {count}
-
-### Validation Summary
-- Spec compliance: {PASS/WARN/FAIL}
-- [MANUAL] integrity: {PASS/WARN/FAIL}
-- Confidence tiers: {PASS/WARN/FAIL}
-- Provenance: {PASS/WARN/FAIL}
-```
-
-### 5. Write Stack Skill Reference Files (Conditional) and Regenerate context-snippet.md
-
-**ONLY if skill_type == "stack":**
-
-For each affected reference file from the merge:
-- Write updated `references/{library}.md` files
-- Write updated `references/integrations/{pair}.md` files
-- Verify [MANUAL] sections preserved in each reference file
-
-**For all skills (both single and stack) — regenerate `context-snippet.md`:**
-
-Per `knowledge/version-paths.md` "Writing Workflows (CS, QS, SS, US)", update-skill is a writing workflow that MUST write all deliverables to `{skill_package}`. `context-snippet.md` is one of those deliverables and goes stale whenever exports, version, or gotchas change.
-
-Regenerate the snippet using the format from the matching template file:
-
-- For single skills: `create-skill/data/skill-sections.md` (pipe-delimited indexed format)
-- For stack skills: `create-stack-skill/data/stack-skill-template.md`
-
-Use the **flat legacy form** for the `root:` path in the draft snippet: `root: skills/{skill-name}/`. The platform-specific prefix (`.claude/skills/`, `.cursor/skills/`, `.agents/skills/`) is applied later by `export-skill` step-03 when the skill is exported. Do not choose a platform prefix in update-skill — that is an export-time decision that depends on config.yaml.
-
-Pull values for the regenerated snippet from the updated metadata.json (version, top exports), the merged SKILL.md (section anchors, inline summaries), and the evidence report (new gotchas). If gotchas cannot be derived from the updated evidence but the prior snippet has a `|gotchas:` line, carry forward the prior line with the `[CARRIED]` marker — see `export-skill/steps-c/step-03-generate-snippet.md` for the carry-forward protocol (one-cycle limit).
-
-Write the regenerated snippet to `{skill_package}/context-snippet.md`, preserving file permissions.
-
-**If skill_type == "stack"**, also verify that the reference file updates from the first half of this section have been applied before writing the snippet so the stack snippet reflects the newest integration list.
-
-### 5b. Update Active Symlink (If Version Changed)
-
-If the version was incremented or changed in section 2 (metadata.json update):
-- Create or update the `active` symlink at `{skill_group}/active` pointing to the new `{version}`
-- If the symlink already exists, remove it first and recreate
-
-```
-{skill_group}/active -> {version}
-```
-
-If the version did not change, the existing symlink already points to the correct version -- no action needed.
-
-### 6. Verify All Writes
-
-For each file written:
-- Read back the file
-- Confirm content matches expected output
-- Confirm [MANUAL] sections are intact (count comparison)
-- Report verification status
-
-"**Write Verification:**
-
-| File | Status |
-|------|--------|
-| SKILL.md | {VERIFIED/FAILED} |
-| metadata.json | {VERIFIED/FAILED} |
-| provenance-map.json | {VERIFIED/FAILED} |
-| evidence-report.md | {VERIFIED/FAILED} |
-| {stack reference files...} | {VERIFIED/FAILED} |
-
-**All files written and verified.**"
-
-### 7. Run Post-Write Validation (Deferred from Step 05)
-
-External tool checks deferred from step-05 now run against the written files:
-
-**If skill-check available:**
-- Run: `npx skill-check check {skill_package} --fix --format json --no-security-scan`
-- **Context sync after --fix:** If `fixed[]` is non-empty (i.e., `--fix` modified files on disk), re-read the modified SKILL.md to update the in-context copy. This prevents silent divergence between the in-context SKILL.md and the on-disk version that step-07-report will reference.
-- If `body.max_lines` reported, prefer selective split — extract only the largest Tier 2 section(s) to `references/`, keeping Tier 1 inline (inline passive context achieves 100% task accuracy vs 79% for on-demand retrieval). Fall back to `npx skill-check split-body {skill_package} --write` if not feasible. Verify anchors resolve after split.
-- Run: `npx skill-check diff` if original version was preserved
-- Run: `npx skill-check check {skill_package} --format json` for security scan
-
-Record findings in the evidence report (section 4). These are advisory — do not block on warnings.
-
-**If skill-check unavailable:** Skip with note — structural checks from step-05 are sufficient.
-
-### 8. Present MENU OPTIONS
-
-Display: "**Proceeding to report...**"
-
-#### Menu Handling Logic:
-
-- After all writes verified and post-write validation complete, immediately load, read entire file, then execute {nextStepFile}
-
-#### EXECUTION RULES:
-
-- This is an auto-proceed step with no user choices
-- Proceed directly to report after verification
-
-## CRITICAL STEP COMPLETION NOTE
-
-ONLY WHEN all files have been written and verified will you load {nextStepFile} to display the change report.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- SKILL.md written to {skill_package} with all merged content and [MANUAL] sections intact
-- metadata.json updated with new version, timestamp, export counts
-- provenance-map.json updated at {forge_version} with current file:line references and timestamps
-- evidence-report.md appended at {forge_version} with update operation record
-- Stack reference files updated if applicable
-- Active symlink updated at {skill_group}/active -> {version} if version changed
-- All writes verified by read-back confirmation
-
-### ❌ SYSTEM FAILURE:
-
-- Any [MANUAL] section content different after write (integrity violation)
-- Skipping provenance map update
-- Not verifying writes after completion
-- Writing partial content (incomplete merge result)
-- Not updating metadata version
-- Leaving stale provenance entries for deleted exports
-
-**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

package/src/workflows/update-skill/workflow.md

@@ -1,56 +0,0 @@
----
-name: update-skill
-description: Smart regeneration preserving [MANUAL] sections. Detects individual vs stack internally.
-web_bundle: true
-installed_path: '{project-root}/_bmad/skf/workflows/skillforge/update-skill'
----
-
-# Update Skill
-
-**Goal:** Surgically update existing skills when source code changes, preserving all [MANUAL] developer content while re-extracting only affected exports with full provenance tracking.
-
-**Your Role:** In addition to your name, communication_style, and persona, you are also a precision code analyst operating in Surgeon mode. This is a surgical operation, not an exploratory session. You bring AST-backed structural analysis and provenance-driven change detection expertise, while the source code provides the ground truth. Every regenerated instruction must trace to code with file:line citations.
-
-## WORKFLOW ARCHITECTURE
-
-### 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
-- **Surgical Precision**: Only changed exports are re-extracted — unchanged content is never touched
-- **[MANUAL] Preservation**: Developer-authored [MANUAL] sections survive regeneration with zero content loss
-- **Zero Hallucination**: Every instruction must trace to actual code with AST file:line citations and confidence tier labels
-
-### 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
-- 🔬 **NEVER** hallucinate — every statement must have AST provenance
-
----
-
-## INITIALIZATION SEQUENCE
-
-### 1. Module Configuration Loading
-
-Load and read full config from {project-root}/_bmad/skf/config.yaml and resolve:
-
-- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`
-- `skills_output_folder`, `forge_data_folder`, `sidecar_path`
-
-### 2. First Step Execution
-
-Load, read the full file and then execute ./steps-c/step-01-init.md to begin the workflow.

package/src/workflows/verify-stack/data/feasibility-report-template.md

@@ -1,63 +0,0 @@
----
-workflowType: 'verify-stack'
-project_name: ''
-architecture_doc: ''
-prd_doc: ''
-date: ''
-overall_verdict: ''
-stepsCompleted: []
-skills_analyzed: 0
-coverage_percentage: 0
-integrations_verified: 0
-integrations_plausible: 0
-integrations_risky: 0
-integrations_blocked: 0
-requirements_fulfilled: null
-requirements_partial: null
-requirements_not_addressed: null
-requirements_pass: ''
-recommendation_count: 0
-prd_available: false
-previous_report: ''
-delta_improved: null
-delta_regressed: null
-delta_new: null
-delta_unchanged: null
----
-
-# Stack Feasibility Report: {project_name}
-
-**Verification Date:** {date}
-**Architecture Document:** {architecture_doc}
-**PRD Document:** {prd_doc}
-**Skills Analyzed:** {skills_analyzed}
-
-## Overall Verdict
-
-{FEASIBLE / CONDITIONALLY FEASIBLE / NOT FEASIBLE}
-
-{1-2 sentence summary}
-
----
-
-## Coverage Matrix
-
-<!-- Appended by step-02-coverage -->
-
----
-
-## Integration Verdicts
-
-<!-- Appended by step-03-integrations -->
-
----
-
-## Requirements Coverage
-
-<!-- Appended by step-04-requirements (if PRD provided) -->
-
----
-
-## Synthesis & Recommendations
-
-<!-- Appended by step-05-synthesize -->

package/src/workflows/verify-stack/data/integration-verification-rules.md

@@ -1,73 +0,0 @@
-# Integration Verification Rules
-
-## Purpose
-
-Rules for cross-referencing API surfaces between two skills to determine integration feasibility.
-
----
-
-## Verdict Definitions
-
-| Verdict | Meaning | Required Evidence |
-|---------|---------|-------------------|
-| **Verified** | APIs demonstrably connect — matching types, documented bridge, or shared protocol | At least one export from Skill A is consumable by an API in Skill B (or vice versa) with compatible types |
-| **Plausible** | Compatible types or protocols but no documented integration path | Both libraries operate in compatible domains with compatible data formats, but no direct API bridge is evident |
-| **Risky** | Type mismatch, protocol gap, or language boundary requiring a bridge | A clear gap exists (e.g., TypeScript↔Rust FFI needed) but a workaround is architecturally feasible |
-| **Blocked** | Fundamental incompatibility — no feasible integration path even with a bridge or adapter layer | The two libraries cannot exchange data in any documented way; requires replacing one of the libraries |
-
----
-
-## Cross-Reference Protocol
-
-For each integration pair (Library A ↔ Library B):
-
-### 1. Language Boundary Check
-
-| A Language | B Language | Assessment |
-|-----------|-----------|------------|
-| Same language | Same language | No boundary — direct API calls possible |
-| TypeScript ↔ Rust | Requires FFI, IPC, or WebSocket bridge | Check if a bridge library exists in the stack (e.g., Tauri provides JS↔Rust IPC) |
-| TypeScript ↔ Python | Requires REST/gRPC/WebSocket bridge | Typically not direct |
-| Any ↔ C/C++ | FFI available in most languages | Check for bindings |
-
-### 2. Protocol Compatibility Check
-
-| A Protocol | B Protocol | Assessment |
-|-----------|-----------|------------|
-| In-process (same runtime) | In-process | Direct — function calls |
-| HTTP/REST | HTTP/REST | Network bridge — compatible if API endpoints match |
-| WebSocket | WebSocket | Real-time bridge — check message format compatibility |
-| Shared filesystem | Shared filesystem | Async — check format compatibility |
-| Embedded database | Embedded database | May conflict on lock files — check for multi-writer support |
-
-### 3. Type Compatibility Check
-
-- Extract the primary data types each library produces/consumes from the skill's export list
-- Check: does Library A export a type that Library B accepts as input?
-- Common patterns: JSON serialization (universal bridge), binary formats (check codec), shared schemas (strong compatibility)
-
-### 4. Documentation Cross-Reference
-
-- Search Skill A's content for mentions of Library B's name
-- Search Skill B's content for mentions of Library A's name
-- If either mentions the other: strong evidence of documented integration
-- Check if either library's README lists the other as a companion/integration
-
----
-
-## Verdict Evidence Format
-
-Each verdict MUST include:
-
-```
-**{Library A} ↔ {Library B}: {VERDICT}**
-
-Evidence:
-- A exports: `{function_name}({params}) → {return_type}` [from skill: {skill_name}]
-- B accepts: `{function_name}({params})` [from skill: {skill_name}]
-- Compatibility: {explanation}
-- Language boundary: {same | bridge required via {mechanism}}
-
-{If RISKY or BLOCKED:}
-Recommendation: {actionable next step}
-```

package/src/workflows/verify-stack/steps-c/step-01-init.md

@@ -1,179 +0,0 @@
----
-name: 'step-01-init'
-description: 'Load generated skills from skills folder, accept architecture doc path and optional PRD path, validate all inputs exist'
-
-nextStepFile: './step-02-coverage.md'
-reportTemplate: '../data/feasibility-report-template.md'
-outputFile: '{forge_data_folder}/feasibility-report-{project_name}.md'
----
-
-# Step 1: Initialize Verification
-
-## STEP GOAL:
-
-Load all generated skills from the skills output folder, accept the architecture document path (required) and optional PRD/vision document path from the user, validate that all inputs exist and are readable, create the feasibility report document, and present an initialization summary before auto-proceeding.
-
-## 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 operating in Ferris Audit mode
-- ✅ Execute with prescriptive precision — every loaded skill must be validated against actual files
-- ✅ You enforce the zero-hallucination principle: only report skills that physically exist on disk
-
-### Step-Specific Rules:
-
-- 🎯 Focus ONLY on loading inputs, scanning skills, and creating the report skeleton
-- 🚫 FORBIDDEN to perform any coverage analysis or integration checking
-- 🚫 Auto-proceed init step — no user confirmation needed. Halts only on validation errors
-- 💬 Present a clear initialization summary so downstream steps have validated inputs
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Collect and validate all input documents and skill artifacts
-- 💾 Create feasibility report from {reportTemplate} with populated frontmatter
-- 📖 Auto-proceed to next step after successful initialization
-- 🚫 HALT with actionable error if minimum requirements not met
-
-## CONTEXT BOUNDARIES:
-
-- This is the first step — no prior workflow state exists
-- Requires skills to have been generated by create-skill or quick-skill workflows
-- User provides architecture document path (required) and optional PRD/vision document path
-- No dependency on setup-forge or forge-tier — this workflow operates on skill content only
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
-
-### 1. Accept Input Documents
-
-"**Verify Stack — Feasibility Analysis**
-
-Please provide the following:
-1. **Architecture document path** (REQUIRED) — your project's architecture doc
-2. **PRD or vision document path** (OPTIONAL) — for requirements coverage analysis
-3. **Previous feasibility report path** (OPTIONAL) — for delta comparison with a prior run (provide a backup copy)"
-
-Wait for user input.
-
-**Validate architecture document:**
-- Confirm the file exists and is readable
-- If missing or unreadable → "Architecture document not found at `{path}`. Provide a valid path."
-- HALT until a valid architecture document is provided
-
-**Validate PRD document (if provided):**
-- Confirm the file exists and is readable
-- If missing → "PRD document not found at `{path}`. Proceeding without PRD — requirements pass will be skipped."
-- Store PRD availability as `prd_available: true|false`
-
-**Validate previous report (if provided):**
-- Confirm the file exists and is readable
-- **Collision check:** Resolve both the provided path and `{outputFile}` to their absolute form before comparing (do not rely on string equality alone). If they resolve to the same location, warn: "The previous report path points to the same location as the new report. This file will be overwritten during this run. Provide a path to a backup copy, or leave empty to skip delta comparison." HALT until resolved.
-- If missing → "Previous report not found at `{path}`. Proceeding without delta comparison."
-- Store as `previous_report: {path}` (or empty string if not provided)
-
-### 2. Scan Skills Folder
-
-Read the `{skills_output_folder}` directory. Skills use a version-nested directory structure (see [knowledge/version-paths.md](../../../knowledge/version-paths.md)).
-
-**Version-aware skill discovery:**
-1. Read `{skills_output_folder}/.export-manifest.json` if it exists. For each skill in `exports`, use `active_version` to resolve `{skill_package}` = `{skills_output_folder}/{skill-name}/{active_version}/{skill-name}/`
-2. For any subdirectory not covered by the manifest, check for an `active` symlink at `{skills_output_folder}/{dir_name}/active` — resolve to `{skill_group}/active/{dir_name}/`
-3. Fall back to flat path `{skills_output_folder}/{dir_name}/` for unmigrated skills
-
-For each resolved skill package, check for the presence of `SKILL.md` and `metadata.json`.
-
-**For each valid skill directory, extract from metadata.json:**
-- `name` — skill name
-- `language` — primary language
-- `confidence_tier` — Quick, Forge, Forge+, or Deep
-- `exports_documented` — read from `stats.exports_documented` in metadata.json (count of documented exports)
-- `source_repo` or `source_root` — original source repository
-
-**Build a skill inventory** as an internal list of all loaded skills with the fields above.
-
-**If a resolved skill package lacks SKILL.md or metadata.json:**
-- Log: "Skipping `{dir_name}` — missing SKILL.md or metadata.json"
-- Do not include in inventory
-
-### 3. Validate Minimum Requirements
-
-**Check skill count:**
-- At least 2 valid skills must exist (a stack requires multiple libraries)
-- If fewer than 2 → "**Cannot proceed.** Only {count} skill(s) found in `{skills_output_folder}`. A stack requires at least 2 skills. Generate more skills with [CS] Create Skill or [QS] Quick Skill, then re-run [VS]."
-- HALT workflow
-
-**Check forge_data_folder:**
-- Verify `forge_data_folder` was resolved from config.yaml and is non-empty
-- If undefined or empty → "**Cannot proceed.** `forge_data_folder` is not configured in config.yaml. Re-run [SF] Setup Forge to initialize."
-- HALT workflow
-
-**Check architecture document:**
-- Confirm it was loaded successfully in section 1
-- If not → HALT with error (should not reach here if section 1 validation passed)
-
-### 4. Create Feasibility Report
-
-Load `{reportTemplate}` and create the output file at `{outputFile}`.
-
-**Populate frontmatter:**
-- `project_name`, `date`, `architecture_doc`, `prd_doc` (or "none")
-- `prd_available: true|false` (from section 1 validation)
-- `previous_report: {path}` (or empty string if not provided)
-- `skills_analyzed: {count}`
-- `overall_verdict: "pending"`
-- `stepsCompleted: ['step-01-init']`
-
-### 5. Display Initialization Summary
-
-"**Stack Verification Initialized**
-
-| Field | Value |
-|-------|-------|
-| **Skills Loaded** | {count} |
-| **Architecture Doc** | {architecture_doc} |
-| **PRD Document** | {prd_doc or 'Not provided — requirements pass will be skipped'} |
-| **Previous Report** | {previous_report or 'Not provided — no delta comparison'} |
-
-**Skill Inventory:**
-
-| Skill | Language | Tier | Exports |
-|-------|----------|------|---------|
-| {skill_name} | {language} | {confidence_tier} | {exports_documented} |
-
-**Proceeding to coverage analysis...**"
-
-### 6. Auto-Proceed to Next Step
-
-Load, read the full file and then execute `{nextStepFile}`.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Architecture document loaded and validated
-- PRD document loaded or absence recorded
-- Skills folder scanned with SKILL.md and metadata.json validation per skill
-- At least 2 valid skills in inventory
-- Feasibility report created from template with populated frontmatter
-- Initialization summary displayed with skill inventory table
-- Auto-proceeded to step 02
-
-### ❌ SYSTEM FAILURE:
-
-- Proceeding with fewer than 2 skills
-- Proceeding without a valid architecture document
-- Not validating SKILL.md and metadata.json existence per skill directory
-- Performing coverage or integration analysis in this step
-- Hardcoded paths instead of frontmatter variables
-
-**Master Rule:** This step validates inputs and initializes state. No analysis, no comparison, no verdicts.