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

package/src/skf-create-stack-skill/steps-c/step-09-report.md

@@ -0,0 +1,128 @@
+---
+nextStepFile: './step-10-health-check.md'
+# Resolve `{atomicWriteHelper}` by probing `{atomicWriteProbeOrder}` in order
+# (installed SKF module path first, src/ dev-checkout fallback); first existing
+# path wins. HALT if neither resolves.
+atomicWriteProbeOrder:
+  - '{project-root}/_bmad/skf/shared/scripts/skf-atomic-write.py'
+  - '{project-root}/src/shared/scripts/skf-atomic-write.py'
+---
+
+# Step 9: Stack Skill Report
+
+## STEP GOAL:
+
+Display the final summary of the forged stack skill with confidence distribution, output file listing, and next workflow recommendations.
+
+## Rules
+
+- Do not write or modify any files — report is console output only
+- Lead with the positive summary, then details, then warnings
+- Recommend next workflows based on what was produced
+- Chains to the local health-check step via `{nextStepFile}` after completion — the user-facing report is NOT the terminal step
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
+
+### 1. Display Stack Forged Banner
+
+"**Stack forged: {project_name}-stack — {lib_count} libraries, {integration_count} integration patterns**
+
+Forge tier: **{tier}**"
+
+### 2. Display Confidence Distribution
+
+"**Confidence distribution:**
+
+| Tier | Count | Description |
+|------|-------|-------------|
+| T1 | {count} | AST-verified structural extraction |
+| T1-low | {count} | Source reading inference |
+| T2 | {count} | QMD-enriched temporal context |
+
+{IF compose_mode:}
+*Note: Confidence tiers above are inherited from source skills — they reflect the extraction method used when those skills were originally generated, not the current compose run.*
+{END IF}"
+
+### 3. Display Output File Summary
+
+"**Output files:**
+
+**Deliverables** (`{skill_package}`):
+- SKILL.md — Integration patterns, library summaries, conventions
+- context-snippet.md — Compressed stack index ({token_estimate} tokens)
+- metadata.json — Skill metadata and library registry
+- references/ — {lib_count} per-library reference files
+{If integrations:} - references/integrations/ — {pair_count} integration pair files
+
+**Workspace** (`{forge_version}`):
+- provenance-map.json — Extraction source tracking
+- evidence-report.md — Evidence and confidence breakdown
+
+**Symlink:** `{skill_group}/active` -> `{version}`"
+
+### 4. Display Validation Summary
+
+**If validation passed with no findings:**
+
+"**Validation:** All checks passed"
+
+**If validation had findings:**
+
+"**Validation:** {warning_count} warning(s) found
+{For each finding:}
+- ⚠ {description}"
+
+### 5. Display Warnings (Conditional)
+
+Read from the `workflow_warnings[]` accumulator defined in the Workflow Rules of `SKILL.md` (M4). Every step that emitted a warning during this run pushed a structured entry there — this section is the single sink that surfaces them.
+
+**Only display if `workflow_warnings[]` is non-empty:**
+
+"**Warnings:**
+{For each entry in workflow_warnings[]:}
+- [{step}/{severity}] {code}: {message}"
+
+**If `workflow_warnings[]` is empty:** Skip this section entirely.
+
+### 6. Recommend Next Workflows
+
+"**Next steps:**
+- **[TS] test-skill** — Validate the stack skill against its own assertions
+- **[EX] export-skill** — Package for distribution or agent loading
+
+- **[VS] verify-stack** — Validate the stack's integration feasibility against your architecture document{IF compose_mode:} (re-run to confirm feasibility after any architecture changes from **[RA] refine-architecture**){END IF}"
+
+### 6b. Result Contract
+
+Write the result contract per `shared/references/output-contract-schema.md` using the shared atomic writer. Two artifacts — both written via `skf-atomic-write.py write`:
+
+**Per-run record (inside the version dir):**
+
+```bash
+<json-content> | python3 {atomicWriteHelper} write \
+  --target {forge_version}/create-stack-skill-result-{YYYYMMDD-HHmmss}-{pid}-{rand}.json
+```
+
+- `{YYYYMMDD-HHmmss}` is a UTC timestamp with seconds resolution.
+- Append `-{pid}-{rand}` (process id + short random suffix) to the filename to avoid same-second collisions when multiple runs land in the same second (S16).
+
+**Stable latest pointer (ABOVE the version dir, at the stack group root):**
+
+```bash
+<json-content> | python3 {atomicWriteHelper} write \
+  --target {forge_data_folder}/{project_name}-stack/create-stack-skill-result-latest.json
+```
+
+- Note the path: the `-latest.json` lives at `{forge_data_folder}/{project_name}-stack/` (the stack group root), NOT inside `{forge_version}/`. Pipeline consumers read this stable path without knowing the current version.
+- Write the same JSON body as the timestamped record (this is a copy, not a symlink, so pipeline consumers never chase a link across version boundaries).
+
+Include `SKILL.md`, `context-snippet.md`, and `metadata.json` paths in `outputs`; include `lib_count`, `integration_count`, `forge_tier`, `confidence_tier`, and confidence distribution in `summary`.
+
+If either atomic write fails, log the error, leave any prior `-latest.json` untouched, and continue — the report is advisory and should not block the health-check chain.
+
+### 7. Chain to Health Check
+
+ONLY WHEN the forge banner, confidence distribution, output file summary, validation summary, warnings (if any), next-workflow recommendations, and result contract have all been handled will you then load, read the full file, and execute `{nextStepFile}`. The health-check step is the true terminal step — do not stop here even though the report reads as final.
+

