bmad-module-skill-forge 0.6.0 → 0.7.1

package/src/workflows/setup-forge/steps-c/step-02-write-config.md

@@ -41,10 +41,10 @@ Write the detected tool availability and calculated tier to forge-tier.yaml, cre
 
 ## CONTEXT BOUNDARIES:
 
-- Available: {detected_tools}, {calculated_tier}, {previous_tier} from step-01
+- Available: {detected_tools}, {calculated_tier}, {previous_tier} from step-01; {ccc_index_result}, {ccc_indexed_path}, {ccc_last_indexed} from step-01b
 - Focus: file I/O operations only
 - Limits: do not modify preferences.yaml if it exists
-- Dependencies: step-01 must have completed with tool detection results
+- Dependencies: step-01 and step-01b must have completed with tool detection and CCC index results
 
 ## MANDATORY SEQUENCE
 
@@ -76,18 +76,19 @@ tier_detected_at: {current ISO timestamp}
 ccc_index:
   indexed_path: {ccc_indexed_path from step-01b, or ~}
   last_indexed: {ccc_last_indexed from step-01b, or ~}
-  status: {ccc_index_status from step-01b: "fresh"|"created"|"none"|"failed"}
+  status: {ccc_index_result from step-01b: "fresh"|"created"|"none"|"failed"}
   staleness_threshold_hours: 24
 
 # CCC index registry (tracks which source paths have been indexed for skill workflows)
-ccc_index_registry: []
+# PRESERVE existing entries on re-runs — see Note below
+ccc_index_registry: {preserved from existing forge-tier.yaml, or [] if first run}
 
 # QMD collection registry (populated by create-skill, consumed by audit/update-skill)
-# Each entry tracks a QMD collection created during skill workflows
-qmd_collections: []
+# PRESERVE existing entries on re-runs — see Note below
+qmd_collections: {preserved from existing forge-tier.yaml, or [] if first run}
 ```
 
-**Note on re-runs:** The `qmd_collections` and `ccc_index_registry` arrays must be preserved across re-runs. Before overwriting forge-tier.yaml, read the existing `qmd_collections` and `ccc_index_registry` arrays and re-inject them into the new write. These arrays are populated by create-skill workflows and must not be reset.
+**Note on re-runs:** The `qmd_collections`, `ccc_index_registry` arrays, and `staleness_threshold_hours` value must be preserved across re-runs. Before overwriting forge-tier.yaml, read these existing values and re-inject them into the new write. These values are populated by create-skill workflows or customized by users and must not be reset.
 
 **This file is ALWAYS overwritten** on every run — it reflects current tool state.
 
@@ -110,27 +111,25 @@ tier_override: ~
 # Passive context injection (set to false to skip snippet generation and CLAUDE.md updates during export)
 passive_context: true
 
-# Language defaults
-output_language: ~
-skill_format_version: ~
-
-# Output preferences
-citation_style: ~
-confidence_display: ~
+# Reserved for future use — these fields are not yet consumed by any workflow step
+# output_language: ~
+# skill_format_version: ~
+# citation_style: ~
+# confidence_display: ~
 ```
 
 **If it DOES exist:** Do not modify. Preserve entirely.
 
 ### 3. Ensure forge-data/ Directory
 
-Check if `{project-root}/forge-data/` directory exists:
+Check if `{forge_data_folder}` directory exists:
 
 - If missing: create it
 - If exists: skip silently
 
 ### 4. Auto-Proceed
 
-"**Proceeding to auto-index check...**"
+"**Proceeding to QMD collection hygiene...**"
 
 #### Menu Handling Logic:
 

package/src/workflows/setup-forge/steps-c/step-03-auto-index.md

@@ -59,7 +59,7 @@ For Quick and Forge tiers (without ccc), skip silently and proceed. For Forge+ t
 
 Read `{calculated_tier}` from context.
 
