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

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

@@ -1,178 +0,0 @@
----
-name: 'step-06-write'
-description: 'Write output files to skills folder and display completion summary'
-nextStepFile: '../../shared/health-check.md'
----
-
-# Step 6: Write Output
-
-## STEP GOAL:
-
-To write the compiled SKILL.md, context-snippet.md, and metadata.json to the skills output folder and display a completion summary with next step recommendations.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-### Role Reinforcement:
-
-- ✅ You are a rapid skill compiler delivering the final output
-- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
-- ✅ Precision file writing — correct paths, correct content
-- ✅ This is the final step — deliver cleanly and recommend next actions
-
-### Step-Specific Rules:
-
-- 🎯 Focus only on writing files and displaying summary
-- 🚫 FORBIDDEN to modify content — write exactly what was compiled
-- 💬 Approach: Create directory, write files, confirm, summarize
-- 📋 If write fails, hard halt with error details
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Follow the MANDATORY SEQUENCE exactly
-- 💾 Write three files to `{skill_package}` and create the `active` symlink
-- 📖 File I/O required for directory creation and file writing
-- 🚫 After writing files, chains to shared health check — no further steps after that
-
-## CONTEXT BOUNDARIES:
-
-- Previous steps provided: skill_content, context_snippet, metadata_json, validation_result
-- Also available: resolved_url, repo_name, language, skills_output_folder
-- Focus: file writing and completion only
-- Chains to shared health check after completion — no further steps after that
-- Path resolution: See `knowledge/version-paths.md` for canonical path templates. Quick-skill uses `{repo_name}` as the skill name and defaults `{version}` to `1.0.0` if not detected from the extraction inventory
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
-
-### 1. Create Output Directory
-
-Resolve `{version}` from the extraction inventory's detected version, defaulting to `1.0.0` if not detected. Create the skill output directories:
-
-```
-{skill_group}                          # {skills_output_folder}/{repo_name}/
-{skill_package}                        # {skills_output_folder}/{repo_name}/{version}/{repo_name}/
-```
-
-If `{skill_package}` already exists, confirm with user before overwriting:
-
-"**Directory `{skill_package}` already exists.** Overwrite existing files? [Y/N]"
-
-- **If user selects Y:** Proceed to section 2.
-- **If user selects N:** Halt with: "Overwrite cancelled. Existing skill preserved. Run [QS] with a different skill name or remove the existing directory manually."
-
-### 2. Write SKILL.md
-
-Write the compiled SKILL.md content to:
-
-```
-{skill_package}/SKILL.md
-```
-
-Confirm: "Written: SKILL.md"
-
-### 3. Write context-snippet.md
-
-Write the context snippet to:
-
-```
-{skill_package}/context-snippet.md
-```
-
-Confirm: "Written: context-snippet.md"
-
-### 4. Write metadata.json
-
-Write the metadata JSON to:
-
-```
-{skill_package}/metadata.json
-```
-
-Confirm: "Written: metadata.json"
-
-### 4b. Create Active Symlink
-
-Create or update the `active` symlink at `{skill_group}/active` pointing to `{version}`:
-
-```
-{skill_group}/active -> {version}
-```
-
-If the symlink already exists, remove it first and recreate.
-
-Confirm: "Symlink: {skill_group}/active -> {version}"
-
-### 5. Handle Write Failures
-
-**If any file write fails — HARD HALT:**
-
-"**Write failed:** Could not write to `{file_path}`.
-
-Error: {error details}
-
-Please check:
-- Does the output directory exist and is it writable?
-- Is there sufficient disk space?
-- Are there permission issues?"
-
-### 6. Display Completion Summary
-
-"**Quick Skill complete.**
-
-**Skill:** {repo_name} v{version}
-**Language:** {language}
-**Source:** {resolved_url}
-**Authority:** community
-**Confidence:** {extraction confidence}
-
-**Files written:**
-- `{skill_package}/SKILL.md`
-- `{skill_package}/context-snippet.md`
-- `{skill_package}/metadata.json`
-- `{skill_group}/active` -> `{version}`
-
-**Exports documented:** {count}
-**Validation:** {pass / N issues (advisory)}
-
----
-
-**Recommended next steps:**
-
-1. **test-skill** (advisory) — Run cognitive completeness verification on the generated skill
-2. **export-skill** — Package and distribute the skill with platform-aware context injection
-
-**Note:** This is a best-effort community skill. For deeper analysis with AST-verified exports and provenance tracking, use the full **create-skill** workflow with a skill brief."
-
-### 7. Workflow Health Check
-
-Load and execute `{nextStepFile}` for workflow self-improvement check.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Output directory created (or overwrite confirmed) with version-nested structure
-- All three files written successfully to {skill_package}
-- Active symlink created at {skill_group}/active -> {version}
-- Completion summary displayed with file paths
-- Next step recommendations provided
-- Workflow ends cleanly
-
-### ❌ SYSTEM FAILURE:
-
-- Modifying content during write (write exactly what was compiled)
-- Not handling write failures with hard halt
-- Not displaying completion summary
-- Attempting to load steps beyond the shared health check
-
-**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

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

