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

package/src/workflows/README.md

@@ -1,174 +0,0 @@
-# SKF Workflows
-
-Fourteen workflows covering the full skill lifecycle — from source discovery through verified export, with pre-code architecture verification and post-distribution management.
-
-All workflows are triggered via Ferris (`@Ferris <code>`) and execute as step-by-step sequences with just-in-time step loading.
-
-## Workflow Index
-
-| Code | Workflow | Steps | Mode | Purpose |
-| --- | --- | --- | --- | --- |
-| SF | [setup-forge](setup-forge/workflow.md) | 5 | Architect | Initialize environment, detect tools, set capability tier |
-| AN | [analyze-source](analyze-source/workflow.md) | 7 | Architect | Discover skillable units in a repo, produce recommended briefs |
-| BS | [brief-skill](brief-skill/workflow.md) | 5 | Architect | Design a skill scope through guided discovery |
-| CS | [create-skill](create-skill/workflow.md) | 8 | Architect | Compile a skill from brief with provenance (supports --batch) |
-| QS | [quick-skill](quick-skill/workflow.md) | 6 | Architect | Fast skill from package name or GitHub URL — no brief needed |
-| SS | [create-stack-skill](create-stack-skill/workflow.md) | 9 | Architect | Consolidated project stack skill with integration patterns (code-mode + compose-mode) |
-| VS | [verify-stack](verify-stack/workflow.md) | 6 | Audit | Validate tech stack feasibility against architecture and PRD |
-| RA | [refine-architecture](refine-architecture/workflow.md) | 6 | Architect | Improve architecture doc using verified skill data |
-| US | [update-skill](update-skill/workflow.md) | 7 | Surgeon | Regenerate after source changes, preserving \[MANUAL\] sections |
-| AS | [audit-skill](audit-skill/workflow.md) | 6 | Audit | Drift detection between skill and current source code |
-| TS | [test-skill](test-skill/workflow.md) | 7 | Audit | Cognitive completeness verification — quality gate before export |
-| EX | [export-skill](export-skill/workflow.md) | 6 | Delivery | Package for distribution, inject into CLAUDE.md/AGENTS.md |
-| RS | [rename-skill](rename-skill/workflow.md) | 3 | Management | Rename a skill across all versions (transactional copy-verify-delete) |
-| DS | [drop-skill](drop-skill/workflow.md) | 3 | Management | Drop specific versions or whole skill (soft deprecate or hard purge) |
-
-## Typical Flows
-
-**First-time setup:**
-
-```
-SF → AN → CS (batch) → TS → EX
-```
-
-**Single skill (full quality):**
-
-```
-SF → BS → CS → TS → EX
-```
-
-**Single skill (fast):**
-
-```
-SF → QS → EX
-```
-
-**Pre-code stack verification:**
-
-```
-SF → CS×N (per library) → VS → RA → SS (compose) → TS → EX
-```
-
-**Maintenance:**
-
-```
-AS → US → TS → EX
-```
-
-**Management:**
-
-```
-RS or DS → EX
-```
-
-## Knowledge vs. Data
-
-The module uses two kinds of reference material, loaded just-in-time during workflow execution:
-
-| Aspect | Knowledge (`knowledge/`) | Data (`{workflow}/data/`) |
-| --- | --- | --- |
-| Scope | Cross-cutting, multi-workflow | Single workflow, single step |
-| Content | Principles, patterns, judgment rules | Schemas, templates, scoring formulas |
-| Index | `skf-knowledge-index.csv` | Referenced directly by step files |
-| Examples | zero-hallucination, confidence-tiers | skill-brief-schema.md, scoring-rules.md |
-
-**Knowledge files** live in `src/knowledge/` and capture principles Ferris applies across multiple workflows — zero hallucination, confidence tiers, provenance tracking, \[MANUAL\] preservation. Workflow steps reference these when they need cross-cutting judgment, not step-specific rules.
-
-**Data files** live in each workflow's `data/` directory and contain operational artifacts tightly coupled to specific steps — schemas, templates, scoring formulas, extraction patterns.
-
-Neither duplicates the other. Knowledge files reference (not repeat) data files where the detailed operational rules live.
-
-## Directory Structure
-
-Each workflow follows a consistent structure:
-
-```
-{workflow}/
-├── workflow.md              # Entry point — goals, mode routing, step sequence
-├── steps-c/                 # Create-mode steps (sequential execution)
-│   ├── step-01-*.md
-│   ├── step-02-*.md
-│   └── ...
-├── data/                    # Reference data — schemas, rules, patterns
-│   └── *.md
-└── templates/               # Output skeletons (only analyze-source, test-skill)
-    └── *-template.md
-```
-
-### Step Loading
-
-Steps execute sequentially via just-in-time loading. Only the current step is in context. Each step explicitly names the next step file. Data and template files are loaded on demand by the steps that need them.
-
-## Workflow Details
-
-### setup-forge (SF)
-
-**5 steps** | **Data:** tier-rules.md
-
-Detects available tools (ast-grep, gh, QMD), determines the capability tier (Quick/Forge/Forge+/Deep), writes `forge-tier.yaml` to the sidecar, and optionally indexes the project. Run this first — all other workflows adapt behavior to the detected tier.
-
-### analyze-source (AN)
-
-**7 steps** | **Data:** skill-brief-schema.md, unit-detection-heuristics.md | **Templates:** analysis-report-template.md
-
-Brownfield onboarding entry point. Scans project structure, identifies skillable units using confidence-tiered heuristic signals, maps exports and integration points, presents recommendations for user confirmation, then generates `skill-brief.yaml` files ready for `create-skill --batch`.
-
-### brief-skill (BS)
-
-**5 steps** | **Data:** skill-brief-schema.md, scope-templates.md
-
-Interactive guided discovery. Gathers user intent (target repo, language, what to skill), analyzes the target to understand boundaries, walks through scope definition with the user, confirms the brief, then writes a validated `skill-brief.yaml`.
-
-### create-skill (CS)
-
-**8 primary steps (11 step files including sub-steps)** | **Data:** extraction-patterns.md, extraction-patterns-tracing.md, skill-sections.md, tier-degradation-rules.md, compile-assembly-rules.md, source-resolution-protocols.md
-
-The core compilation engine. Loads a brief, checks ecosystem context, extracts source with AST-backed provenance (T1 confidence when ast-grep available), enriches with usage patterns, compiles into agentskills.io-compliant sections, validates structural integrity, generates the `SKILL.md` artifact, and produces an evidence report. Supports `--batch` for processing multiple briefs.
-
-### quick-skill (QS)
-
-**6 steps** | **Data:** registry-resolution.md, skill-template.md
-
-Fastest path to a skill. Accepts a GitHub URL or package name, resolves to source via registry lookup, performs ecosystem check, extracts public API surface without requiring a brief, compiles best-effort `SKILL.md`, validates, and writes output.
-
-### create-stack-skill (SS)
-
-**9 steps** | **Data:** integration-patterns.md, manifest-patterns.md, stack-skill-template.md, compose-mode-rules.md
-
-Two modes: **Code-mode** analyzes dependency manifests and co-import patterns from actual source code. **Compose-mode** synthesizes a stack skill from pre-generated individual skills + architecture document (no codebase required). Both produce the same output format — consolidated stack skill with integration patterns.
-
-### verify-stack (VS)
-
-**6 steps** | **Data:** integration-verification-rules.md, coverage-patterns.md, feasibility-report-template.md
-
-Pre-code verification engine. Cross-references generated skills against architecture and PRD documents. Three passes: coverage verification (does a skill exist for each tech?), integration verification (do the APIs actually connect?), and requirements verification (does the stack cover the PRD?). Produces a feasibility report with evidence-backed verdicts and prescriptive recommendations. Re-runnable — swap libraries, regenerate skills, re-verify.
-
-### refine-architecture (RA)
-
-**6 steps** | **Data:** refinement-rules.md
-
-Architecture improvement engine. Takes the original architecture document and refines it using verified skill data and VS feasibility findings. Fills gaps, flags issues, suggests improvements — all backed by specific API evidence from the generated skills. Produces a refined architecture document.
-
-### update-skill (US)
-
-**7 steps** | **Data:** manual-section-rules.md, merge-conflict-rules.md, remote-source-resolution.md (tier-degradation-rules shared from create-skill)
-
-Surgical update engine. Loads the existing skill, detects what changed in source since last compilation, re-extracts only affected exports with fresh provenance, merges new extractions while preserving all `[MANUAL]` developer-authored content, validates the merged result, writes the updated skill, and produces a change report.
-
-### audit-skill (AS)
-
-**6 steps** | **Data:** drift-report-template.md, severity-rules.md
-
-Drift detection engine. Loads the skill under audit, re-indexes current source to build a fresh reference, performs structural diff (signature changes, missing exports), performs semantic diff (behavioral divergence), classifies each finding by severity using defined rules, and produces a graded drift report.
-
-### test-skill (TS)
-
-**7 steps** | **Data:** output-section-formats.md, scoring-rules.md, source-access-protocol.md | **Templates:** test-report-template.md
-
-Quality gate before export. Loads the skill, detects test mode (naive for Quick tier, contextual for Forge/Deep), runs coverage checks against source, runs coherence checks for internal consistency, scores using weighted rubric, and produces a completeness report with pass/fail gate decision.
-
-### export-skill (EX)
-
-**6 steps** | **Data:** managed-section-format.md, snippet-format.md
-
-Distribution packaging. Loads the completed skill, packages as agentskills.io-compliant bundle, generates context snippets optimized for token efficiency, updates managed sections in `CLAUDE.md` / `AGENTS.md` with platform-aware injection, produces a token budget report, and summarizes the export.