-**If tier is Quick or Forge:** Proceed directly to section 6 (Auto-Proceed) — no output, no messaging.
+**If tier is Quick or Forge:** Set `{ccc_registry_stale_cleaned: 0}`. Proceed directly to section 6 (Auto-Proceed) — no output, no messaging.
 
 **If tier is Forge+:** Skip QMD hygiene (qmd is not available at Forge+). Proceed directly to section 5b (CCC Index Registry Hygiene) — no QMD output, no messaging.
 

package/src/workflows/setup-forge/steps-c/step-04-report.md

@@ -115,10 +115,10 @@ Load and read {tierRulesData} for the tier capability descriptions and re-run me
 
 ### 3. Handle --update-spec Flag (Optional)
 
-**If `--update-spec` was passed:**
+**If the user included `--update-spec` in their workflow invocation (e.g., `@Ferris SF --update-spec`):**
 - Attempt to fetch the latest agentskills.io specification schema
 - Use `gh` or `curl` to retrieve the spec
-- Store in `{project-root}/forge-data/agentskills-spec.json` (or appropriate format)
+- Store in `{forge_data_folder}/agentskills-spec.json` (or appropriate format)
 - If fetch succeeds: display "agentskills.io spec updated."
 - If fetch fails: display "Could not fetch agentskills.io spec. Existing spec (if any) unchanged."
 - Do NOT fail the workflow over this — it is purely optional

package/src/workflows/setup-forge/workflow.md

@@ -1,6 +1,6 @@
 ---
 name: setup-forge
-description: Initialize forge environment, detect tools, set tier, auto-index project
+description: Initialize forge environment, detect tools, set tier, verify QMD collection hygiene
 web_bundle: true
 installed_path: '{project-root}/_bmad/skf/workflows/skillforge/setup-forge'
 ---
@@ -15,7 +15,7 @@ installed_path: '{project-root}/_bmad/skf/workflows/skillforge/setup-forge'
 
 ### Core Principles
 
-- **Micro-file Design**: Each step of the overall goal is a self contained instruction file that you will adhere too 1 file as directed at a time
+- **Micro-file Design**: Each step of the overall goal is a self contained instruction file that you will adhere to 1 file as directed at a time
 - **Just-In-Time Loading**: Only 1 current step file will be loaded, read, and executed to completion - 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
 - **Fully Autonomous**: All steps auto-proceed with no user interaction until the final report
@@ -44,6 +44,7 @@ installed_path: '{project-root}/_bmad/skf/workflows/skillforge/setup-forge'
 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
 

package/src/workflows/test-skill/data/scoring-rules.md

@@ -17,6 +17,8 @@
 
 ## Naive Mode Weight Redistribution
 
+The following weights replace the default table for naive mode. The 18% coherence weight from the default table has been proportionally redistributed into these values. Do not apply a second redistribution.
+
 When running in naive mode (no coherence category):
 - Export Coverage: 45%
 - Signature Accuracy: 25%