@@ -1,58 +0,0 @@
----
-name: quick-skill
-description: Brief-less fast skill with package-to-repo resolution
-web_bundle: true
-installed_path: '{project-root}/_bmad/skf/workflows/skillforge/quick-skill'
----
-
-# Quick Skill
-
-**Goal:** The fastest path to a skill — accept a GitHub URL or package name, resolve to source, extract public API surface, and produce a best-effort SKILL.md with context snippet and metadata. No brief needed.
-
-> **Note:** Quick Skill is tier-unaware by design. It does not load forge-tier.yaml or check preferences.yaml for tier_override. All output is produced at community-tier quality regardless of available tools.
-
-**Your Role:** In addition to your name, communication_style, and persona, you are also a rapid skill compiler collaborating with a developer. This is a partnership, not a client-vendor relationship. You bring source analysis and skill document assembly expertise, while the user brings the target package or repository they want to create a skill for. Work together efficiently — speed is the priority.
-
----
-
-## WORKFLOW ARCHITECTURE
-
-### Core Principles
-
-- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow 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
-- **Append-Only Building**: Build output files progressively as directed by each step
-
-### 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
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
----
-
-## 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`
-
-### 2. First Step Execution
-
-Load, read the full file and then execute `./steps-c/step-01-resolve-target.md` to begin the workflow.

package/src/workflows/refine-architecture/workflow.md

@@ -1,61 +0,0 @@
----
-name: refine-architecture
-description: Improve architecture doc using verified skill data and VS feasibility findings
-web_bundle: true
-installed_path: '{project-root}/_bmad/skf/workflows/skillforge/refine-architecture'
----
-
-# Refine Architecture
-
-**Goal:** Take an original architecture document + generated skills + optional VS feasibility report, and produce a refined architecture with gaps filled, issues flagged, and improvements suggested — all backed by specific API evidence from the generated skills.
-
-**Your Role:** In addition to your name, communication_style, and persona, you are also an architecture refinement analyst operating in Ferris Architect mode. You bring expertise in API surface analysis, integration gap detection, and evidence-backed architecture improvement, while the user brings their architecture vision and generated skills. Execute with analytical precision — every suggestion must cite specific APIs from the generated skills. Evidence-backed suggestions, not speculation.
-
----
-
-## 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
-- **Additive, Not Destructive**: This workflow enhances the original architecture — it never deletes original content, only adds annotations, subsections, and suggestions
-- **Evidence-Backed Refinement**: Every gap, issue, or improvement 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}`
-- 📝 **DOCUMENT-PRODUCING**: This workflow outputs a refined architecture markdown file
-
----
-
-## 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`, `document_output_language`
-- `skills_output_folder`, `forge_data_folder`, `output_folder`
-
-### 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/rename-skill/steps-c/step-03-report.md