package/src/workflows/analyze-source/data/skill-brief-schema.md

@@ -1,125 +0,0 @@
-# Skill Brief Schema
-
-## Purpose
-
-Defines the output contract for skill-brief.yaml files generated by analyze-source. Each generated brief must conform to this schema to be consumable by brief-skill and create-skill downstream workflows.
-
-## Required Fields
-
-| Field | Type | Constraint | Description |
-|-------|------|------------|-------------|
-| name | string | kebab-case `[a-z0-9-]+` | Unique skill identifier |
-| version | string | Semantic version (`X.Y.Z` or `X.Y.Z-prerelease`) | Auto-detect from source (see Version Detection below), fall back to `1.0.0` |
-| source_repo | string | GitHub URL or local path | Repository or project root (optional when `source_type: "docs-only"`) |
-| language | string | Recognized language | Primary programming language |
-| scope | object | See Scope Object below | Boundary definition |
-| description | string | 1-3 sentences | What the skill covers |
-| forge_tier | string | `Quick` / `Forge` / `Forge+` / `Deep` | Inherited from forge-tier.yaml (Title Case) |
-| created | string | ISO date `YYYY-MM-DD` | Generation date |
-| created_by | string | user_name from config | Who generated the brief |
-
-## Optional Fields
-
-| Field | Type | Constraint | Description |
-|-------|------|------------|-------------|
-| source_type | string | `source` or `docs-only` | Default `source`. When `docs-only`: `source_repo` optional, `doc_urls` required |
-| doc_urls | array | `{url, label}` objects | Documentation URLs for T3 content. Required when `source_type: "docs-only"` |
-| `scripts_intent` | string | `detect` / `none` / free-text | Describes whether scripts should be extracted. Values: `detect` (auto-detect from source — default when absent), `none` (skip scripts), or a free-text description of expected scripts (e.g., "CLI validation tools in bin/"). |
-| `assets_intent` | string | `detect` / `none` / free-text | Describes whether assets should be extracted. Values: `detect` (auto-detect from source — default when absent), `none` (skip assets), or a free-text description of expected assets (e.g., "JSON schemas in schemas/"). |
-| `target_version` | string | Semantic version (`X.Y.Z` or `X.Y.Z-prerelease`) | User-specified target version. When present, overrides auto-detection and becomes the skill's version. Recommended for docs-only skills where auto-detection is unavailable. |
-| `source_authority` | string | `official` / `community` / `internal` | Default `community`. Set to `official` only when the skill creator is the library maintainer. Forced to `community` when `source_type: "docs-only"`. |
-| `source_ref` | string | Git ref (tag/branch/HEAD) | Resolved git ref used for source access. Set automatically during tag resolution — do not set manually. |
-
-When `source_type: "docs-only"`:
-- `source_repo` becomes optional (set to doc site URL for reference)
-- `doc_urls` must have at least one entry
-- `source_authority` is forced to `community` (T3 external documentation cannot be `official`)
-- All extracted content gets `[EXT:{url}]` citations
-
-## Version Detection
-
-During brief generation, attempt to auto-detect the source version before defaulting to `"1.0.0"`. Check the first matching file in the source:
-
-- **Python:** `pyproject.toml` `[project] version` (static) → if `dynamic = ["version"]`, check `__init__.py` for `__version__` → `_version.py` if exists → `setup.py` `version=` → `git describe --tags --abbrev=0`
-- **JavaScript/TypeScript:** `package.json` (`"version"`)
-- **Rust:** `Cargo.toml` `[package] version` (static) → if `version = { workspace = true }`, resolve from workspace root `Cargo.toml` → `git describe --tags --abbrev=0`
-- **Go:** version tag from `go.mod` or `git describe --tags --abbrev=0`
-
-If the source is a remote GitHub repo, use `gh api repos/{owner}/{repo}/contents/{file}` to read the version file. If the source is local, read the file directly.
-
-If detection succeeds, use the detected version. If it fails or returns a non-semver value, fall back to `"1.0.0"`.
-
-The create-skill workflow (step-03-extract) also performs version reconciliation at extraction time — if the source version has changed since the brief was created, the extraction step warns and uses the source version.
-
-**Target version override:** When `target_version` is present in the brief, it takes precedence over auto-detection. Auto-detection still runs for informational purposes (displayed as "Detected version" alongside the user-specified "Target version"), but the `target_version` value is used as the brief's `version` field. This is particularly useful for docs-only skills (where no package manifest exists) and when the user wants to compile a skill for a specific older version.
-
-**Pre-release handling:** If the detected version contains a pre-release tag (e.g., `1.0.0-beta.0`, `2.0.0-rc.1`), preserve it as-is. Pre-release tags are valid semver and must not be stripped. When comparing versions during reconciliation, use semver-aware comparison that respects pre-release ordering.
-
-## Scope Object
-
-```yaml
-scope:
-  type: full-library | specific-modules | public-api | component-library | docs-only
-  include:
-    - 'src/**/*.ts'          # At least one required
-  exclude:
-    - 'src/**/*.test.ts'     # Optional
-  notes: 'Optional rationale for scope decision'
-  # Additional fields when scope.type is "component-library":
-  # registry_path: "path/to/registry.ts"  # Optional — auto-detected if omitted
-  # ui_variants:                           # Optional — design system variants
-  #   - name: "shadcnui"
-  #     package: "packages/components/react-shadcn"
-  # demo_patterns:                         # Optional — auto-detected if omitted
-  #   - "**/demo/**"
-  #   - "**/*.stories.*"
-```
-
-### Scope Types
-
-| Type | Use When |
-|------|----------|
-| full-library | Entire codebase of a unit |
-| specific-modules | Selected components or packages |
-| public-api | Only exported interfaces |
-| component-library | UI component libraries with registries, props-based APIs, and design system variants |
-| docs-only | When source_type is docs-only — no source code available, all content from doc_urls |
-
-## YAML Template
-
-```yaml
-name: '{unit-name}'
-version: '{detected-version or 1.0.0}'
-source_type: 'source'
-source_repo: '{project_path}'
-language: '{detected_language}'
-scope:
-  type: '{detected_scope_type}'
-  include:
-    - '{include_pattern}'
-  exclude:
-    - '{exclude_pattern}'
-  notes: '{scope_rationale}'
-description: '{1-3 sentence description}'
-forge_tier: '{Quick|Forge|Forge+|Deep}'
-created: '{current_date}'
-created_by: '{user_name}'
-```
-
-## Validation Rules
-
-1. **Name uniqueness**: No duplicate names within forge_data_folder
-2. **Source accessibility**: source_repo path must exist or be reachable
-3. **Language recognized**: Must be a known programming language
-4. **Scope type valid**: Must match one of the five defined types (full-library, specific-modules, public-api, component-library, docs-only)
-5. **Include patterns**: At least one include glob pattern required (exception: `docs-only` scope, where include patterns are optional since no source code is available)
-6. **Forge tier match**: Must match value in forge-tier.yaml
-7. **Docs-only mode**: When `source_type: "docs-only"`, `doc_urls` required (>= 1), `source_repo` optional
-8. Each `doc_urls` entry must have a valid `url` field
-
-## Output Location
-
-Each skill-brief.yaml is written to:
-```
-{forge_data_folder}/{unit-name}/skill-brief.yaml
-```

