bmad-module-skill-forge 0.6.0 → 0.7.0

package/src/workflows/update-skill/data/tier-degradation-rules.md

@@ -1,46 +0,0 @@
-# Tier Degradation Rules
-
-## Remote Source at Forge/Deep Tier
-
-When `source_repo` is a remote URL (GitHub URL or owner/repo format) and the tier is Forge or Deep:
-
-- **ast-grep requires local files** — it cannot operate on remote URLs
-
-**Ephemeral clone strategy (preferred):**
-
-1. Check `git` availability (`git --version`). `git` is effectively guaranteed at Deep tier (via `gh` dependency) but NOT guaranteed at Forge tier.
-2. If `git` is available: perform an ephemeral shallow clone to a system temp path (`{system_temp}/skf-ephemeral-{skill-name}-{timestamp}/`).
-3. For create-skill: use `--depth 1 --single-branch --filter=blob:none`; if `include_patterns` are specified, apply mode selection: if `exclude_patterns` are absent, use cone mode (convert include_patterns to directory roots; use `--skip-checks` for individual file paths); if `exclude_patterns` are present, use `--no-cone` mode (pass gitignore-style patterns with `!`-prefixed excludes — includes first, then negations). See source-resolution-protocols.md for the full conversion rules.
-4. For update-skill: use sparse-checkout with `--skip-checks` scoped to the changed files from the change manifest only (file paths require `--skip-checks`). No `--branch` flag — uses the remote default branch (must match the branch used during original create-skill run).
-5. If clone succeeds: use the local clone path for AST extraction. All results are T1 with `[AST:...]` citations.
-6. Cleanup: delete the temp directory after extraction inventory is built and all data is in context. The clone never persists beyond the extraction step.
-
-**Fallback (clone fails or `git` unavailable):**
-
-- The extraction step MUST warn the user explicitly before degrading
-- **create-skill:** Warning must include actionable guidance — clone locally and update `source_repo` in the brief to the local path
-- **update-skill:** Warning must include actionable guidance — clone locally, re-run [CS] Create Skill with the local path to regenerate provenance data, then re-run the update
-- Extraction proceeds using Quick tier strategy (source reading via gh_bridge)
-- All results labeled T1-low with `[SRC:...]` citations
-- The degradation reason is recorded in the evidence report
-
-Silent degradation is **forbidden**. The user must always know when AST extraction was skipped and why.
-
-## AST Tool Unavailable at Forge/Deep Tier
-
-When the tier is Forge or Deep but ast-grep is not functional:
-
-- The extraction step MUST warn the user explicitly before degrading
-- Warning must include actionable guidance: run [SF] Setup Forge to detect tools
-- Extraction proceeds using Quick tier strategy
-- All results labeled T1-low
-- The degradation reason is recorded in the evidence report
-
-## Per-File AST Failure
-
-When ast-grep fails on an individual file (parse error, unsupported syntax):
-
-- Fall back to source reading for **that file only**
-- Other files continue with AST extraction
-- The affected file's results are labeled T1-low; unaffected files retain T1
-- Log a warning noting which file degraded and why

package/src/workflows/update-skill/validation-report.md