package/src/skf-create-stack-skill/steps-c/step-10-health-check.md

@@ -0,0 +1,22 @@
+---
+# `shared/health-check.md` resolves relative to the SKF module root
+# (`_bmad/skf/` when installed, `src/` during development), NOT relative
+# to this step file.
+nextStepFile: 'shared/health-check.md'
+---
+
+# Step 10: Workflow Health Check
+
+## STEP GOAL:
+
+Chain to the shared workflow self-improvement health check at `{nextStepFile}`. This is the terminal step of create-stack-skill — after the shared health check completes, the workflow is fully done.
+
+## Rules
+
+- No user-facing reports, file writes, or result contracts in this step — those belong in step-09
+- Delegate directly to `{nextStepFile}` with no additional commentary
+- Do not attempt any other action between loading this step and executing `{nextStepFile}`
+
+## MANDATORY SEQUENCE
+
+Load `{nextStepFile}`, read it fully, then execute it.

package/src/skf-drop-skill/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: skf-drop-skill
+description: Drop a specific skill version or an entire skill — soft (deprecate) or hard (purge) with platform context rebuild. Use when the user requests to "drop" or "remove a skill."
+---
+
+# Drop Skill
+
+## Overview
+
+Drops 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. Every destructive action requires explicit user confirmation — nothing is deleted silently. The export manifest is the source of truth; the filesystem is updated to match.
+
+## Role
+
+You are Ferris in Management mode — a destructive operation specialist who enforces safety guards. You treat every drop as potentially irreversible and require explicit confirmation before touching the manifest or filesystem. You protect the active version, keep the export manifest consistent with on-disk state, and ensure downstream platform context files are rebuilt.
+
+## Workflow Rules
+
+These rules apply to every step in this workflow:
+
+- 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
+- Read each step file completely before taking any action
+- Follow the mandatory sequence in each step exactly — do not skip, reorder, or optimize
+- Only load one step file at a time — never preload future steps
+- If any instruction references a subprocess or tool you lack, achieve the outcome in your main context thread
+- Always communicate in `{communication_language}`
+- If `{headless_mode}` is true, auto-proceed through confirmation gates with their default action and log each auto-decision
+
+## Stages
+
+| # | Step | File | Auto-proceed |
+|---|------|------|--------------|
+| 1 | Select Target | steps-c/step-01-select.md | No (confirm) |
+| 2 | Execute Drop | steps-c/step-02-execute.md | Yes |
+| 3 | Report | steps-c/step-03-report.md | Yes |
+| 4 | Workflow Health Check | steps-c/step-04-health-check.md | Yes |
+
+## Invocation Contract
+
+| Aspect | Detail |
+|--------|--------|
+| **Inputs** | skill_name [required], mode (deprecate/purge) [required], version (all/specific) [required] |
+| **Gates** | step-01: Input Gate [use args], Confirm Gate [Y] |
+| **Outputs** | Updated manifest, rebuilt context files, (purge: deleted directories) |
+| **Headless** | All gates auto-resolve with default action when `{headless_mode}` is true |
+
+## On Activation
+
+1. Load 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`
+   - `snippet_skill_root_override` (optional string) — when set, the context-file rebuild in step-02 preserves any snippet `root:` prefix that matches the override instead of rewriting it to the target IDE's skill root. See `skf-export-skill/assets/managed-section-format.md` for full semantics.
+   - Generate and store `timestamp` as `YYYYMMDD-HHmmss` format. This value is fixed for the entire workflow run.
+
+2. **Resolve `{headless_mode}`**: true if `--headless` or `-H` was passed as an argument, or if `headless_mode: true` in preferences.yaml. Default: false.
+
+3. Load, read the full file, and then execute `./steps-c/step-01-select.md` to begin the workflow.

package/src/{workflows/drop-skill → skf-drop-skill}/steps-c/step-01-select.md

@@ -1,8 +1,6 @@
 ---
-name: 'step-01-select'
-description: 'Select skill, version(s), and drop mode (deprecate/purge)'
 nextStepFile: './step-02-execute.md'
-versionPathsKnowledge: '../../../knowledge/version-paths.md'
+versionPathsKnowledge: 'knowledge/version-paths.md'
 ---
 
 # Step 1: Select Drop Target
@@ -11,45 +9,12 @@ versionPathsKnowledge: '../../../knowledge/version-paths.md'
 
 Identify exactly what the user wants to drop — which skill, which version(s), and whether the drop is a soft deprecation (manifest-only) or a hard purge (files deleted). Enforce the active version guard, gather the list of affected directories, and obtain explicit user confirmation before any write or delete operation is scheduled.
 
-## MANDATORY EXECUTION RULES (READ FIRST):
+## Rules
 
-### Universal Rules:
-
-- 🛑 NEVER schedule a destructive operation without explicit user confirmation
-- 📖 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 Ferris in Management mode — a destructive operation specialist
-- ✅ Safety first, confirmation required
-- ✅ You protect the active version and enforce the active version guard
-- ✅ You treat every drop as potentially irreversible — soft drops are recoverable, hard drops are not
-
-### Step-Specific Rules:
-
-- 🎯 Focus only on selection, validation, and confirmation
-- 🚫 FORBIDDEN to proceed without explicit user confirmation at the final gate
-- 🚫 FORBIDDEN to modify the manifest or delete any files in this step — execution happens in step-02
-- 🚫 FORBIDDEN to drop an active version when other non-deprecated versions exist
-- 💬 Present selections clearly so the user can verify scope, mode, and blast radius before committing
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Load version-paths knowledge and the export manifest (if present) alongside an on-disk skill scan
-- 💾 Gather all selection decisions into context for step-02
-- 📖 Show version lists, statuses, and directory paths clearly so the user understands what will be affected
-- 🚫 Halt only if neither the manifest nor an on-disk scan yields any skill — a missing manifest is not fatal for purge mode because draft skills (created but never exported) can still be legitimately hard-dropped from disk
-
-## CONTEXT BOUNDARIES:
-
-- Available: Export manifest v2, SKF module config variables, on-disk skill directory listing
-- Focus: Selection, validation, and user confirmation
-- Limits: Do not write to the manifest, do not delete any files — execution is deferred to step-02
-- Dependencies: At least one skill must exist in either the export manifest or on disk under `{skills_output_folder}/`; otherwise the workflow halts. Draft skills (on disk but not in the manifest) are eligible for purge mode only
+- Focus only on selection, validation, and confirmation — do not modify the manifest or delete files
+- Do not proceed without explicit user confirmation at the final gate
+- Do not drop an active version when other non-deprecated versions exist
+- Present selections clearly so the user can verify scope, mode, and blast radius
 
 ## MANDATORY SEQUENCE
 
@@ -110,7 +75,7 @@ Available skills:
 "**Which skill would you like to drop?**
 Enter the skill name or its number from the list above."
 
-Wait for user input. Accept either the numeric index or the skill name (exact match).
+Wait for user input. Accept either the numeric index or the skill name (exact match). **GATE [default: use args]** — If `{headless_mode}` and skill name was provided as argument: select that skill and auto-proceed. If not provided, HALT: "headless mode requires skill name argument."
 
 **If the user's input does not match any listed skill:** Re-display the list and ask again.
 
@@ -244,6 +209,8 @@ Display the full operation summary:
 Proceed? [Y/N]
 ```
 