package/src/workflows/analyze-source/data/unit-detection-heuristics.md

@@ -1,124 +0,0 @@
-# Unit Detection Heuristics
-
-## Purpose
-
-Rules for identifying discrete skillable units within a project. A "skillable unit" is a self-contained component with clear boundaries that can be documented as an independent skill.
-
-## Detection Signals
-
-### Strong Signals (High Confidence)
-
-| Signal | Description | Example |
-|--------|-------------|---------|
-| Independent package.json / Cargo.toml / go.mod | Unit has its own dependency manifest | `packages/auth/package.json` |
-| Separate entry point | Unit has a main/index file | `services/api/src/index.ts` |
-| Docker/service definition | Unit runs as an independent service | `docker-compose.yml` service entry |
-| Distinct export surface | Unit exports a public API consumed by others | `src/lib/index.ts` with re-exports |
-| Workspace member | Listed in root workspace configuration | `pnpm-workspace.yaml` packages |
-
-### Moderate Signals (Medium Confidence)
-
-| Signal | Description | Example |
-|--------|-------------|---------|
-| Directory depth boundary | Top-level directory with self-contained structure | `src/modules/payments/` |
-| Naming convention | Follows organizational naming pattern | `@org/package-name` |
-| Separate test suite | Has its own test directory or config | `packages/auth/__tests__/` |
-| README.md presence | Has documentation at directory level | `libs/utils/README.md` |
-| CI/CD pipeline reference | Referenced in build/deploy configuration | `.github/workflows/deploy-auth.yml` |
-
-### Weak Signals (Low Confidence — Require Corroboration)
-
-| Signal | Description | Example |
-|--------|-------------|---------|
-| Large directory | Many files in a subtree | 50+ files under one directory |
-| Comment boundaries | Code comments marking sections | `// --- Auth Module ---` |
-| Import clustering | Files that import primarily from each other | Tight import graph cluster |
-
-## Boundary Classification
-
-### Service Boundary
-- Independent deployable unit
-- Own process, port, or container
-- Clear network interface (REST, gRPC, message queue)
-- Scope type: `full-library`
-
-### Package Boundary
-- Workspace member or independently versioned package
-- Own dependency manifest
-- Exports consumed by other packages
-- Scope type: `full-library` or `specific-modules`
-
-### Module Boundary
-- Logical grouping within a single package
-- Shared namespace or directory structure
-- Internal cohesion, external coupling through defined interface
-- Scope type: `specific-modules` or `public-api`
-
-### Library Boundary
-- Third-party dependency with significant project-specific usage patterns
-- Custom wrappers, configurations, or integration code
-- Scope type: `public-api`
-
-### Component Library Boundary
-- Contains a component registry or catalog file (array of component definitions with IDs, names, categories)
-- Has `components/`, `packages/components/`, or similar multi-component directory structure
-- Multiple design system variant directories (e.g., `react-shadcn/`, `react-baseui/`, `react-carbon/`)
-- Significant demo/story/example file ratio (>30% of total files)
-- CLI-based installation pattern (e.g., `npx <tool> add <component-id>`)
-- Props interfaces outnumber function signatures as primary API surface
-- Scope type: `component-library`
-
-## Disqualification Rules
-
-Do NOT recommend as a skillable unit if:
-
-1. **Too small**: Fewer than 3 source files or 100 lines of code
-2. **Generated code**: Auto-generated files (protobuf, GraphQL codegen, etc.)
-3. **Pure configuration**: Only config files with no logic
-4. **Test-only**: Test utilities with no production code
-5. **Vendor/dependency**: Third-party code copied into project
-6. **Already skilled**: Existing skill found in forge_data_folder (recommend update-skill instead)
-
-## Script/Asset Detection Signals
-
-During per-unit analysis, check for scripts and assets alongside code exports.
-
-**Script signals:**
-
-| Strength | Signal | Example |
-|----------|--------|---------|
-| Strong | Entry point in `package.json` `bin`, Cargo.toml `[[bin]]`, pyproject.toml `[project.scripts]` | `"bin": { "migrate": "scripts/migrate.js" }` |
-| Strong | Shebang + executable file | `#!/usr/bin/env python` in `scripts/setup.py` |
-| Moderate | File in `scripts/`, `bin/`, `tools/`, `cli/` directory | `scripts/validate.sh` |
-| Moderate | CI/CD reference to script | `.github/workflows/test.yml` runs `scripts/test.sh` |
-
-**Asset signals:**
-
-| Strength | Signal | Example |
-|----------|--------|---------|
-| Strong | JSON Schema file with `$schema` key | `schemas/config.schema.json` |
-| Strong | Config template with `.example` or `.template` extension | `config.yaml.example` |
-| Moderate | File in `assets/`, `templates/`, `schemas/`, `configs/`, `examples/` directory | `templates/report.hbs` |
-| Moderate | OpenAPI/GraphQL definition | `openapi.json`, `schema.graphql` |
-
-**Per-unit output:** Record `has_scripts: boolean`, `has_assets: boolean`, `script_files: string[]`, `asset_files: string[]`.
-
-**Disqualify:** Generated files (dist/, build/), vendored dependencies, IDE configs (.vscode/, .idea/), binary files (.so, .dll, .jar).
-
-## Stack Skill Candidate Detection
-
-Flag units as stack skill candidates when:
-
-1. **Co-import frequency**: Two or more units are imported together in 3+ files
-2. **Integration adapter**: A unit exists primarily to bridge two other units
-3. **Shared state**: Multiple units read/write to the same data store
-4. **Orchestration layer**: A unit coordinates calls across multiple other units
-
-## Tier-Aware Scanning Depth
-
-| Forge Tier | Scanning Approach |
-|------------|-------------------|
-| Quick | File structure analysis: directory trees, manifest files, entry points, naming conventions |
-| Forge | AST analysis: export surfaces, import graphs, dependency trees, type hierarchies |
-| Forge+ | AST + CCC: semantic file pre-ranking before structural analysis, CCC signals for relevance scoring |
-| Deep | AST + QMD: temporal evolution, refactoring patterns, semantic relationships, architectural drift |