@@ -38,6 +40,7 @@ tessl evaluates SKILL.md body content only — it does not read `references/*.md
 - Signature Accuracy: skipped (no AST)
 - Type Coverage: skipped (no AST)
 - Score based on: structural completeness only
+- Weight redistribution: skipped categories' weights (Signature Accuracy 22% + Type Coverage 14%) redistributed proportionally to remaining active categories
 
 ### Forge Tier (ast-grep)
 - Export Coverage: AST-backed export comparison

package/src/workflows/test-skill/data/source-access-protocol.md

@@ -32,7 +32,7 @@ If no provenance-map.json exists (typical for quick-skill output), fall back to
 If neither provenance-map nor metadata exports provide a usable baseline, but remote reading tools (zread, deepwiki, gh API, or similar) are available and `source_repo` is set in metadata.json, read the entry point remotely to build the export inventory from scratch. Name-matching only — no AST. Set `analysis_confidence: remote-only`.
 
 **State 5 — No source access at all:**
-If none of the above succeed, fall through to docs-only mode (section 0 already handles this). Set `analysis_confidence: docs-only`. Warn: "**No source access available.** Coverage check evaluates documentation self-consistency only. Re-run with local clone or remote access for source-backed verification."
+If none of the above succeed, fall through to docs-only mode (as defined in step-01-init.md Section 0: pre-analysis source type detection). Set `analysis_confidence: docs-only`. Warn: "**No source access available.** Coverage check evaluates documentation self-consistency only. Re-run with local clone or remote access for source-backed verification."
 
 Set `analysis_confidence` in context for use in Section 2 analysis depth, step-05 output, and step-05 scoring.
 

package/src/workflows/test-skill/steps-c/step-01-init.md

@@ -150,6 +150,7 @@ testMode: ''
 forgeTier: '{detected_tier}'
 testResult: ''
 score: ''
+threshold: ''
 analysisConfidence: ''
 testDate: '{current_date}'
 stepsCompleted: ['step-01-init']

package/src/workflows/test-skill/steps-c/step-02-detect-mode.md

@@ -86,6 +86,8 @@ Read the skill metadata (loaded in step 01) and check:
 - Default to **naive mode** (conservative — fewer checks, less chance of false negatives from missing context)
 - Note the default in the report
 
+**Quick-tier adjustment (applies to both modes):** If `forge_tier` is `Quick`, Signature Accuracy and Type Coverage are skipped during scoring (no AST available). Their weights are redistributed proportionally to remaining active categories. See `scoring-rules.md` Tier-Dependent Scoring section for details.
+
 ### 3. Update Output Document
 
 Update `{outputFile}` frontmatter:

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

@@ -2,7 +2,7 @@
 name: test-skill
 description: Cognitive completeness verification. Naive and contextual modes.
 web_bundle: true
-installed_path: '{project-root}/_bmad/skf/workflows/test-skill'
+installed_path: '{project-root}/_bmad/skf/workflows/skillforge/test-skill'
 ---
 
 # Test Skill
@@ -15,7 +15,7 @@ installed_path: '{project-root}/_bmad/skf/workflows/test-skill'
 
 ### Core Principles
 
-- **Micro-file Design**: Each step of the overall goal is a self contained instruction file that you will adhere too 1 file as directed at a time
+- **Micro-file Design**: Each step of the overall goal is a self contained instruction file that you will adhere to 1 file as directed at a time
 - **Just-In-Time Loading**: Only 1 current step file will be loaded, read, and executed to completion - 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
 - **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array

package/src/workflows/update-skill/steps-c/step-02-detect-changes.md

@@ -35,7 +35,7 @@ Compare current source code state against the provenance map to produce a comple
 - 🎯 Focus ONLY on detecting and classifying changes — do not extract or merge
 - 🚫 FORBIDDEN to modify any files — read-only change detection
 - 🚫 FORBIDDEN to re-extract content — that is step 03
-- 💬 Use subprocess optimization Pattern 4 for parallel comparison when available
+- 💬 Use subprocess Pattern 4 (parallel): In Claude Code, use multiple parallel Agent tool calls or `run_in_background: true`. In Cursor, use parallel requests (IDE-dependent). In CLI, use `xargs -P` or background processes. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md)
 - ⚙️ If subprocess unavailable, perform comparison sequentially in main thread
 
 ## EXECUTION PROTOCOLS:
@@ -110,7 +110,7 @@ Launch subprocesses in parallel that compare source state against provenance map
 
 **Category C — Rename detection:**
 - Cross-reference deleted files/exports with added files/exports
-- If content similarity > 80%: classify as RENAMED instead of deleted+added
+- If content similarity > 80%: classify as RENAMED instead of deleted+added. **Similarity mechanism by tier:** Quick: compare file size ratio (within 20%) and export name overlap (>70% of exports match by name). Forge and above: use ast-grep to compare export signatures between the deleted and added files. Forge+/Deep: use CCC semantic similarity when available
 
 **Category D — Script/asset file changes:**
 - Compare `file_entries` from provenance-map.json against current source files
@@ -177,7 +177,7 @@ The skill `{skill_name}` is current — no update needed.
 | Files moved/renamed | {count} |
 | Exports affected | {total_export_changes} |
 
-**Proceeding to re-extraction of {affected_file_count} changed files...**"
+**Proceeding to re-extraction of {affected_file_count if normal mode, or gap_count if gap-driven mode} changes...**"
 
 ### 6. Present MENU OPTIONS
 

package/src/workflows/update-skill/steps-c/step-03-re-extract.md

@@ -4,8 +4,9 @@ description: 'Tier-aware AST extraction on changed files only, producing fresh e
 
 nextStepFile: './step-04-merge.md'
 extractionPatternsData: '../../create-skill/data/extraction-patterns.md'
-tierDegradationRulesData: '../data/tier-degradation-rules.md'
+extractionPatternsTracingData: '../../create-skill/data/extraction-patterns-tracing.md'
 remoteSourceResolutionData: '../data/remote-source-resolution.md'
+tierDegradationRulesData: '../../create-skill/data/tier-degradation-rules.md'
 ---
 
 # Step 3: Re-Extract Changed Exports
@@ -92,12 +93,16 @@ Perform tier-aware extraction on only the changed files identified in step 02, p
 - Extract: parameter types, return types, JSDoc/docstring comments
 - Confidence: T1 (AST-verified structural truth)
 
+**Tier degradation handling (Forge/Forge+/Deep):** If ast-grep is unavailable or fails on individual files, follow `{tierDegradationRulesData}` for fallback strategy and user notification requirements. Silent degradation is forbidden — the user must always know when AST extraction was skipped.
+
 **Deep tier (AST + QMD semantic enrichment):**
 - Perform all Forge tier extractions (T1)
 - Additionally: launch a subprocess that queries qmd_bridge for temporal context on changed exports, returning T2 evidence per export
 - QMD provides: usage patterns, historical context, related documentation
 - Confidence: T1 for structural, T2 for semantic enrichment
 
+**Tool resolution:** `ast_bridge` → ast-grep MCP tools (`find_code`, `find_code_by_rule`) or `ast-grep` CLI. `qmd_bridge` → QMD MCP tools (`mcp__plugin_qmd-plugin_qmd__search`, `vector_search`) or `qmd` CLI. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md).
+
 ### 2. Extract Changed Files
 
 DO NOT BE LAZY — For EACH file in the change manifest with status MODIFIED, ADDED, or RENAMED, launch a subprocess that:
@@ -117,7 +122,7 @@ DO NOT BE LAZY — For EACH file in the change manifest with status MODIFIED, AD
 
 **For MOVED files:** Re-extract at new location to update file:line references.
 
-**Re-export tracing (Forge/Deep only):** After extracting changed files, check if any public exports from the package entry point (`__init__.py`, `index.ts`, `lib.rs`) are unresolved — particularly when a changed file is part of a module re-export chain. Follow the **Re-Export Tracing** protocol in `{extractionPatternsData}` to trace unresolved symbols to their actual definition files.
+**Re-export tracing (Forge/Deep only):** After extracting changed files, check if any public exports from the package entry point (`__init__.py`, `index.ts`, `lib.rs`) are unresolved — particularly when a changed file is part of a module re-export chain. Follow the **Re-Export Tracing** protocol in `{extractionPatternsTracingData}` to trace unresolved symbols to their actual definition files.
 
 ### 2b. CCC Semantic Ranking (Forge+ and Deep with ccc)
 
@@ -125,7 +130,7 @@ DO NOT BE LAZY — For EACH file in the change manifest with status MODIFIED, AD
 
 Before aggregating extraction results, use CCC to assess semantic significance of changes:
 
-1. Run `ccc_bridge.search("{skill_name}", source_root, top_k=15)` to get the skill's most semantically central files
+1. Run `ccc_bridge.search("{skill_name}", source_root, top_k=15)` — **Tool resolution:** `/ccc` skill search (Claude Code), ccc MCP (Cursor), `ccc search` (CLI) — to get the skill's most semantically central files
 2. Cross-reference the change manifest files with CCC results
 3. Files appearing in BOTH the change manifest AND CCC's top results are **semantically significant changes** — flag them for priority in the merge step
 4. Store `{ccc_significant_changes: [{file, score}]}` in context

package/src/workflows/update-skill/steps-c/step-05-validate.md

@@ -33,7 +33,7 @@ Validate the merged skill content against the agentskills.io specification, veri
 
 - 🎯 Focus ONLY on validation — do not fix issues (that's the user's choice)
 - 🚫 FORBIDDEN to modify merged content — validation is read-only
-- 💬 Launch parallel validation checks when subprocess available (Pattern 4)
+- 💬 Launch parallel validation checks when subprocess available (Pattern 4): In Claude Code, use multiple parallel Agent tool calls. In Cursor, use parallel requests (IDE-dependent). In CLI, use `xargs -P`. See [knowledge/tool-resolution.md](../../../knowledge/tool-resolution.md)
 - ⚙️ If subprocess unavailable, perform checks sequentially in main thread
 
 ## EXECUTION PROTOCOLS:
@@ -69,13 +69,9 @@ Run: `npx skill-check -h`
 
 Launch subprocesses in parallel for each validation category, aggregating results when complete:
 
-**Check A — Spec Compliance (via skill-check):**
+**Check A — Spec Compliance (deferred to post-write):**
 
-**If available**, run: `npx skill-check check <skill-dir> --fix --format json --no-security-scan`
-
-Parse JSON output for quality score (0-100), auto-fixed issues, and remaining diagnostics. If `body.max_lines` reported, prefer selective split: extract only the largest Tier 2 section(s) to `references/`, keeping all Tier 1 content inline (selective split preserves agent accuracy — inline passive context achieves 100% task accuracy vs 79% for on-demand retrieval per Vercel research). Fall back to `npx skill-check split-body <skill-dir> --write` only if selective split is not feasible. After any split, verify `#quick-start` and `#key-types` anchors still resolve in SKILL.md.
-
-**If unavailable**, perform manual check: validate merged SKILL.md structure, verify required sections (exports, usage patterns, conventions), verify export entries have name/type/signature/file:line reference, flag missing sections.
+Skill-check requires written files on disk. This check is deferred to step-06 section 7. Perform manual structural check only: verify merged SKILL.md has required sections (exports, usage patterns, conventions), verify export entries have name/type/signature/file:line reference, flag missing sections.
 
 **Check B — [MANUAL] Section Integrity:**
 - Compare [MANUAL] inventory from step 01 against merged content