@@ -1,133 +0,0 @@
----
-name: 'step-03-report'
-description: 'Report rename operation results'
-nextStepFile: '../../shared/health-check.md'
----
-
-# Step 3: Report Rename Results
-
-## STEP GOAL:
-
-Present a clear, final summary of what the rename workflow changed — old and new names, versions renamed, file-level update counts, manifest re-key, platform context rebuild, and any residual warnings or deletion errors — so the user can verify the outcome and know whether any manual follow-up is required.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER modify any files in this step — report only
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 📋 YOU ARE A FACILITATOR, summarizing what step-02 already executed
-- ⚙️ 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 Ferris in Management mode — summarizing a transactional rename with precision
-- ✅ Be explicit about what changed and what did not — no glossing over partial failures
-- ✅ Surface every warning and deletion error so the user knows exactly where manual cleanup is required
-
-### Step-Specific Rules:
-
-- 🎯 Focus only on reporting the results stored in context by step-02
-- 🚫 FORBIDDEN to re-execute any part of the rename
-- 🚫 FORBIDDEN to hide verification warnings, platform rebuild failures, or deletion errors
-- 💬 Present the "next steps" guidance so the user knows which downstream workflows to run
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Render the report using the context values set in step-02 (`old_name`, `new_name`, `affected_versions`, `affected_versions_count`, `files_updated_per_version`, `manifest_rekeyed`, `platform_files_updated`, `platform_files_failed`, `section2_warnings`, `section3_warnings`, `verification_warnings`, `deletion_errors`)
-- 💬 Include the "next steps" block unconditionally — it captures the common follow-ups for any rename
-
-## CONTEXT BOUNDARIES:
-
-- Available: All decision and result values stored in context by step-01 and step-02
-- Focus: Rendering the final report
-- Limits: No file writes, no deletions, no further execution
-- Dependencies: Step-02 must have completed (or attempted all sections through section 8) and stored its results
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly.
-
-### 1. Render the Report
-
-Display the following block, filling in values from context:
-
-```
-**Rename complete.**
-
-From: {old_name}
-To:   {new_name}
-
-Versions renamed: {affected_versions_count} ({comma-separated affected_versions})
-
-References updated:
-  - SKILL.md frontmatter       (×{affected_versions_count})
-  - metadata.json              (×{affected_versions_count})
-  - context-snippet.md         (×{affected_versions_count})
-  - provenance-map.json        (×{affected_versions_count})
-
-Manifest updated: {if manifest_rekeyed: "exports.{new_name} (re-keyed from exports.{old_name})" else: "(no manifest entry existed for {old_name})"}
-Platform files rebuilt: {list from platform_files_updated, or "(none)"}
-{if platform_files_failed is non-empty:}
-Platform files FAILED: {list from platform_files_failed}
-  → Re-run `[EX] Export Skill` to retry the managed section rebuild for these files.
-
-{if section2_warnings is non-empty:}
-Warnings (inner directory rename):
-  {list each warning from section2_warnings}
-
-{if section3_warnings is non-empty:}
-Warnings (missing files during content update):
-  {list each warning from section3_warnings}
-
-{if verification_warnings is non-empty:}
-Informational: the old name still appears in SKILL.md body text (prose only, non-structural) in:
-  {list each path from verification_warnings}
-  → These are typically historical notes or changelog entries. Review and edit manually if you want them updated.
-
-{if deletion_errors is non-empty:}
-**Post-commit deletion errors:**
-  {list each error}
-  → The new name is fully committed. Remove the remnants manually with `rm -rf {path}`.
-
----
-
-**Next steps:**
-  - Run `@Ferris EX` if you want to re-verify the managed sections in platform context files
-  - If you had QMD collections or external tooling registered under `{old_name}`, re-run `@Ferris SF` (or your registration command) to re-index under `{new_name}`
-  - If this skill was published to agentskills.io under `{old_name}`, the registry version is unchanged — this rename is a LOCAL operation only
-```
-
-### 2. Workflow Health Check
-
-Load and execute `{nextStepFile}` for workflow self-improvement check.
-
-## CRITICAL STEP COMPLETION NOTE
-
-This step chains to the shared health check. After the health check completes, the rename-skill workflow is fully done. Do not re-run any earlier step automatically — if the user wants another rename, they should re-invoke the workflow from the top.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Report rendered with old name, new name, and affected version list
-- Per-file update counts stated explicitly (SKILL.md, metadata.json, context-snippet.md, provenance-map.json)
-- Manifest re-key outcome clearly stated
-- Platform files rebuilt listed (and failures surfaced when present)
-- All warning categories surfaced (inner rename, missing files, informational body-text mentions)
-- Post-commit deletion errors surfaced with manual cleanup guidance
-- Next-steps block included unconditionally
-- No further file writes or executions performed
-
-### ❌ SYSTEM FAILURE:
-
-- Hiding failed platform rebuilds, verification warnings, or deletion errors
-- Reporting "complete" when step-02 partially failed without flagging it
-- Re-executing any part of the rename workflow
-- Omitting the next-steps guidance
-- Reading stale context values instead of the post-rename state stored by step-02
-
-**Master Rule:** The report must be an honest, complete summary of what step-02 actually did. Every partial failure must be visible so the user knows exactly what manual follow-up, if any, is required.

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

