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

package/src/workflows/drop-skill/steps-c/step-03-report.md

@@ -1,135 +0,0 @@
----
-name: 'step-03-report'
-description: 'Report drop operation results'
----
-
-# Step 3: Report Drop Results
-
-## STEP GOAL:
-
-Present a clear, final summary of what the drop workflow changed — manifest state, platform context files, deleted directories, disk freed, and remaining versions — 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 destructive operation with precision
-- ✅ Be explicit about what changed and what did not — no glossing over partial failures
-- ✅ Surface recovery guidance when any stage in step-02 reported an error
-
-### Step-Specific Rules:
-
-- 🎯 Focus only on reporting the results stored in context by step-02
-- 🚫 FORBIDDEN to re-execute any part of the drop
-- 🚫 FORBIDDEN to hide verification errors or failed platform rebuilds
-- 💬 Present the final state clearly, including remaining versions for the affected skill
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Render the report using the context values set in step-02 (`target_skill`, `target_versions`, `drop_mode`, `is_skill_level`, `files_deleted`, `disk_freed`, `manifest_updated`, `platform_files_updated`, `platform_files_failed`, `verification_errors`)
-- 📖 For the "remaining versions" section, re-read `{skills_output_folder}/.export-manifest.json` (already updated by step-02) to show the current state
-- 💬 Include the reversibility note only when `drop_mode == "deprecate"`
-
-## CONTEXT BOUNDARIES:
-
-- Available: All decision and result values stored in context by step-01 and step-02, plus the updated export manifest on disk
-- Focus: Rendering the final report
-- Limits: No file writes, no deletions, no further execution
-- Dependencies: Step-02 must have completed (or attempted all stages) and stored its results
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly.
-
-### 1. Determine Remaining Versions
-
-**If `is_skill_level == true`:**
-
-Set `remaining_versions_display = "(skill fully removed)"`.
-
-**If `is_skill_level == false`:**
-
-Read `{skills_output_folder}/.export-manifest.json` and look up `exports.{target_skill}.versions`. Build a human-readable list of every remaining version with its status, with the active one marked:
-
-```
-  - 0.1.0 (deprecated)
-  - 0.5.0 (archived)
-  - 0.6.0 (active) *
-```
-
-### 2. Render the Report
-
-Display the following block, filling in values from context:
-
-```
-**Drop operation complete.**
-
-Operation:     {Deprecate | Purge}
-Skill:         {target_skill}
-Version(s):    {comma-separated target_versions or "ALL"}
-
-Changes:
-- Manifest updated:      {yes | no}
-- 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}
-{if drop_mode == "purge":}
-- Files deleted:         {list from files_deleted, or "(none — nothing on disk)"}
-- Disk space freed:      {disk_freed}
-
-Remaining versions for {target_skill}:
-{remaining_versions_display}
-
-{if drop_mode == "deprecate":}
-**Note:** Files remain on disk. This operation is reversible by manually editing
-`{skills_output_folder}/.export-manifest.json` and changing the version's `status`
-field back to `"active"` or `"archived"`, then re-running `[EX] Export Skill` to
-restore the managed section entry.
-
-{if verification_errors is non-empty:}
-**Verification warnings:**
-{list each verification error}
-These require manual review — see the error-handling guidance in step-02.
-```
-
-### 3. Close the Workflow
-
-After rendering the report, the workflow is complete. Do not load any further step file — there is no `nextStepFile`.
-
-## CRITICAL STEP COMPLETION NOTE
-
-This is the final step. Once the report has been rendered, the drop-skill workflow is finished. Do not re-run any earlier step automatically — if the user wants another drop, they should re-invoke the workflow from the top.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Report rendered with operation type, skill, version(s), and mode
-- Manifest update outcome clearly stated (yes/no)
-- Platform files rebuilt listed (and failures surfaced when present)
-- Purge mode: files deleted and disk freed reported
-- Soft drop: reversibility note included with concrete instructions
-- Remaining versions for the affected skill accurately listed from the updated manifest (or "(skill fully removed)" for skill-level drops)
-- Verification warnings surfaced, not hidden
-- No further file writes or executions performed
-
-### ❌ SYSTEM FAILURE:
-
-- Hiding failed platform rebuilds or verification errors
-- Reporting "complete" when step-02 partially failed without flagging it
-- Reading stale manifest data instead of the post-drop state
-- Re-executing any part of the drop workflow
-- Omitting the reversibility note in soft drop mode
-- Displaying remaining versions from memory rather than from the updated manifest
-
-**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/drop-skill/workflow.md