+**GATE [default: Y]** — If `{headless_mode}`: auto-proceed with [Y], log: "headless: auto-confirmed drop of {target_skill}"
+
 Wait for explicit user response.
 
 - **If `Y`** → proceed to section 11
@@ -269,30 +236,3 @@ Load, read the full file, and then execute `{nextStepFile}`.
 
 ONLY WHEN the user has confirmed with `Y` at the confirmation gate AND all selection decisions have been stored in context, will you then load and read fully `{nextStepFile}` to execute the drop.
 
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Version-paths knowledge loaded and applied via templates (no hardcoded paths)
-- Export manifest read if present; on-disk scan augments the list; halt only if both are empty
-- Complete skill and version list displayed with statuses, active marker, and on-disk-only entries flagged "(not in manifest — purge only)"
-- Skill, version(s), and mode selected by explicit user input; mode forced to purge for not-in-manifest skills
-- Active version guard enforced for manifest-tracked skills — refused to drop an active version with surviving non-deprecated peers
-- Affected directories computed from templates
-- Explicit user confirmation (`Y`) received at the confirmation gate
-- All selection decisions stored in context for step-02 (including `target_in_manifest`)
-
-### ❌ SYSTEM FAILURE:
-
-- Proceeding without reading version-paths knowledge
-- Halting when the manifest is missing but on-disk skills exist — the fallback scan MUST be attempted before any "nothing to drop" halt
-- Offering soft-deprecate for a skill that has no manifest entry
-- Hardcoding directory paths instead of using `{skill_package}`, `{skill_group}`, `{forge_version}`, `{forge_group}` templates
-- Allowing a drop of the active version when other non-deprecated versions exist
-- Modifying the manifest or deleting files in this step (execution belongs to step-02)
-- Skipping the confirmation gate or proceeding on any response other than `Y`
-- Not storing decisions in context for step-02
-
-**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE. No destructive action proceeds without explicit user confirmation.