@@ -84,7 +80,7 @@ Parse JSON output for quality score (0-100), auto-fixed issues, and remaining di
 
 **Check C — Confidence Tier Consistency:**
 - Verify all re-extracted exports have confidence labels (T1/T1-low/T2)
-- Verify tier labels match forge tier: Quick=T1-low only, Forge=T1 (T1-low for degraded), Deep=T1+T2
+- Verify tier labels match forge tier: Quick=T1-low only, Forge=T1 (T1-low for degraded), Forge+=T1 (same as Forge, CCC improves coverage not confidence), Deep=T1+T2
 - Flag mismatched or missing tier labels
 
 **Check D — Provenance Completeness:**
@@ -166,9 +162,9 @@ ONLY WHEN all validation checks have completed and findings are displayed will y
 
 ### ✅ SUCCESS:
 
-- All six checks executed (spec, [MANUAL], confidence, provenance, diff, security)
-- `npx skill-check check --fix` and `diff` executed if available (or fallbacks used)
-- Quality score captured; auto-fix applied for deterministic issues
+- All six checks executed (spec-manual, [MANUAL], confidence, provenance, diff, security)
+- Checks A (spec compliance via skill-check), E (diff), and F (security scan) deferred to post-write in step-06
+- Manual structural check performed for spec compliance in this step
 - Stack skill reference files validated if applicable
 - Findings reported with severity and specific locations; [MANUAL] integrity verified
 - Auto-proceeds regardless of findings (advisory mode)