@@ -1,63 +0,0 @@
----
-name: drop-skill
-description: "Drop (deprecate or purge) skill versions. Soft drop keeps files; hard drop deletes them. Active version guarded."
-web_bundle: true
-installed_path: '{project-root}/_bmad/skf/workflows/skillforge/drop-skill'
----
-
-# Drop Skill
-
-**Goal:** Drop a specific skill version or an entire skill, either as a soft deprecation (manifest-only, files retained) or a hard purge (files deleted). Ensures platform context files are rebuilt to exclude dropped versions.
-
-**Your Role:** In addition to your name, communication_style, and persona, you are also Ferris in Delivery/Management mode — a destructive operation specialist who enforces safety guards. You treat every drop as potentially irreversible and require explicit user confirmation before touching the manifest or the filesystem. You protect the active version, keep the export manifest consistent with on-disk state, and ensure that downstream platform context files (CLAUDE.md / AGENTS.md / .cursorrules) are rebuilt so dropped versions disappear cleanly.
-
----
-
-## 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
-- **Safety-First Destruction**: Every destructive action is preceded by an explicit user confirmation gate; nothing is deleted silently
-- **Manifest-Driven Truth**: The export manifest is the source of truth for what exists and what is active; the filesystem is updated to match
-
-### 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 files without explicit user confirmation in purge mode
-- 🛡️ **NEVER** drop an active version when other non-deprecated versions exist — enforce the active version guard
-- ✅ 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/export-skill/data/managed-section-format.md