package/src/{workflows/drop-skill → skf-drop-skill}/steps-c/step-02-execute.md

@@ -1,9 +1,7 @@
 ---
-name: 'step-02-execute'
-description: 'Execute the drop operation — update manifest, rebuild context files, delete files if purge'
 nextStepFile: './step-03-report.md'
-versionPathsKnowledge: '../../../knowledge/version-paths.md'
-managedSectionLogic: '../../export-skill/data/managed-section-format.md'
+versionPathsKnowledge: 'knowledge/version-paths.md'
+managedSectionLogic: 'skf-export-skill/assets/managed-section-format.md'
 ---
 
 # Step 2: Execute Drop
@@ -12,45 +10,12 @@ managedSectionLogic: '../../export-skill/data/managed-section-format.md'
 
 Execute the drop decisions recorded in step-01: update the export manifest, rebuild platform context files so dropped versions disappear from managed sections, and (in purge mode) delete the affected directories from disk. Record everything that was changed for the final report in step-03.
 
-## MANDATORY EXECUTION RULES (READ FIRST):
+## Rules
 
-### Universal Rules:
-
-- 🛑 NEVER modify content outside `<!-- SKF:BEGIN/END -->` markers in platform context files
-- 🛑 NEVER delete files outside the `affected_directories` list from step-01
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: When loading next step, 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 Ferris in Management mode — a destructive operation specialist
-- ✅ Execute only the decisions confirmed in step-01 — no scope expansion, no "while I'm at it" extras
-- ✅ Surgical precision: preserve all content outside `<!-- SKF:BEGIN/END -->` markers
-- ✅ Manifest and filesystem must end in a consistent state
-
-### Step-Specific Rules:
-
-- 🎯 Focus only on manifest update, context rebuild, and (in purge mode) file deletion
-- 🚫 FORBIDDEN to re-prompt the user — decisions were made in step-01
-- 🚫 FORBIDDEN to delete files in deprecate mode
-- 🚫 FORBIDDEN to widen the deletion scope beyond `affected_directories`
-- 💬 Report each stage's outcome as it completes so the user sees progress
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Re-read version-paths knowledge to avoid drift between step files
-- 💾 Persist the manifest update before touching platform context files
-- 📖 Rebuild managed sections from the updated manifest, not from memory
-- 🚫 If any stage fails, halt and report which stage failed with recovery guidance
-
-## CONTEXT BOUNDARIES:
-
-- Available: Decisions from step-01 (`target_skill`, `target_versions`, `drop_mode`, `is_skill_level`, `affected_directories`), SKF module config, version-paths knowledge, managed-section format
-- Focus: Manifest mutation, context rebuild, filesystem deletion (purge only)
-- Limits: Only modify content between `<!-- SKF:BEGIN/END -->` markers; only delete directories enumerated in `affected_directories`
-- Dependencies: Step-01 must have completed and stored all decisions in context
+- Focus only on manifest update, context rebuild, and (in purge mode) file deletion
+- Do not re-prompt the user — decisions were made in step-01
+- Do not delete files in deprecate mode; do not widen deletion scope beyond `affected_directories`
+- Report each stage's outcome as it completes
 
 ## MANDATORY SEQUENCE
 