@@ -177,7 +173,7 @@ ONLY WHEN all validation checks have completed and findings are displayed will y
 
 - Skipping any of the six checks; blocking on validation warnings
 - Not verifying [MANUAL] integrity; hallucinating findings not backed by comparison
-- Modifying merged content during validation (except via skill-check --fix)
+- Modifying merged content during validation (validation is read-only in this step)
 - Not recording quality score when skill-check is available
 
 **Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

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

@@ -74,7 +74,9 @@ Update `{skills_output_folder}/{skill_name}/metadata.json`:
   - `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)
-  - `confidence_t1`, `confidence_t2`, `confidence_t3`: update counts from re-extraction results
+- 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
@@ -154,7 +156,7 @@ For each affected reference file from the merge:
 - Regenerate `context-snippet.md` with updated export summaries
 - Verify [MANUAL] sections preserved in each reference file
 
-**If skill_type != "stack":** Skip with notice.
+**If skill_type != "stack":** Skip reference file updates. However, if exports changed (added, removed, or renamed), warn: "⚠️ `context-snippet.md` was NOT updated — exports have changed. Run **[EX] Export Skill** to regenerate the context snippet and update CLAUDE.md/AGENTS.md."
 
 ### 6. Verify All Writes
 
@@ -182,6 +184,7 @@ External tool checks deferred from step-05 now run against the written files:
 
 **If skill-check available:**
 - Run: `npx skill-check check {skills_output_folder}/{skill_name} --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 {skills_output_folder}/{skill_name} --write` if not feasible. Verify anchors resolve after split.
 - Run: `npx skill-check diff` if original version was preserved
 - Run: `npx skill-check check {skills_output_folder}/{skill_name} --format json` for security scan

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

@@ -2,7 +2,7 @@
 name: update-skill
 description: Smart regeneration preserving [MANUAL] sections. Detects individual vs stack internally.
 web_bundle: true
-installed_path: '{project-root}/_bmad/skf/workflows/update-skill'
+installed_path: '{project-root}/_bmad/skf/workflows/skillforge/update-skill'
 ---
 
 # Update Skill

package/src/workflows/verify-stack/data/coverage-patterns.md

@@ -0,0 +1,45 @@
+# Coverage Patterns
+
+## Purpose
+
+Rules for detecting technology/library references in architecture and PRD documents, and matching them against generated skills.
+
+---
+
+## Technology Detection in Documents
+
+### Direct Name Matching
+
+Search the architecture document for exact mentions of:
+1. Library names from generated skills (case-insensitive)
+2. Common aliases (e.g., "React" also matches "ReactJS", "react.js")
+3. Framework names that encompass libraries (e.g., "Tauri" encompasses the Tauri ecosystem)
+
+### Section-Based Detection
+
+Parse document section headers for technology groupings:
+- `## Desktop App` → technologies listed under this section
+- `## Backend Core` → technologies in backend layer
+- `## AI Layer` → AI-related technologies
+
+**Mermaid Diagram Handling:** Do NOT parse Mermaid diagram syntax (`graph`, `flowchart`, `sequenceDiagram`, etc.) for technology detection. Only use prose text (headings, paragraphs, lists, tables) for detection. If the architecture document appears to list technologies exclusively inside Mermaid diagrams, note this in the coverage results as a detection limitation and recommend the user add prose-based technology listings.
+
+### Coverage Verdict
+
+| Verdict | Meaning |
+|---------|---------|
+| **Covered** | A generated skill exists in `skills/` for this technology |
+| **Missing** | Technology is referenced in architecture doc but no skill exists |
+| **Extra** | A skill exists but the technology is not referenced in the architecture doc (informational, not an error) |
+
+## Output Format
+
+When presenting coverage results, use the following structure:
+
+```
+| Technology | Source Section | Skill Match | Verdict |
+|------------|---------------|-------------|---------|
+| {tech_name} | {section_heading} | {skill_name or '—'} | Covered / Missing |
+```
+
+Include a summary line: `Coverage: {covered_count}/{total_count} ({percentage}%)`

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

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

@@ -0,0 +1,73 @@
+# 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}
+```