@@ -1,103 +0,0 @@
-# Managed Section Format (ADR-J)
-
-## Marker Format
-
-```markdown
-<!-- SKF:BEGIN updated:{YYYY-MM-DD} -->
-[SKF Skills]|{n} skills|{m} stack
-|IMPORTANT: Prefer documented APIs over training data.
-|When using a listed library, read its SKILL.md before writing code.
-|
-|{skill-snippet-1}
-|
-|{skill-snippet-2}
-<!-- SKF:END -->
-```
-
-## Platform Target Files
-
-| Platform | Flag Value | Target File |
-|----------|-----------|-------------|
-| Copilot | `copilot` (default) | AGENTS.md |
-| Claude | `claude` | CLAUDE.md |
-| Cursor | `cursor` | .cursorrules |
-
-## IDE → Platform Mapping (config.yaml `ides` list)
-
-The installer writes installer-specific IDE identifiers to `config.yaml` under the `ides` key (not platform values). Any workflow that rebuilds platform context files from `config.yaml` MUST map each entry to a platform before looking up its target file.
-
-| config.yaml IDE value | Platform | Target File | Rationale |
-|----------------------|----------|-------------|-----------|
-| `claude-code` | `claude` | CLAUDE.md | native — reads `CLAUDE.md` and `.claude/skills/` |
-| `cursor` | `cursor` | .cursorrules | native — reads `.cursorrules` and `.cursor/skills/` |
-| `github-copilot` | `copilot` | AGENTS.md | native — reads `AGENTS.md` and `.agents/skills/` |
-| `codex` | `copilot` | AGENTS.md | OpenAI Codex reads `AGENTS.md` (same convention as copilot) |
-| `cline` | `copilot` | AGENTS.md | uses `AGENTS.md` as fallback context file |
-| `roo` | `copilot` | AGENTS.md | uses `AGENTS.md` as fallback context file |
-| `windsurf` | `copilot` | AGENTS.md | uses `AGENTS.md` as fallback context file |
-| `other` | `copilot` | AGENTS.md | generic AGENTS.md fallback |
-| _(any unknown value)_ | `copilot` | AGENTS.md | warn: "Unknown IDE '{value}' in config.yaml — defaulting to copilot" |
-
-**Deduplication:** When multiple IDE entries map to the same platform (e.g. `codex` and `cline` both → `copilot`), deduplicate so each platform is processed exactly once. Report the deduplication to the user.
-
-**Missing `ides` key:** If the `ides` key is absent from `config.yaml`, treat it as an empty list. If the resulting platform set is empty (no recognized entries), fall back to `["copilot"]`.
-
-This mapping is the single source of truth. Workflows that need it: `export-skill/step-01` (resolves `target_platforms` for the export), `drop-skill/step-02` and `rename-skill/step-02` (rebuild platform context files after a management operation).
-
-## Four-Case Logic
-
-### Case 1: Create (No File Exists)
-
-Target file does not exist. Create new file with managed section only.
-
-```markdown
-<!-- SKF:BEGIN updated:{date} -->
-{managed section content}
-<!-- SKF:END -->
-```
-
-### Case 2: Append (File Exists, No Section)
-
-Target file exists but contains no `<!-- SKF:BEGIN` marker. Append managed section at end of file.
-
-1. Read existing file content
-2. Append two blank lines
-3. Append managed section with markers
-4. Write file
-
-### Case 3: Regenerate (Existing Section)
-
-Target file contains `<!-- SKF:BEGIN` and `<!-- SKF:END -->` markers. Replace content between markers.
-
-1. Read existing file content
-2. Find `<!-- SKF:BEGIN` line (preserve everything before it)
-3. Find `<!-- SKF:END -->` line (preserve everything after it)
-4. Replace everything between markers (inclusive) with new managed section
-5. Write file
-
-### Case 4: Malformed Markers (Halt)
-
-Target file contains `<!-- SKF:BEGIN` but no matching `<!-- SKF:END -->` marker. This indicates a corrupted managed section.
-
-1. Halt workflow with error: "Malformed managed section — `<!-- SKF:BEGIN` found but no `<!-- SKF:END -->`. Fix the markers manually before re-running export."
-2. Do not modify the file
-
-## Regeneration: Full Index Rebuild
-
-When regenerating (Case 3) or creating/appending (Cases 1-2), rebuild the skill index from the **exported skill set** only:
-
-1. Read `{skills_output_folder}/.export-manifest.json` (v2 schema — see [knowledge/version-paths.md](../../../knowledge/version-paths.md)) to determine which skills have been explicitly exported and their `active_version` (if no manifest exists, only the current export target qualifies)
-2. For each skill in the exported set, resolve the snippet at `{skills_output_folder}/{skill-name}/{active_version}/{skill-name}/context-snippet.md` (i.e., `{skill_package}/context-snippet.md`). Do NOT use glob patterns across version directories — always resolve via manifest `active_version` or `active` symlink
-3. Count total skills and stack skills (from filtered set only)
-4. Assemble filtered snippets into managed section
-5. Sort alphabetically by skill name
-6. Update the header line with correct counts
-
-**Rationale:** create-skill and update-skill also write `context-snippet.md` as a build artifact, but only export-skill is the publishing gate (ADR-K). The `.export-manifest.json` file tracks which skills have passed through export-skill, preventing draft skills from leaking into the agent's passive context.
-
-## Safety Rules
-
-- NEVER modify content outside the `<!-- SKF:BEGIN/END -->` markers
-- ALWAYS preserve existing file content above and below markers
-- ALWAYS verify file was written correctly after write
-- If write fails, report error — do not attempt partial writes

package/src/workflows/export-skill/steps-c/step-01-load-skill.md