package/src/workflows/analyze-source/workflow.md

@@ -1,61 +0,0 @@
----
-name: analyze-source
-description: Decomposition engine — discover what to skill, recommend stack skill
-web_bundle: true
-installed_path: '{project-root}/_bmad/skf/workflows/skillforge/analyze-source'
----
-
-# Analyze Source
-
-**Goal:** Analyze a large repo or multi-service project to identify discrete skillable units, map exports and integration points, and produce recommended skill-brief.yaml files as the primary entry point for brownfield onboarding.
-
-**Your Role:** In addition to your name, communication_style, and persona, you are also a source code analyst and decomposition architect collaborating with a developer onboarding an existing project. This is a partnership, not a client-vendor relationship. You bring expertise in codebase analysis, service boundary detection, and skill scoping, while the user brings their domain knowledge of the project being analyzed. Work together as equals.
-
-**Meta-Context:** This workflow is the entry point of the SKF skill creation pipeline. Its output (skill-brief.yaml files) feeds directly into brief-skill and create-skill workflows. The analysis must be thorough enough to produce actionable briefs, but scoped enough to avoid overwhelming the user with false positives.
-
----
-
-## 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
-- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array
-- **Append-Only Building**: Build the analysis report by appending content as directed to the output file
-- **Tier-Aware Analysis**: Scanning depth adapts to forge tier — Quick (file structure), Forge (AST), Forge+ (AST + CCC semantic pre-ranking), Deep (AST+QMD)
-
-### 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. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
-6. **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** update frontmatter of output files when writing the final output for a specific step
-- 🎯 **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
-
----
-
-## 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`, `forge_data_folder`, `skills_output_folder`, `sidecar_path`
-
-### 2. First Step Execution
-
-Load, read the full file and then execute `./steps-c/step-01-init.md` to begin the workflow.

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