@@ -76,7 +41,7 @@ For each version in `target_versions`:
 
 1. Navigate to `exports.{target_skill}.versions.{version}`
 2. Set `status = "deprecated"`
-3. Leave `platforms`, `last_exported`, and all other fields unchanged
+3. Leave `ides`, `last_exported`, and all other fields unchanged
 
 Do NOT change `active_version` on the skill entry in this pass — if the dropped version was the active one (only reachable when it was the sole non-deprecated version per the step-01 guard), the active_version field will still point at it, but every consumer excludes deprecated versions from exports.
 
@@ -95,33 +60,27 @@ Set context flag `manifest_updated = true`.
 - Report: "**Manifest update failed:** {error}. No files were deleted and platform context files were not rebuilt. The manifest is in its pre-drop state — rerun the workflow once the underlying issue is resolved."
 - Store `manifest_updated = false` and jump to section 6
 
-### 3. Rebuild Platform Context Files
-
-Load the `ides` list from `config.yaml`. The installer writes installer-specific IDE identifiers (e.g. `claude-code`, `github-copilot`, `codex`, `cline`, `roo`, `windsurf`, `cursor`, `other`), NOT platform values — these must be mapped to platforms before any target-file lookup.
+### 3. Rebuild Context Files
 
-**Resolve `target_platforms`** using the "IDE → Platform Mapping" table in `{managedSectionLogic}`:
+Load the `ides` list from `config.yaml`. The installer writes IDE identifiers — these must be mapped to context files and skill roots using the "IDE → Context File Mapping" table in `{managedSectionLogic}`.
 