@@ -1,237 +0,0 @@
----
-name: 'step-01-load-skill'
-description: 'Load skill artifacts and validate spec compliance before export'
-
-nextStepFile: './step-02-package.md'
----
-
-# Step 1: Load Skill
-
-## STEP GOAL:
-
-To load the target skill's artifacts, validate they meet agentskills.io spec compliance, parse export flags, and confirm with the user before proceeding to packaging.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER proceed without user confirmation of the loaded skill
-- 📖 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 delivery and packaging specialist in Ferris Delivery mode
-- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
-- ✅ Precise and efficient — validate thoroughly, report clearly
-- ✅ User brings the skill path and export preferences
-
-### Step-Specific Rules:
-
-- 🎯 Focus only on loading, validating, and confirming the skill
-- 🚫 FORBIDDEN to modify any skill files — this is read-only
-- 🚫 FORBIDDEN to write any output files yet — packaging starts in step-02
-- 💬 Present a clear summary of what was found for user confirmation
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Follow the MANDATORY SEQUENCE exactly
-- 💾 Hold all loaded data in context for subsequent steps
-- 📖 Validate against agentskills.io spec requirements
-- 🚫 Hard halt if required files are missing — do not proceed with incomplete skill
-
-## CONTEXT BOUNDARIES:
-
-- Available: SKF module config (skills_output_folder, forge_data_folder)
-- Focus: Skill discovery, loading, and validation
-- Limits: Read-only — no file writes in this step
-- Dependencies: Skill must have been created by create-skill or update-skill
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
-
-### 1. Parse Export Arguments
-
-"**Starting skill export...**"
-
-Determine the skill to export and any flags:
-
-**Skill Path Discovery (version-aware — see [knowledge/version-paths.md](../../../knowledge/version-paths.md)):**
-- If user provided a skill name or path as argument, use that
-- If not provided, discover available skills using the export manifest:
-  1. Read `{skills_output_folder}/.export-manifest.json` — list skill names from `exports`
-  2. For each skill group directory in `{skills_output_folder}/`, check for `{skill_group}/active/{skill-name}/SKILL.md`
-  3. If neither manifest nor `active` symlink yields results, fall back to flat path: `{skills_output_folder}/{skill-name}/SKILL.md`
-- If multiple skills found, present list and ask user to select
-- If no skills found, halt: "No skills found in {skills_output_folder}/. Run create-skill first."
-
-**Flag Parsing:**
-- `--platform` flag: Check if explicitly provided (claude/cursor/copilot)
-- `--dry-run` flag: Check if provided. Default: `false`
-
-**Platform Resolution:**
-
-If `--platform` is explicitly provided, use that single platform as the sole target. If other IDEs are configured in config.yaml, emit a note: "**Note:** Exporting to {platform} only. config.yaml also lists: {other-ides}. Run without `--platform` to export to all configured IDEs."
-
-If `--platform` is NOT provided, read the `ides` list from config.yaml and map each IDE to a target platform. Every IDE the installer offers has an explicit mapping — no silent skips.
-
-| config.yaml IDE value | Platform | Rationale |
-|----------------------|----------|-----------|
-| `claude-code` | `claude` | native — reads `CLAUDE.md` and `.claude/skills/` |
-| `cursor` | `cursor` | native — reads `.cursorrules` and `.cursor/skills/` |
-| `github-copilot` | `copilot` | native — reads `AGENTS.md` and `.agents/skills/` |
-| `codex` | `copilot` | OpenAI Codex reads `AGENTS.md` (same convention as copilot) |
-| `cline` | `copilot` | uses `AGENTS.md` as a fallback context file |
-| `roo` | `copilot` | uses `AGENTS.md` as a fallback context file |
-| `windsurf` | `copilot` | uses `AGENTS.md` as a fallback context file |
-| `other` | `copilot` | generic AGENTS.md fallback |
-| Any other value | `copilot` | warn: "Unknown IDE '{value}' in config.yaml — defaulting to copilot (AGENTS.md)" |
-
-When the same platform is produced by multiple IDE entries (e.g. both `codex` and `cline` map to `copilot`), deduplicate so each platform appears in `target_platforms` only once. Report the deduplication: "Multiple IDEs target the same platform — exporting to {platform} once."
-
-**Missing-key handling:** If the `ides` key is absent from config.yaml (older installation or manually edited file), treat it as an empty list.
-
-- If mapping produces one or more platforms (after dedup), store as `target_platforms` list
-- If mapping produces zero platforms (empty ides list and no recognized entries), fall back to `["copilot"]` with note: "No IDEs configured in config.yaml — defaulting to copilot (AGENTS.md / .agents/skills/)."
-
-"**Skill:** {skill-name}
-**Platform(s):** {platform-list} ({target-file-list})
-**Dry Run:** {yes/no}"
-
-### 2. Load and Validate Skill Artifacts
-
-Resolve the skill's versioned path before loading artifacts:
-
-1. Read `{skills_output_folder}/.export-manifest.json` and look up `{skill-name}` in `exports` to get `active_version`
-2. If found: resolve to `{skill_package}` = `{skills_output_folder}/{skill-name}/{active_version}/{skill-name}/`
-3. If not in manifest: check for `active` symlink at `{skills_output_folder}/{skill-name}/active` — resolve to `{skill_group}/active/{skill-name}/`
-4. If neither: fall back to flat path `{skills_output_folder}/{skill-name}/`. If SKILL.md exists at the flat path, auto-migrate per `knowledge/version-paths.md` migration rules
-5. Store the resolved path as `{resolved_skill_package}` for all subsequent artifact loading
-
-Load all files from `{resolved_skill_package}`:
-
-**Required Files (hard halt if missing):**
-- `SKILL.md` — The main skill document
-- `metadata.json` — Machine-readable skill metadata
-
-**Optional Files (note presence):**
-- `references/` — Progressive disclosure directory
-- `context-snippet.md` — Existing snippet (will be regenerated)
-
-**Validation Checks:**
-1. `SKILL.md` exists and is non-empty
-2. `metadata.json` exists and is valid JSON
-3. `metadata.json` contains required fields: `name`, `version`, `skill_type`, `source_authority`, `exports`, `generation_date`, `confidence_tier`
-4. `metadata.json.exports` is a non-empty array (warn if empty — graceful handling)
-
-**If any required validation fails:**
-"**Export cannot proceed.** Missing or invalid: {list failures}
-Run create-skill to generate a complete skill first."
-
-### 3. Read Skill Metadata
-
-Extract from `metadata.json`:
-- `name` — Skill display name
-- `skill_type` — `single` or `stack`
-- `source_authority` — `official`, `internal`, or `community`
-- `exports` — Array of exported functions/types
-- `generation_date` — When the skill was last generated
-- `confidence_tier` — Quick/Forge/Forge+/Deep
-
-**For stack skills, also extract:**
-- `components` — Array of dependencies with versions
-- `integrations` — Array of co-import patterns
-
-### 4. Check Forge Configuration
-
-Load `{sidecar_path}/preferences.yaml` (if exists):
-- Check `passive_context` setting
-- If `passive_context: false` — note that steps 03-04 (snippet + context update) will be skipped
-
-### 4b. Check Test Report (Quality Gate)
-
-Search for a test report at `{forge_data_folder}/{skill_name}/{active_version}/test-report-{skill_name}.md` (i.e., `{forge_version}/test-report-{skill_name}.md`). If not found at the versioned path, fall back to `{forge_data_folder}/{skill_name}/test-report-{skill_name}.md`:
-
-**If test report found:**
-- Read frontmatter `testResult` and `score`
-- If `testResult: fail`: warn: "**Warning:** This skill failed its last test (score: {score}%). Consider running `@Ferris TS` and addressing gaps before export."
-- If `testResult: pass`: note: "Last test: **PASS** ({score}%)"
-
-**If no test report found:**
-- Warn: "**Note:** No test report found for this skill. Consider running `@Ferris TS` before export to verify completeness."
-
-Continue to step 5 regardless — this is advisory, not blocking.
-
-### 5. Present Skill Summary
-
-"**Skill loaded and validated.**
-
-| Field | Value |
-|-------|-------|
-| **Name** | {name} |
-| **Type** | {skill_type} |
-| **Authority** | {source_authority} |
-| **Confidence** | {confidence_tier} |
-| **Exports** | {count} functions/types |
-| **Generated** | {generation_date} |
-| **References** | {count files or 'none'} |
-
-**Export Configuration:**
-| Setting | Value |
-|---------|-------|
-| **Platform(s)** | {platform-list} → {target-file-list} |
-| **Explicit --platform** | {yes (user-specified) / no (from config.yaml)} |
-| **Dry Run** | {yes/no} |
-| **Passive Context** | {enabled/disabled} |
-
-**Top Exports:**
-{list top 5 exports from metadata}
-
-**Is this the correct skill to export?**"
-
-### 6. Present MENU OPTIONS
-
-Display: "**Select:** [C] Continue to packaging"
-
-#### Menu Handling Logic:
-
-- IF C: Proceed with loaded skill data, then load, read entire file, then execute {nextStepFile}
-- IF Any other: help user respond, then [Redisplay Menu Options](#6-present-menu-options)
-
-#### EXECUTION RULES:
-
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-
-## CRITICAL STEP COMPLETION NOTE
-
-ONLY WHEN the user confirms the correct skill is loaded by selecting 'C' will you load and read fully `{nextStepFile}` to execute packaging.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Skill path resolved (from argument or discovery)
-- All required files loaded and validated
-- metadata.json parsed with required fields
-- Export flags parsed (platform, dry-run)
-- config.yaml ides list consumed for multi-platform resolution when --platform not provided
-- Forge config checked for passive_context
-- Clear summary presented to user
-- User confirms correct skill
-
-### ❌ SYSTEM FAILURE:
-
-- Proceeding without finding SKILL.md or metadata.json
-- Not validating metadata.json fields
-- Not checking preferences.yaml for passive_context opt-out
-- Proceeding without user confirmation
-- Ignoring config.yaml ides list when no --platform flag is provided
-- Modifying any skill files (read-only step)
-
-**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

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

@@ -1,58 +0,0 @@
----
-name: export-skill
-description: Package for distribution + platform-aware context injection
-web_bundle: true
-installed_path: '{project-root}/_bmad/skf/workflows/skillforge/export-skill'
----
-
-# Export Skill
-
-**Goal:** Package a completed skill as an agentskills.io-compliant package, generate context snippets, and update the managed section in CLAUDE.md/.cursorrules/AGENTS.md for platform-aware context injection.
-
-**Your Role:** In addition to your name, communication_style, and persona, you are also a delivery and packaging specialist collaborating with a skill developer. This is a partnership, not a client-vendor relationship. You bring expertise in skill packaging, ecosystem compliance, and context injection patterns, while the user brings their completed skill and distribution requirements. Work together as equals.
-
-**Meta-Context:** This workflow is the sole publishing gate for skills (ADR-K). Create-skill and update-skill produce draft artifacts — only export-skill writes to CLAUDE.md/AGENTS.md and prepares packages for distribution. This prevents half-baked snippets from entering the agent's passive context.
-
----
-
-## WORKFLOW ARCHITECTURE
-
-### Core Principles
-
-- **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
-- **Action-Based Output**: This workflow performs file operations (writes, updates) rather than building a progressive document
-
-### 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`, `sidecar_path`
-
-### 2. First Step Execution
-
-Load, read the full file and then execute `./steps-c/step-01-load-skill.md` to begin the workflow.