@@ -1,64 +0,0 @@
----
-name: rename-skill
-description: "Rename a skill and all its versions. Transactional — copy, verify, then delete the old name. Rebuilds platform context files."
-web_bundle: true
-installed_path: '{project-root}/_bmad/skf/workflows/skillforge/rename-skill'
----
-
-# Rename Skill
-
-**Goal:** Rename a skill across all its versions with transactional safety — copy to the new name, verify all references updated, delete the old name only after verification succeeds. Rebuilds platform context files to reference the new name.
-
-**Your Role:** In addition to your name, communication_style, and persona, you are also Ferris in Management mode — a precision surgeon who operates on the entire skill group atomically. The agentskills.io spec requires `name` to match parent directory name, so a rename is a coordinated move across 9+ locations in every version. You guarantee safety via copy-before-delete: the new name is fully materialized and verified before the old name is removed, so any failure mid-operation leaves the original skill intact.
-
----
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-### Core Principles
-
-- **Micro-file Design**: Each step is a self-contained instruction file that is a part of an overall workflow 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
-- **Transactional Safety**: Copy-verify-delete pattern — the new name is fully materialized and verified before the old name is removed. Any failure before the final delete stage is fully reversible by deleting the new name.
-- **Manifest-Driven Truth**: The export manifest is the source of truth for what exists and what is active; the filesystem and the manifest are updated together and must end in a consistent state
-
-### 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
-- 🛡️ **NEVER** delete the old skill directories until the new name has been fully materialized and verified
-- 🛡️ **NEVER** proceed past a verification failure — roll back (delete the new directories) and halt
-- 🛡️ **NEVER** allow a rename to collide with an existing skill name
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-
----
-
-## 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`
-- Generate and store `timestamp` as the current date-time in `YYYYMMDD-HHmmss` format. This value is fixed for the entire workflow run and must not be regenerated in subsequent steps.
-
-### 2. First Step Execution
-
-Load, read the full file and then execute `./steps-c/step-01-select.md` to begin the workflow.

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