-1. For each entry in `config.yaml.ides`, look up its platform value (`claude-code` → `claude`, `github-copilot` → `copilot`, `codex`/`cline`/`roo`/`windsurf`/`other` → `copilot`, `cursor` → `cursor`)
-2. For any entry not found in the table, default to `copilot` and emit a warning: "Unknown IDE '{value}' in config.yaml — defaulting to copilot"
-3. Deduplicate the resulting platform list (e.g. both `codex` and `cline` collapse to a single `copilot` entry)
-4. If `config.yaml.ides` is absent or the mapping yields an empty list, fall back to `["copilot"]` and emit a note: "No IDEs configured in config.yaml — defaulting to copilot (AGENTS.md)"
+**Resolve `target_context_files`** using the canonical mapping table in `{managedSectionLogic}`:
 
-Store the result as `target_platforms` for this section.
+1. For each entry in `config.yaml.ides`, look up its `context_file` and `skill_root` from the mapping table
+2. For any entry not found in the table, default to AGENTS.md / `.agents/skills/` and emit a warning: "Unknown IDE '{value}' in config.yaml — defaulting to AGENTS.md"
+3. Deduplicate by `context_file` — when multiple IDEs map to the same context file, use the first configured IDE's `skill_root`
+4. If `config.yaml.ides` is absent or the mapping yields an empty list, fall back to `[{context_file: "AGENTS.md", skill_root: ".agents/skills/"}]` and emit a note: "No IDEs configured in config.yaml — defaulting to AGENTS.md"
 
-For each platform in `target_platforms`:
+Store the result as `target_context_files` for this section.
 
-1. **Resolve target file** using the "Platform Target Files" table in `{managedSectionLogic}`:
+For each entry in `target_context_files`:
 
-   | Platform | Target File |
-   |----------|-------------|
-   | `claude` | `{project-root}/CLAUDE.md` |
-   | `cursor` | `{project-root}/.cursorrules` |
-   | `copilot` | `{project-root}/AGENTS.md` |
+1. **Resolve target file** at `{context_file}`.
 
 2. **Read the current file.**
-   - If the file does not exist, skip this platform (nothing to rebuild — the file will be re-created next time export-skill runs)
-   - If the file exists but contains no `<!-- SKF:BEGIN -->` marker, skip this platform (no managed section to rewrite)
-   - If the file contains `<!-- SKF:BEGIN -->` but no matching `<!-- SKF:END -->`, record the error against that platform and continue to the next IDE — do not halt the entire drop on a malformed context file. The manifest has already been updated in section 2 and is canonical state; the platform file can be repaired manually and rebuilt on the next `[EX] Export Skill` run.
+   - If the file does not exist, skip this context file (nothing to rebuild — the file will be re-created next time export-skill runs)
+   - If the file exists but contains no `<!-- SKF:BEGIN -->` marker, skip this context file (no managed section to rewrite)
+   - If the file contains `<!-- SKF:BEGIN -->` but no matching `<!-- SKF:END -->`, record the error against that context file and continue to the next entry — do not halt the entire drop on a malformed context file. The manifest has already been updated in section 2 and is canonical state; the context file can be repaired manually and rebuilt on the next `[EX] Export Skill` run.
 
 3. **Build the exported skill set (version-aware, deprecated-excluded)** using the same logic as export-skill step-04 section 4b:
    - Read the manifest's `exports` object (already updated in section 2)
@@ -134,15 +93,9 @@ For each platform in `target_platforms`:
    - If the file is missing, fall back to the `active` symlink path, then skip with a warning if still not found
    - Collect successful snippets into the skill index
 
-5. **Rewrite root paths for the current platform** using export-skill step-04 section 4d logic:
+5. **Rewrite root paths for the current context file** using the generic rewrite algorithm from export-skill step-04 section 4d:
 
-   | Platform | Root Path Prefix |
-   |----------|-----------------|
-   | `claude` | `.claude/skills/` |
-   | `cursor` | `.cursor/skills/` |
-   | `copilot` | `.agents/skills/` |
-
-   For each snippet, detect its current `root:` prefix and rewrite it to the current platform's prefix if different.
+   For each snippet, parse the `root:` line (`root: {prefix}{skill-name}/`), strip the trailing `{skill-name}/` to extract the current prefix, and replace it with the current entry's `skill_root` if different. **Override guard:** If `snippet_skill_root_override` is set in config.yaml AND the extracted prefix equals the override value, skip the rewrite — leave the root path untouched. See `skf-export-skill/steps-c/step-04-update-context.md` §4d for full semantics.
 
 6. **Sort skills alphabetically by name.** Count totals (skills, stack skills).
 