@@ -1,559 +0,0 @@
----
-validationDate: 2026-02-27
-workflowName: update-skill
-workflowPath: _bmad-output/bmb-creations/workflows/update-skill
-validationStatus: COMPLETE
-completionDate: 2026-02-27
----
-
-# Validation Report: update-skill
-
-**Validation Started:** 2026-02-27
-**Validator:** BMAD Workflow Validation System
-**Standards Version:** BMAD Workflow Standards
-
----
-
-## File Structure & Size
-
-### Folder Structure
-
-```
-update-skill/
-├── workflow.md                          (56 lines)
-├── workflow-plan-update-skill.md        (plan file)
-├── data/
-│   ├── manual-section-rules.md          (44 lines)
-│   └── merge-conflict-rules.md          (62 lines)
-└── steps-c/
-    ├── step-01-init.md                  (208 lines)
-    ├── step-02-detect-changes.md        (183 lines)
-    ├── step-03-re-extract.md            (187 lines)
-    ├── step-04-merge.md                 (230 lines)
-    ├── step-05-validate.md              (187 lines)
-    ├── step-06-write.md                 (204 lines)
-    └── step-07-report.md                (201 lines)
-```
-
-### Structure Assessment
-
-- workflow.md exists: PASS
-- Step files in organized steps-c/ folder: PASS
-- Reference data in data/ folder: PASS
-- Folder names logical: PASS
-- No stray files: PASS
-
-### File Size Analysis
-
-| File | Lines | Status |
-|------|-------|--------|
-| step-01-init.md | 208 | ⚠️ Approaching limit (200-250) |
-| step-02-detect-changes.md | 183 | ✅ Good |
-| step-03-re-extract.md | 187 | ✅ Good |
-| step-04-merge.md | 230 | ⚠️ Approaching limit (200-250) |
-| step-05-validate.md | 187 | ✅ Good |
-| step-06-write.md | 204 | ⚠️ Approaching limit (200-250) |
-| step-07-report.md | 201 | ⚠️ Approaching limit (200-250) |
-| workflow.md | 56 | ✅ Good |
-| manual-section-rules.md | 44 | ✅ Good |
-| merge-conflict-rules.md | 62 | ✅ Good |
-
-**Size Warnings:**
-- step-01-init.md (208): Init step with Input Discovery pattern — inherently longer due to artifact validation and degraded mode handling
-- step-04-merge.md (230): Largest step — complex merge priority logic with [MANUAL] conflict resolution UI. Consider extracting conflict UI template to data/ if further expansion needed
-- step-06-write.md (204): Atomic write + verification for multiple file types
-- step-07-report.md (201): Comprehensive summary with multiple report sections
-
-**Recommendation:** step-04-merge.md at 230 lines is the highest risk. If any content is added, the conflict resolution UI or stack skill merge section should be extracted to a data file.
-
-### File Presence Verification
-
-| Design Step | File | Status |
-|-------------|------|--------|
-| 01 - init | step-01-init.md | PRESENT |
-| 02 - detect-changes | step-02-detect-changes.md | PRESENT |
-| 03 - re-extract | step-03-re-extract.md | PRESENT |
-| 04 - merge | step-04-merge.md | PRESENT |
-| 05 - validate | step-05-validate.md | PRESENT |
-| 06 - write | step-06-write.md | PRESENT |
-| 07 - report | step-07-report.md | PRESENT |
-
-- Sequential numbering: PASS (01-07 with no gaps)
-- Final step exists: PASS
-- All design steps have corresponding files: PASS
-
-### Overall: PASS with WARNINGS (4 files approaching size limit, 0 exceeding)
-
----
-
-## Frontmatter Validation
-
-### Per-File Results
-
-| File | name | description | Variables Used | Paths Valid | Status |
-|------|------|-------------|---------------|-------------|--------|
-| step-01-init.md | ✅ | ✅ | 2/2 used | ✅ | PASS |
-| step-02-detect-changes.md | ✅ | ✅ | 1/1 used | ⚠️ | FAIL |
-| step-03-re-extract.md | ✅ | ✅ | 1/1 used | ✅ | PASS |
-| step-04-merge.md | ✅ | ✅ | 3/3 used | ✅ | PASS |
-| step-05-validate.md | ✅ | ✅ | 1/1 used | ✅ | PASS |
-| step-06-write.md | ✅ | ✅ | 1/1 used | ✅ | PASS |
-| step-07-report.md | ✅ | ✅ | 0/0 (final) | ✅ | PASS |
-
-### Violations Found
-
-**1. [FAIL] step-02-detect-changes.md — Hardcoded path reference**
-- Lines 128, 151, 160 reference `step-07-report.md` directly (no-change shortcut path)
-- **Fix:** Add frontmatter variable `noChangeReportFile: './step-07-report.md'` and replace hardcoded references with `{noChangeReportFile}`
-
-### Overall: FAIL (1 violation in step-02-detect-changes.md)
-
-## Critical Path Violations
-
-### Config Variables (Exceptions)
-
-From workflow.md Configuration Loading section:
-- `skills_output_folder`, `forge_data_folder`, `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`
-
-These are runtime config variables resolved from `{project-root}/_bmad/skf/config.yaml` — paths using these are valid.
-
-### Content Path Violations
-
-No `{project-root}/` hardcoded paths found in step content. All module-specific paths use config variables.
-
-### Dead Links
-
-| Reference | From | Status |
-|-----------|------|--------|
-| `./step-02-detect-changes.md` | step-01-init | EXISTS |
-| `../data/manual-section-rules.md` | step-01-init | EXISTS |
-| `./step-03-re-extract.md` | step-02-detect-changes | EXISTS |
-| `./step-04-merge.md` | step-03-re-extract | EXISTS |
-| `./step-05-validate.md` | step-04-merge | EXISTS |
-| `../data/manual-section-rules.md` | step-04-merge | EXISTS |
-| `../data/merge-conflict-rules.md` | step-04-merge | EXISTS |
-| `./step-06-write.md` | step-05-validate | EXISTS |
-| `./step-07-report.md` | step-06-write | EXISTS |
-
-All frontmatter file references resolve to existing files.
-
-### Module Awareness
-
-Workflow is SKF module — correctly references `{project-root}/_bmad/skf/config.yaml`. No BMB-specific path assumptions detected.
-
-### Summary
-
-- **CRITICAL:** 0 violations
-- **HIGH:** 0 violations
-- **MEDIUM:** 0 violations
-
-**Status:** PASS — No critical path violations
-
-## Menu Handling Validation
-
-### Per-File Results
-
-| File | Menu Type | Handler | Exec Rules | A/P | Status |
-|------|-----------|---------|------------|-----|--------|
-| step-01-init | [C] gate + [D]/[X] degraded | ✅ Present | ✅ halt+wait | None (correct) | PASS |
-| step-02-detect-changes | Auto-proceed | ✅ Present | ✅ auto-proceed | None | PASS |
-| step-03-re-extract | Auto-proceed | ✅ Present | ✅ auto-proceed | None | PASS |
-| step-04-merge | Conditional: [C] if conflicts, auto if clean | ✅ Both paths | ✅ Both paths | None | PASS |
-| step-05-validate | Auto-proceed (advisory) | ✅ Present | ✅ auto-proceed | None | PASS |
-| step-06-write | Auto-proceed | ✅ Present | ✅ auto-proceed | None | PASS |
-| step-07-report | None (final step) | N/A | N/A | None | PASS |
-
-### Assessment
-
-- All step files have appropriate menu patterns for their type
-- Init step (01) correctly uses [C] gate without A/P
-- Auto-proceed steps (02, 03, 05, 06) correctly skip user interaction
-- Conditional step (04) properly handles both conflict and clean merge paths
-- Final step (07) correctly ends workflow with no menu
-- A/P excluded throughout (correct for prescriptive surgical workflow)
-- step-01 has secondary [D]/[X] menu for degraded mode with proper handler
-- step-04 has secondary [K]/[R]/[E] conflict resolution UI within merge process
-
-### Overall: PASS — No menu handling violations
-
-## Step Type Validation
-
-### Per-File Results
-
-| File | Expected Type | Actual Type | Pattern Match | Status |
-|------|--------------|-------------|---------------|--------|
-| step-01-init | Init (Input Discovery) | Init (Input Discovery) | ✅ | PASS |
-| step-02-detect-changes | Middle (Simple/Auto) | Middle (Auto-proceed) | ✅ | PASS |
-| step-03-re-extract | Middle (Simple/Auto) | Middle (Auto-proceed) | ✅ | PASS |
-| step-04-merge | Middle (Conditional) | Middle (Conditional) | ✅ | PASS |
-| step-05-validate | Validation Sequence | Validation Sequence | ✅ | PASS |
-| step-06-write | Middle (Simple/Auto) | Middle (Auto-proceed) | ✅ | PASS |
-| step-07-report | Final | Final | ✅ | PASS |
-
-### Detailed Analysis
-
-**step-01-init:** Init with Input Discovery pattern. Requests skill path from user, validates required artifacts (SKILL.md, metadata.json, forge-tier.yaml), checks `preferences.yaml` for `tier_override`, offers degraded mode for missing provenance, inventories [MANUAL] sections. C-only gate (no A/P — correct for init). Non-continuable (correct for single-session).
-
-**step-02-detect-changes:** Auto-proceed middle step with Pattern 4 parallel subprocess. No-change shortcut correctly routes to final step. No user interaction.
-
-**step-03-re-extract:** Auto-proceed middle step with Pattern 2 per-file + Pattern 3 QMD subprocesses. Tier-aware extraction logic. No user interaction.
-
-**step-04-merge:** Conditional middle step — unique pattern. Auto-proceeds on clean merge, presents [C] gate on [MANUAL] conflicts. Secondary [K]/[R]/[E] conflict resolution UI for per-conflict decisions. Correctly halts for user input when conflicts exist.
-
-**step-05-validate:** Validation sequence — auto-proceeds regardless of findings (advisory mode). Pattern 4 parallel checks across 4 categories. Non-blocking.
-
-**step-06-write:** Auto-proceed middle step. Atomic file writes with read-back verification. No user interaction.
-
-**step-07-report:** Final step — no nextStepFile, no menu, workflow ends. Handles no-change shortcut from step-02. Provides workflow chaining recommendations.
-
-### Overall: PASS — All 7 steps match their designated type patterns
-
-## Output Format Validation
-
-### Document Production
-
-**Classification:** Non-document workflow (action-based)
-**From plan:** "Document Output: false (modifies existing files, does not produce new documents)"
-
-This workflow surgically modifies existing skill artifacts (SKILL.md, metadata.json, provenance-map.json, evidence-report.md) rather than producing a new document.
-
-### Assessment
-
-- Template file required: NO (non-document) ✅
-- Final polish step required: NO (non-document) ✅
-- Step-to-output mapping: N/A (no progressive document construction)
-- No `outputFile` variables in any step frontmatter: ✅ (correct for action workflow)
-- No `stepsCompleted` tracking in output: ✅ (correct for non-continuable, non-document)
-
-### Overall: PASS (N/A — non-document workflow correctly configured)
-
-## Validation Design Check
-
-### Is Validation Critical?
-
-YES — This workflow modifies code-derived artifacts with provenance tracking. [MANUAL] section integrity is a zero-loss requirement. Quality gates are important to catch merge errors.
-
-### Internal Validation Step: step-05-validate
-
-| Criterion | Status |
-|-----------|--------|
-| Loads validation data/standards (skill-check) | ✅ |
-| Systematic check sequence (4 parallel checks) | ✅ |
-| Auto-proceeds through checks | ✅ |
-| Clear pass/fail criteria (PASS/WARN/FAIL per check) | ✅ |
-| Reports findings to user | ✅ |
-| Anti-lazy language | ⚠️ Has "CRITICAL:" but not explicit "DO NOT BE LAZY" |
-
-### 4 Validation Checks Assessed
-
-1. **Spec Compliance** — validates against agentskills.io via skill-check ✅
-2. **[MANUAL] Section Integrity** — byte-level comparison against step-01 inventory ✅
-3. **Confidence Tier Consistency** — verifies tier labels match forge capabilities ✅
-4. **Provenance Completeness** — verifies export-to-source mapping integrity ✅
-
-### Critical Flow Segregation
-
-Validation is inline with create steps (step-05 in steps-c/), not in a separate steps-v/ folder. This is **correct** — update-skill is a create-only workflow, not tri-modal. The validation is an internal quality gate within the pipeline, not a standalone validation mode.
-
-### Data Files
-
-- `data/manual-section-rules.md` — referenced by steps 01, 04 ✅
-- `data/merge-conflict-rules.md` — referenced by step 04 ✅
-- No validation-specific data files (validation criteria embedded in step-05) ⚠️
-
-### Overall: PASS — Validation design is well-structured with 4 systematic checks
-
----
-
-## Instruction Style Check
-
-### Domain Assessment
-
-**Domain:** Code analysis / surgical modification
-**Appropriate Style:** Prescriptive (zero-hallucination surgical workflow)
-**From plan:** "Instruction Style: Overall: prescriptive"
-
-### Per-File Style Analysis
-
-| File | Style | Appropriate | Status |
-|------|-------|------------|--------|
-| step-01-init | Prescriptive | ✅ Yes (artifact validation) | PASS |
-| step-02-detect-changes | Prescriptive | ✅ Yes (deterministic comparison) | PASS |
-| step-03-re-extract | Prescriptive | ✅ Yes (AST extraction) | PASS |
-| step-04-merge | Prescriptive | ✅ Yes (merge priority order) | PASS |
-| step-05-validate | Prescriptive | ✅ Yes (systematic validation) | PASS |
-| step-06-write | Prescriptive | ✅ Yes (atomic file operations) | PASS |
-| step-07-report | Prescriptive | ✅ Yes (factual reporting) | PASS |
-
-### Style Indicators Observed
-
-- All steps use "Follow this sequence exactly" ✅
-- All steps have "FORBIDDEN to" rules ✅
-- All steps have explicit MANDATORY SEQUENCE ✅
-- Zero "guide user through" or "think about" language (correct — not facilitative)
-- Consistent prescriptive style throughout ✅
-
-### Overall: PASS — Prescriptive style appropriate for surgical code analysis domain
-
----
-
-## Collaborative Experience Check
-
-### Workflow Interaction Profile
-
-This is a **mostly autonomous** workflow. 5 of 7 steps auto-proceed without user interaction. User interaction is minimal by design — surgical precision, not collaborative facilitation.
-
-### Per-Step Analysis
-
-| File | Interaction | Question Style | Status |
-|------|-------------|---------------|--------|
-| step-01-init | [C] gate + optional [D]/[X] | Progressive (1-2 prompts) | PASS |
-| step-02-detect-changes | Auto-proceed | None | PASS |
-| step-03-re-extract | Auto-proceed | None | PASS |
-| step-04-merge | Conditional: per-conflict [K]/[R]/[E] | Progressive (one conflict at a time) | PASS |
-| step-05-validate | Auto-proceed | None | PASS |
-| step-06-write | Auto-proceed | None | PASS |
-| step-07-report | Display only | None | PASS |
-
-### Assessment
-
-**Collaborative Strengths:**
-- step-01: Single question for skill path, then baseline summary before [C] gate — not overwhelming
-- step-01 degraded mode: Clear [D]/[X] choice with explanation — not interrogative
-- step-04 conflict resolution: Presents one conflict at a time with [K]/[R]/[E] — progressive, not a laundry list
-- Auto-proceed steps respect user's time — no unnecessary gates
-
-**No Interrogation Patterns Found:**
-- No laundry list questions detected
-- No form-filling patterns
-- Two user touchpoints are appropriate for the workflow's purpose
-
-**Progression and Arc:**
-- Clear flow: load → detect → extract → merge → validate → write → report ✅
-- Each step builds on previous with explicit data flow ✅
-- Summary tables at key points keep user informed ✅
-- Report step provides satisfying completion with chaining recommendations ✅
-
-**User Experience:** This workflow feels like a **surgical instrument** — minimal interaction, maximum precision. Appropriate for its domain.
-
-### Overall: PASS — Minimal interaction appropriate for autonomous surgical workflow
-
-## Subprocess Optimization Opportunities
-
-### Already Implemented
-
-| Step | Pattern | Description | Status |
-|------|---------|-------------|--------|
-| step-02 | Pattern 4 (Parallel) | Parallel timestamp/hash comparison across 3 categories | ✅ Implemented |
-| step-03 | Pattern 2 (Per-file) | Per-file AST extraction on each changed file | ✅ Implemented |
-| step-03 | Pattern 3 (Data Ops) | QMD semantic enrichment query (Deep tier only) | ✅ Implemented |
-| step-05 | Pattern 4 (Parallel) | Parallel validation: spec, [MANUAL], confidence, provenance | ✅ Implemented |
-
-All steps include TOOL/SUBPROCESS FALLBACK rule for graceful degradation to main thread.
-
-### Additional Opportunities Identified
-
-**LOW Priority — step-06-write: Parallel verification reads**
-- **Current:** Sequential read-back verification of each written file
-- **Suggested:** Pattern 4 — verify all files in parallel after all writes complete
-- **Impact:** Minor time savings on 4-5 file verifications
-- **Priority:** LOW (verification is fast regardless)
-
-### Steps Without Subprocess Needs
-
-| Step | Reason |
-|------|--------|
-| step-01-init | Sequential artifact loading + user interaction. No parallelizable work. |
-| step-04-merge | Sequential by design (priority order: delete → move → rename → modify → add). Parallelization would break merge semantics. |
-| step-07-report | Display only — no computation requiring subprocess. |
-
-### Summary by Pattern
-
-- **Pattern 1 (grep/regex):** 0 opportunities — no multi-file grep operations
-- **Pattern 2 (per-file):** 1 implemented (step-03 extraction)
-- **Pattern 3 (data ops):** 1 implemented (step-03 QMD enrichment)
-- **Pattern 4 (parallel):** 2 implemented (steps 02, 05) + 1 low-priority (step-06)
-
-### Overall: PASS — Major optimization opportunities already implemented in design. 1 low-priority additional opportunity identified.
-
-## Cohesive Review
-
-### Overall Assessment: EXCELLENT
-
-This workflow is a well-architected surgical pipeline that achieves its goal of precision skill updating with zero [MANUAL] content loss. The balance of autonomy (5 auto-proceed steps) and user control (2 strategic gates) is appropriate for its domain.
-
-### Quality Dimensions
-
-| Dimension | Rating | Notes |
-|-----------|--------|-------|
-| Goal Clarity | Excellent | Single clear purpose — surgical skill update preserving [MANUAL] content |
-| Logical Flow | Excellent | Linear pipeline with clean data flow: load → detect → extract → merge → validate → write → report |
-| Facilitation Quality | Good | Minimal interaction by design — appropriate for autonomous surgical operation |
-| User Experience | Excellent | Clear baseline summary, progressive conflict resolution, comprehensive report |
-| Goal Achievement | Excellent | All success criteria from requirements addressed in the implementation |
-
-### Cohesiveness Analysis
-
-**Flow Continuity:**
-- Each step explicitly builds on previous step's output ✅
-- Data flow is traceable across all 7 steps ✅
-- Two skip paths (no-change shortcut, clean merge auto-proceed) are well-integrated ✅
-
-**Voice and Tone:**
-- Consistent clinical, terse communication throughout ✅
-- Confidence tier labeling principle maintained ✅
-- Surgeon mode persona reinforced in every step ✅
-
-**Structural Consistency:**
-- All steps follow identical structure (MANDATORY EXECUTION RULES, CONTEXT BOUNDARIES, MANDATORY SEQUENCE, SYSTEM METRICS) ✅
-- Universal rules consistently repeated ✅
-- Step-specific rules clearly differentiated ✅
-
-### Strengths
-
-1. **Zero-hallucination principle** enforced throughout — every statement must trace to actual artifacts
-2. **[MANUAL] section preservation** treated as highest priority with multiple safeguards (inventory in step-01, preservation in step-04, integrity verification in step-05, write verification in step-06)
-3. **Tier-aware extraction** well-implemented across Quick/Forge/Forge+/Deep with graceful degradation
-4. **Subprocess optimization** strategically placed at the right steps (02-parallel, 03-per-file, 03-QMD, 05-parallel)
-5. **Error handling** is comprehensive (missing artifacts → abort with helpful message, missing provenance → degraded mode, [MANUAL] conflicts → user resolution)
-6. **Workflow chaining** properly integrated with input/output contracts
-7. **No-change shortcut** prevents unnecessary work when skill is already current
-8. **Conflict resolution UI** is progressive (one conflict at a time, [K]/[R]/[E] choices)
-
-### Weaknesses
-
-1. **Hardcoded path** in step-02 for no-change shortcut (`step-07-report.md` instead of `{noChangeReportFile}`) — already flagged in frontmatter validation
-2. **step-04-merge at 230 lines** — largest step, risk of exceeding limit if expanded. Conflict UI or stack merge section could be extracted to data/
-3. **Evidence-report.md append** in step-06 doesn't explicitly handle the case where the file doesn't exist yet (first update after create-skill)
-4. **Batch mode** mentioned in requirements but not implemented in steps (noted as future enhancement)
-
-### Critical Issues
-
-None. The workflow is well-designed and should function correctly in its current form.
-
-### Recommendation
-
-**READY TO USE** — This workflow exemplifies best practices for surgical code analysis workflows within the SKF module ecosystem. The single frontmatter violation (step-02 hardcoded path) is minor and easily fixed. The workflow reflects deep understanding of the provenance-driven update cycle, [MANUAL] preservation requirements, and tier-aware extraction patterns established across prior SKF workflow builds.
-
-## Plan Quality Validation
-
-### Plan File
-
-**Location:** workflow-plan-update-skill.md
-**Status:** Found and validated
-
-### Implementation Coverage
-
-#### 1. Discovery/Vision
-
-| Planned | Implemented | Quality |
-|---------|------------|---------|
-| Smart regeneration preserving [MANUAL] sections | ✅ All 7 steps implement this vision | HIGH |
-| Provenance-map-driven change detection | ✅ step-02 uses provenance map for targeted diff | HIGH |
-| Handles individual and stack skills internally | ✅ Conditional stack sections in steps 01, 04, 05, 06 | HIGH |
-
-#### 2. Classification
-
-| Attribute | Planned | Implemented | Status |
-|-----------|---------|------------|--------|
-| Document Output | false | No outputFile, no templates | ✅ |
-| Module | SKF | Loads from `_bmad/skf/config.yaml` | ✅ |
-| Session Type | single-session | No continueFile, no stepsCompleted | ✅ |
-| Lifecycle | create-only (steps-c/) | Only steps-c/ folder | ✅ |
-
-#### 3. Requirements
-
-| Requirement | Implemented | Quality |
-|-------------|------------|---------|
-| Linear 7-step pipeline | ✅ 7 sequential steps | HIGH |
-| 2 strategic user gates | ✅ step-01 [C] + step-04 conditional [C] | HIGH |
-| Required inputs (SKILL.md, metadata, forge-tier, provenance) | ✅ All validated in step-01 | HIGH |
-| Outputs (SKILL.md, provenance-map, evidence-report) | ✅ All written in step-06 | HIGH |
-| Zero [MANUAL] content loss | ✅ Safeguards in steps 01, 04, 05, 06 | HIGH |
-| Confidence tier labeling (T1/T1-low/T2) | ✅ step-03 tier-aware extraction | HIGH |
-| AST file:line citations | ✅ Zero-hallucination principle throughout | HIGH |
-| Stack skill multi-file support | ✅ Conditional sections across steps | HIGH |
-| Prescriptive instruction style | ✅ Consistent throughout | HIGH |
-
-#### 4. Design
-
-| Design Element | Implemented | Status |
-|---------------|------------|--------|
-| 7 steps matching design sequence | ✅ All present, correct order | ✅ |
-| Step types match design table | ✅ Init, 4x auto, conditional, validation, final | ✅ |
-| Data flow matches diagram | ✅ Explicit data passing across all steps | ✅ |
-| Interaction patterns (2 gates, 5 auto) | ✅ Matches design specification | ✅ |
-| No-change shortcut (step-02 → step-07) | ✅ Implemented | ✅ |
-| Error handling (abort/degraded/conflict) | ✅ All scenarios covered | ✅ |
-
-#### 5. Tools
-
-| Tool | Planned | Implemented | Status |
-|------|---------|------------|--------|
-| File I/O | Included | Steps 01, 06 read/write | ✅ |
-| Sub-Processes | Included | Steps 02, 03, 05 | ✅ |
-| ast_bridge | External | Referenced in step-03 | ✅ |
-| gh_bridge | External | Implied in source file access | ✅ |
-| qmd_bridge | External | Referenced in step-03 (Deep tier) | ✅ |
-| skill-check | External | Referenced in step-05 | ✅ |
-| manual-section-rules.md | Data file | Created | ✅ |
-| merge-conflict-rules.md | Data file | Created | ✅ |
-
-### Implementation Gaps
-
-1. **Batch mode** (--batch, --continue flags) — Mentioned in requirements but not implemented in step files. This was a deferred enhancement; the plan notes batch mode "wraps multiple runs" suggesting it's an external orchestration concern, not an internal workflow concern.
-
-### Quality Issues
-
-None significant. All implemented requirements are HIGH quality.
-
-### Overall Assessment
-
-- **Plan implementation score:** ~97% (only batch mode deferred)
-- **Status:** Fully Implemented
-- **Quality:** HIGH across all requirement areas
-
-## Summary
-
-**Validation Completed:** 2026-02-27
-**Overall Status:** PASS with 1 minor violation
-
-### Validation Steps Completed
-
-| Step | Check | Result |
-|------|-------|--------|
-| 1 | File Structure & Size | PASS (4 warnings — files approaching limit) |
-| 2 | Frontmatter Validation | FAIL (1 violation — hardcoded path in step-02) |
-| 2b | Critical Path Violations | PASS (0 violations) |
-| 3 | Menu Handling | PASS (all menus correct) |
-| 4 | Step Type Validation | PASS (all types match design) |
-| 5 | Output Format | PASS (N/A — non-document workflow) |
-| 6 | Validation Design Check | PASS (well-structured internal validation) |
-| 7 | Instruction Style | PASS (prescriptive, appropriate for domain) |
-| 8 | Collaborative Experience | PASS (minimal interaction, appropriate for surgical workflow) |
-| 8b | Subprocess Optimization | PASS (major patterns already implemented) |
-| 9 | Cohesive Review | EXCELLENT (ready to use) |
-| 11 | Plan Quality | Fully Implemented (~97%) |
-
-### Issues to Fix
-
-**Must Fix (1):**
-1. **step-02-detect-changes.md** — Add `noChangeReportFile: './step-07-report.md'` to frontmatter and replace hardcoded `step-07-report.md` references on lines 128, 151, 160 with `{noChangeReportFile}`
-
-**Recommended (0 blocking):**
-- step-04-merge.md at 230 lines is highest risk for exceeding 250-line limit. Consider extracting conflict UI or stack merge section to a data file if expansion is needed.
-- step-06-write should explicitly handle the case where evidence-report.md doesn't exist yet (first update after create-skill).
-
-### Key Strengths
-
-- Zero-hallucination principle consistently enforced
-- [MANUAL] section preservation is multi-layered (inventory, preservation, verification, write-check)
-- Tier-aware extraction is well-implemented
-- Subprocess optimization strategically placed
-- Error handling is comprehensive with helpful messages
-- Workflow chaining contracts are properly defined
-- Plan implementation is ~97% complete
-
-### Recommendation
-
-**READY TO USE** after fixing the 1 frontmatter violation in step-02. The workflow exemplifies best practices for surgical code analysis within the SKF module ecosystem.