@@ -1,64 +0,0 @@
----
-name: audit-skill
-description: "Drift detection. Forge tier: structural. Deep tier: full."
-web_bundle: true
-installed_path: '{project-root}/_bmad/skf/workflows/skillforge/audit-skill'
----
-
-# Audit Skill
-
-**Goal:** Detect drift between an existing skill and its current source code, producing a severity-graded drift report with AST-backed findings and actionable remediation suggestions.
-
-**Your Role:** In addition to your name, communication_style, and persona, you are also a skill auditor operating in Ferris Audit mode. This is a deterministic analysis workflow — every finding must trace to actual code with file:line citations. You enforce the zero-hallucination principle: structural truth over semantic guessing. You bring AST analysis expertise and drift detection methodology, while the source code provides the ground truth.
-
----
-
-## 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
-- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array
-- **Append-Only Building**: Build the drift report by appending sections as directed to the output file
-- **Tier-Aware Execution**: Adapt analysis depth based on detected forge tier (Quick/Forge/Forge+/Deep) with graceful degradation
-
-### 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. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
-6. **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** update frontmatter of output files when writing the final output for a specific step
-- 🎯 **ALWAYS** follow the exact instructions in the step file
-- ⏸️ **ALWAYS** halt at menus and wait for user input
-- 📋 **NEVER** create mental todo lists from future steps
-- ⚙️ **TOOL/SUBPROCESS FALLBACK**: If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-
----
-
-## 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-init.md` to begin the workflow.