@@ -176,9 +129,9 @@ For each platform in `target_platforms`:
    - Confirm `{target_skill}` (at the dropped version, or at all versions if skill-level) no longer appears between the markers
    - Confirm content outside the markers is byte-identical to what was preserved
 
-10. **On per-file failure:** record the error against that platform and continue to the next IDE. Do not halt — other platforms should still be rebuilt.
+10. **On per-file failure:** record the error against that context file and continue to the next entry. Do not halt — other context files should still be rebuilt.
 
-**After the loop,** record `platform_files_updated` as the list of files that were successfully rewritten, and `platform_files_failed` as the list of any that failed.
+**After the loop,** record `context_files_updated` as the list of files that were successfully rewritten, and `context_files_failed` as the list of any that failed.
 
 Report: "**Rebuilt managed sections in:** {list of updated files}. {if any failed: 'Failed: {list}'}"
 
@@ -223,7 +176,7 @@ Run these verification checks:
    - Version-level drop: `exports.{target_skill}.versions.{version}.status == "deprecated"`
    - Skill-level drop: `exports.{target_skill}` is absent
 
-2. **Platform files check:** For each file in `platform_files_updated`, spot-check that the dropped skill/version is no longer referenced between the markers.
+2. **Context files check:** For each file in `context_files_updated`, spot-check that the dropped skill/version is no longer referenced between the markers.
 
 3. **Purge check (purge mode only):** For each path in `files_deleted`, confirm it no longer exists on disk.
 
@@ -236,8 +189,8 @@ Store the following for step-03:
 - `files_deleted` — list of directory paths actually deleted (purge mode) or `[]` (soft drop)
 - `disk_freed` — human-readable size (purge mode) or `"N/A (soft drop)"`
 - `manifest_updated` — boolean (true if section 2 succeeded)
-- `platform_files_updated` — list of successfully rebuilt files
-- `platform_files_failed` — list of files that failed to rebuild (empty if none)
+- `context_files_updated` — list of successfully rebuilt files
+- `context_files_failed` — list of files that failed to rebuild (empty if none)
 - `verification_errors` — list of verification failures (empty if none)
 
 ### 7. Load Next Step
@@ -251,40 +204,11 @@ If any stage fails, record which stage failed and provide recovery guidance in t
 | Failed Stage | Recovery Guidance |
 |--------------|-------------------|
 | Manifest update | "Manifest is in pre-drop state. Re-run the workflow once the underlying I/O issue is resolved. No files were deleted." |