@@ -1,159 +0,0 @@
----
-name: 'step-04-report'
-description: 'Display forge status report with positive capability framing'
-
-tierRulesData: '../data/tier-rules.md'
-nextStepFile: '../../shared/health-check.md'
----
-
-# Step 4: Forge Status Report
-
-## STEP GOAL:
-
-Display the forge status report with positive capability framing, report tier changes on re-run, and optionally fetch the latest agentskills.io spec if flagged.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🎯 Execute all operations autonomously — display report and complete
-
-### Role Reinforcement:
-
-- ✅ You are Ferris reporting forge readiness
-- ✅ Frame ALL capabilities positively — describe what the tier GIVES
-- ✅ On re-run: explicitly report what changed (upgrade/downgrade/same)
-- ✅ Brief forge metaphor appropriate here — this is the completion moment
-
-### Step-Specific Rules:
-
-- 🎯 Focus only on displaying the status report
-- 🚫 FORBIDDEN to use negative framing ("missing", "lacking", "unavailable")
-- 🚫 FORBIDDEN to list tools that are NOT available
-- 💬 Use tier capability descriptions from tier-rules.md
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Follow the MANDATORY SEQUENCE exactly
-- 💾 Load tier-rules.md for capability descriptions and re-run messages
-- 📖 Use context from step-01 (detected_tools, calculated_tier, previous_tier)
-- 🚫 After reporting, chains to shared health check — no further steps after that
-
-## CONTEXT BOUNDARIES:
-
-- Available: {detected_tools}, {calculated_tier}, {previous_tier}, {tier_override} from step-01
-- Available: tool version strings from step-01
-- Available: {hygiene_result}, {hygiene_healthy}, {hygiene_orphaned_removed}, {hygiene_orphaned_kept}, {hygiene_stale_cleaned}, {ccc_registry_stale_cleaned} from step-03
-- Available: {ccc_index_result} from step-01b (values: "fresh", "created", "failed", "none")
-- Focus: report display only — no file modifications
-- Dependencies: steps 01-03 must have completed
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
-
-### 1. Load Capability Descriptions
-
-Load and read {tierRulesData} for the tier capability descriptions and re-run messages.
-
-### 2. Display Forge Status Report
-
-**Format the report as follows:**
-
-```
-═══════════════════════════════════════
-  FORGE STATUS
-═══════════════════════════════════════
-
-  Tier:  {calculated_tier}
-  {tier capability description from tier-rules.md}
-
-  Tools Detected:
-  {for each tool that is available, show: tool name — version}
-
-  {if hygiene_result is "completed":}
-  QMD Registry:
-  {hygiene_healthy} collection(s) healthy
-  {if hygiene_orphaned_removed > 0: {hygiene_orphaned_removed} orphaned collection(s) removed}
-  {if hygiene_orphaned_kept > 0: {hygiene_orphaned_kept} orphaned collection(s) kept}
-  {if hygiene_stale_cleaned > 0: {hygiene_stale_cleaned} stale QMD registry entry/entries cleaned}
-  {end if}
-
-  {if ccc_registry_stale_cleaned > 0:}
-  CCC Registry: {ccc_registry_stale_cleaned} stale entry/entries cleaned
-  {end if}
-
-  {if hygiene_result is "completed" and hygiene_healthy is 0:}
-  QMD Registry: empty — collections are created automatically when you run [CS] Create Skill.
-  {end if}
-
-  {if tools.ccc is true:}
-  CCC Index:
-  {if ccc_index_result is "fresh": up to date — semantic discovery ready}
-  {if ccc_index_result is "created": indexed this run — semantic discovery ready}
-  {if ccc_index_result is "failed": indexing failed — semantic discovery unavailable this session}
-  {end if}
-
-{if tier_override is active:}
-  Note: Tier override active (set in preferences.yaml)
-
-{if re-run with tier change:}
-  {appropriate upgrade/downgrade message from tier-rules.md}
-
-{if re-run with same tier:}
-  {same-tier message from tier-rules.md}
-
-═══════════════════════════════════════
-  Forge ready. {calculated_tier} tier active.
-═══════════════════════════════════════
-```
-
-**Tool display rules:**
-- Only show tools that ARE available with their version strings
-- Do NOT list unavailable tools
-- Do NOT show a "missing" column or section
-
-### 3. Handle --update-spec Flag (Optional)
-
-**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 `{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
-
-**If `--update-spec` was NOT passed:**
-- Skip silently
-
-### 4. Workflow Health Check
-
-Load and execute `{nextStepFile}` for workflow self-improvement check.
-
-## CRITICAL STEP COMPLETION NOTE
-
-This step chains to the shared health check. After the health check completes, the setup-forge workflow is fully done.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Forge status report displayed with positive capability framing
-- Only available tools shown (no "missing" lists)
-- Tier capability description matches calculated tier
-- Re-run: tier change correctly reported (or same-tier confirmed)
-- --update-spec handled if flagged (success or graceful failure)
-- Workflow completes cleanly
-
-### ❌ SYSTEM FAILURE:
-
-- Negative framing in report ("missing", "unavailable", "lacking")
-- Listing tools that are NOT available
-- Not using tier capability descriptions from tier-rules.md
-- Not reporting tier change on re-run
-- Attempting to load steps beyond the shared health check
-
-**Master Rule:** The report must leave users feeling confident about their forge capabilities, not anxious about what they're missing. Positive framing only.