-| Platform rebuild | "Manifest is already updated. Re-run `[EX] Export Skill` against any still-valid skill to regenerate the affected managed sections, or rerun the drop workflow." |
-| File deletion (purge) | "Manifest and platform files are consistent. Remaining directories listed in the report can be deleted manually: `rm -rf {path}`." |
+| Context file rebuild | "Manifest is already updated. Re-run `[EX] Export Skill` against any still-valid skill to regenerate the affected managed sections, or rerun the drop workflow." |
+| File deletion (purge) | "Manifest and context files are consistent. Remaining directories listed in the report can be deleted manually: `rm -rf {path}`." |
 | Verification | "Execution completed but post-write checks found drift. See the report for specific paths requiring manual review." |
 
 ## CRITICAL STEP COMPLETION NOTE
 
 ONLY WHEN all execution stages have been attempted (manifest update, context rebuild, file deletion in purge mode, verification) and results have been stored in context, will you then load and read fully `{nextStepFile}` to generate the final report.
 
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Version-paths knowledge and managed-section format re-read at the start of the step
-- Export manifest updated correctly (deprecated status for version-level, skill removal for skill-level)
-- Platform context files rebuilt for all configured IDEs using the same logic as export-skill step-04 (sections 4b–5), with surgical replacement preserving all content outside markers
-- Deprecated versions no longer appear in any managed section
-- Purge mode: all directories in `affected_directories` deleted with size accounting; `active` symlink updated or removed as appropriate
-- Soft drop: no files deleted; `files_deleted` is empty and `disk_freed` is `"N/A (soft drop)"`
-- Verification checks executed on manifest, platform files, and (if purge) deleted paths
-- All results stored in context for step-03
-- Errors at any stage are recorded with recovery guidance rather than silently swallowed
-
-### ❌ SYSTEM FAILURE:
-
-- Deleting files in soft drop mode
-- Deleting directories outside the `affected_directories` list
-- Modifying content outside `<!-- SKF:BEGIN/END -->` markers
-- Rebuilding managed sections from memory instead of the updated manifest
-- Including deprecated versions in the rebuilt skill index
-- Not updating the `active` symlink after a version-level purge when the dropped version was the target
-- Not verifying the final state
-- Hardcoding paths instead of using `{skill_package}`, `{skill_group}`, `{forge_version}`, `{forge_group}` templates
-- Halting the entire workflow on a recoverable per-platform error instead of continuing and reporting
-
-**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE. The manifest and the filesystem must end in a consistent state, and every destructive action must trace back to a decision made in step-01.

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

@@ -0,0 +1,83 @@
+---
+nextStepFile: './step-04-health-check.md'
+---
+
+# 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.
+
+## Rules
+
+- Focus only on reporting results stored in context by step-02 — do not re-execute any part of the drop
+- Do not hide verification errors or failed context file rebuilds
+- Chains to the local health-check step via `{nextStepFile}` after completion — the user-facing report is NOT the terminal step
+
+## 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}
+- Context files rebuilt: {list from context_files_updated, or "(none)"}
+{if context_files_failed is non-empty:}
+- Context files FAILED: {list from context_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.
+```
+
+### Result Contract
+
+Write the result contract per `shared/references/output-contract-schema.md`: the per-run record at `{skills_output_folder}/drop-skill-result-{YYYYMMDD-HHmmss}.json` (UTC timestamp, resolution to seconds) and a copy at `{skills_output_folder}/drop-skill-result-latest.json` (stable path for pipeline consumers — copy, not symlink). Include all purged file paths in `outputs`; include `target_skill`, `drop_mode`, and `versions_affected` in `summary`.
+
+### 3. Chain to Health Check
+
+ONLY WHEN the report has been rendered and the result contract saved will you then load, read the full file, and execute `{nextStepFile}`. The health-check step is the true terminal step — do not stop here even though the report reads as final.
+
+## CRITICAL STEP COMPLETION NOTE
+
+This step chains to the local health-check step (`{nextStepFile}`), which in turn delegates to `shared/health-check.md`. After the health check completes, the drop-skill workflow is fully done. Do not re-run any earlier step automatically — if the user wants another drop, they should re-invoke the workflow from the top.
+

package/src/skf-drop-skill/steps-c/step-04-health-check.md

@@ -0,0 +1,22 @@
+---
+# `shared/health-check.md` resolves relative to the SKF module root
+# (`_bmad/skf/` when installed, `src/` during development), NOT relative
+# to this step file.
+nextStepFile: 'shared/health-check.md'
+---
+
+# Step 4: Workflow Health Check
+
+## STEP GOAL:
+
+Chain to the shared workflow self-improvement health check at `{nextStepFile}`. This is the terminal step of drop-skill — after the shared health check completes, the workflow is fully done.
+
+## Rules
+
+- No user-facing reports, file writes, or result contracts in this step — those belong in step-03
+- Delegate directly to `{nextStepFile}` with no additional commentary
+- Do not attempt any other action between loading this step and executing `{nextStepFile}`
+
+## MANDATORY SEQUENCE
+
+Load `{nextStepFile}`, read it fully, then execute it.