bmad-module-skill-forge 0.2.0

package/src/workflows/analyze-source/steps-c/step-01b-continue.md

@@ -0,0 +1,144 @@
+---
+name: 'step-01b-continue'
+description: 'Handle workflow continuation from previous session'
+
+outputFile: '{output_folder}/analyze-source-report-{project_name}.md'
+nextStepOptions:
+  step-02: './step-02-scan-project.md'
+  step-03: './step-03-identify-units.md'
+  step-04: './step-04-map-and-detect.md'
+  step-05: './step-05-recommend.md'
+  step-06: './step-06-generate-briefs.md'
+---
+
+# Step 1b: Continue Analysis
+
+## STEP GOAL:
+
+To resume the analyze-source workflow from where it was left off in a previous session by reading the analysis report's progress state and routing to the correct next step.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 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
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+- ⚙️ 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
+
+### Role Reinforcement:
+
+- ✅ You are a source code analyst and decomposition architect (Ferris Architect mode)
+- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
+- ✅ Prescriptive precision — resume exactly where we left off
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on reading state and routing — do NOT perform any analysis
+- 🚫 FORBIDDEN to re-run completed steps
+- 💬 Present progress summary to user before resuming
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Follow the MANDATORY SEQUENCE exactly
+- 💾 Update lastContinued in output frontmatter
+- 📖 Route to the correct next step based on stepsCompleted
+- 🚫 FORBIDDEN to skip the progress summary
+
+## CONTEXT BOUNDARIES:
+
+- Available: Existing analysis report with stepsCompleted array
+- Focus: State detection and routing only
+- Limits: Do not modify any existing report content
+- Dependencies: Output file must exist with valid stepsCompleted
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Welcome Back
+
+"**Welcome back!** Let me check where we left off with the source analysis..."
+
+### 2. Read Progress State
+
+Load {outputFile} and read frontmatter:
+- `stepsCompleted` array
+- `project_path`
+- `project_name`
+- `forge_tier`
+- `existing_skills`
+- `confirmed_units`
+
+### 3. Present Progress Summary
+
+"**Analysis Progress for {project_name}:**
+
+**Project:** {project_path}
+**Forge Tier:** {forge_tier}
+**Steps Completed:** {list stepsCompleted}
+**Last Step:** {last entry in stepsCompleted}
+
+**Progress:**
+{For each completed step, summarize what was accomplished — read the relevant sections from the report}"
+
+### 4. Determine Next Step
+
+Map the last completed step to the next step file:
+
+| Last Completed | Next Step |
+|----------------|-----------|
+| step-01-init | step-02-scan-project |
+| step-02-scan-project | step-03-identify-units |
+| step-03-identify-units | step-04-map-and-detect |
+| step-04-map-and-detect | step-05-recommend |
+| step-05-recommend | step-06-generate-briefs |
+
+**IF all steps completed:**
+"**This analysis appears to be complete.** All steps have been finished. Would you like to start a new analysis?"
+
+### 5. Update and Route
+
+Update {outputFile} frontmatter:
+```yaml
+lastContinued: '{current_date}'
+```
+
+"**Resuming from {next_step_name}...**"
+
+#### Menu Handling Logic:
+
+- After progress is confirmed, immediately load, read entire file, then execute the appropriate step from {nextStepOptions}
+
+#### EXECUTION RULES:
+
+- This is an auto-proceed continuation step
+- Route directly to the next incomplete step
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN the progress state has been read, summarized to the user, and lastContinued updated will you load the appropriate next step file to resume the workflow.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Analysis report loaded and progress state read
+- Progress summary presented to user
+- Correct next step identified from stepsCompleted
+- lastContinued updated in frontmatter
+- Routed to correct step file
+
+### ❌ SYSTEM FAILURE:
+
+- Not reading stepsCompleted from report
+- Skipping progress summary
+- Routing to wrong step
+- Re-running already completed steps
+- Not updating lastContinued
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

package/src/workflows/analyze-source/steps-c/step-02-scan-project.md

@@ -0,0 +1,208 @@
+---
+name: 'step-02-scan-project'
+description: 'Map project structure, detect service boundaries, and identify package manifests'
+
+nextStepFile: './step-03-identify-units.md'
+outputFile: '{output_folder}/analyze-source-report-{project_name}.md'
+heuristicsFile: '../data/unit-detection-heuristics.md'
+---
+
+# Step 2: Scan Project
+
+## STEP GOAL:
+
+To map the complete project structure by scanning directory trees, detecting service boundaries, identifying package manifests, and cataloging entry points — building the foundation that subsequent steps use for unit identification.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 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
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+- ⚙️ 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
+
+### Role Reinforcement:
+
+- ✅ You are a source code analyst and decomposition architect (Ferris Architect mode)
+- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
+- ✅ Prescriptive precision — zero-hallucination, only report what is found
+- ✅ File:line citation tracing for all claims
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on structural scanning — do NOT classify units or map exports yet
+- 🚫 FORBIDDEN to read source file contents beyond manifest files and entry points
+- 💬 Use subprocess optimization (Pattern 1) for scanning across many files
+- 📋 Tier-aware scanning depth: Quick (file structure only), Forge (+ manifest parsing), Deep (+ config analysis)
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Follow the MANDATORY SEQUENCE exactly
+- 💾 Append "## Project Scan" section to {outputFile}
+- 📖 Update stepsCompleted in {outputFile} frontmatter
+- 🚫 FORBIDDEN to proceed without presenting scan results to user
+
+## CONTEXT BOUNDARIES:
+
+- Available: project_path, forge_tier, scope_hints, existing_skills from report frontmatter
+- Focus: Project structure mapping only — directory tree, manifests, entry points, service configs
+- Limits: Do not analyze exports, imports, or integration points (that's steps 03-04)
+- Dependencies: step-01-init must have created the report with valid project_path
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Load Context
+
+Read {outputFile} frontmatter to obtain:
+- `project_path` — the root to scan
+- `forge_tier` — determines scanning depth
+- Scope hints (if any were provided in step 01)
+
+Load {heuristicsFile} for reference on detection signals.
+
+### 2. Scan Directory Structure
+
+Launch a subprocess that scans the project directory structure:
+
+1. Map the top-level directory tree (2-3 levels deep)
+2. Identify workspace configuration files (pnpm-workspace.yaml, lerna.json, Cargo.toml [workspace], go.work, etc.)
+3. Find all package manifests (package.json, Cargo.toml, go.mod, requirements.txt, pyproject.toml, build.gradle, pom.xml)
+4. Locate entry point files (index.ts, main.ts, app.ts, main.go, main.rs, __init__.py, etc.)
+5. Detect service configuration (Dockerfile, docker-compose.yml, kubernetes manifests, serverless.yml)
+6. Return structured findings — file paths and types only, not contents
+
+**If subprocess unavailable:** Perform directory scanning in main thread using file I/O tools.
+
+**Apply scope hints if provided:**
+- If specific directories were given, scan only those
+- If exclusion patterns were given, skip matching directories
+
+### 3. Detect Service Boundaries
+
+Based on scan results, identify potential service boundaries:
+
+**Strong boundary signals:**
+- Independent package manifest (own package.json, Cargo.toml, etc.)
+- Docker/container configuration
+- Separate entry point file
+- Workspace member listing
+
+**Document each detected boundary with:**
+- Path relative to project root
+- Boundary type (service / package / module)
+- Detection signals found (list specific files)
+- Confidence level (strong / moderate / weak)
+
+### 4. Catalog Manifests and Entry Points
+
+Create a structured catalog:
+
+**Manifests found:**
+| Path | Type | Language Indicator |
+|------|------|-------------------|
+| {path} | {manifest_type} | {language} |
+
+**Entry points found:**
+| Path | Type |
+|------|------|
+| {path} | {entry_type} |
+
+**Service configurations found:**
+| Path | Type |
+|------|------|
+| {path} | {config_type} |
+
+### 5. Present Scan Results
+
+"**Project Scan Complete**
+
+**Project:** {project_path}
+**Forge Tier:** {forge_tier}
+
+**Structure Overview:**
+{top-level directory tree}
+
+**Detected Boundaries:** {count}
+{list each boundary with path, type, confidence}
+
+**Manifests Found:** {count}
+{summary table}
+
+**Entry Points Found:** {count}
+{summary table}
+
+**Service Configurations:** {count}
+{summary table}
+
+**Scope Applied:** {hints or 'Full project scan'}
+
+Does this scan look complete? Any directories I should investigate further or skip?"
+
+Wait for user feedback. If user identifies gaps, rescan as directed.
+
+### 6. Append to Report
+
+Append the complete "## Project Scan" section to {outputFile}:
+
+Replace the placeholder `[Appended by step-02-scan-project]` with the full scan results including:
+- Structure overview
+- Detected boundaries table
+- Manifests catalog
+- Entry points catalog
+- Service configurations catalog
+- Scope notes
+
+Update {outputFile} frontmatter:
+```yaml
+stepsCompleted: ['step-01-init', 'step-02-scan-project']
+lastStep: 'step-02-scan-project'
+```
+
+### 7. Present MENU OPTIONS
+
+Display: "**Select:** [C] Continue to Unit Identification"
+
+#### Menu Handling Logic:
+
+- IF C: Save scan results to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
+- IF Any other: help user, then [Redisplay Menu Options](#7-present-menu-options)
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN the Project Scan section has been appended to {outputFile} with complete boundary, manifest, and entry point catalogs, and frontmatter stepsCompleted has been updated, will you load and read fully {nextStepFile} to begin unit identification.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Complete directory structure mapped
+- All package manifests found and cataloged
+- Entry points identified
+- Service boundaries detected with confidence levels
+- Scope hints applied correctly
+- Results presented to user for confirmation
+- Report updated with Project Scan section
+- stepsCompleted updated in frontmatter
+
+### ❌ SYSTEM FAILURE:
+
+- Incomplete directory scan (missing subdirectories)
+- Not detecting workspace configuration files
+- Reading source file contents (only manifests/configs allowed)
+- Not presenting results for user confirmation
+- Classifying units in this step (that's step 03)
+- Hardcoded paths instead of using frontmatter variables
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

package/src/workflows/analyze-source/steps-c/step-03-identify-units.md

@@ -0,0 +1,199 @@
+---
+name: 'step-03-identify-units'
+description: 'Classify discrete skillable units from scan results using detection heuristics and assign scope types'
+
+nextStepFile: './step-04-map-and-detect.md'
+outputFile: '{output_folder}/analyze-source-report-{project_name}.md'
+heuristicsFile: '../data/unit-detection-heuristics.md'
+---
+
+# Step 3: Identify Units
+
+## STEP GOAL:
+
+To classify each detected boundary from the project scan into discrete skillable units by applying detection heuristics, assigning boundary types and scope types, and filtering out disqualified candidates.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 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
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+- ⚙️ 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
+
+### Role Reinforcement:
+
+- ✅ You are a source code analyst and decomposition architect (Ferris Architect mode)
+- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
+- ✅ Prescriptive precision — zero-hallucination, only report what is found
+- ✅ File:line citation tracing — cite detection signals with specific file paths
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on unit classification — do NOT map exports or integration points yet
+- 🚫 FORBIDDEN to generate skill-brief.yaml in this step
+- 💬 Apply heuristics systematically to each detected boundary
+- 📋 Every classification must cite the detection signals that justify it
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Follow the MANDATORY SEQUENCE exactly
+- 💾 Append "## Identified Units" section to {outputFile}
+- 📖 Update stepsCompleted in {outputFile} frontmatter
+- 🚫 FORBIDDEN to proceed without presenting classifications to user
+
+## CONTEXT BOUNDARIES:
+
+- Available: Project Scan section from report (boundaries, manifests, entry points, configs)
+- Focus: Classification of boundaries into skillable units with scope types
+- Limits: Do not analyze file contents beyond what's needed for classification
+- Dependencies: step-02-scan-project must have populated the Project Scan section
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Load Context
+
+Read {outputFile} to obtain:
+- Project Scan results (detected boundaries, manifests, entry points)
+- `forge_tier` from frontmatter
+- `existing_skills` from frontmatter
+
+Load {heuristicsFile} for classification rules.
+
+### 2. Apply Detection Heuristics
+
+For EACH detected boundary from the scan:
+
+**Step A — Count detection signals:**
+- Check strong signals (independent manifest, separate entry point, Docker config, distinct export surface, workspace member)
+- Check moderate signals (directory depth, naming convention, separate tests, README, CI/CD reference)
+- Check weak signals (large directory, comment boundaries, import clustering)
+
+**Step B — Classify boundary type:**
+- Service Boundary — independent deployable unit
+- Package Boundary — workspace member or independently versioned
+- Module Boundary — logical grouping within a package
+- Library Boundary — third-party with significant project-specific usage
+
+**Step C — Assign scope type:**
+- `full-library` — entire codebase of the unit
+- `specific-modules` — selected components or packages
+- `public-api` — only exported interfaces
+
+**Step D — Check disqualification rules:**
+- Too small (fewer than 3 source files or 100 lines)
+- Generated code
+- Pure configuration
+- Test-only
+- Vendor/dependency copy
+- Already skilled (exists in existing_skills list)
+
+### 3. Build Unit Classification Table
+
+For each candidate that passes disqualification:
+
+| # | Unit Name | Path | Boundary Type | Scope Type | Signals | Confidence | Status |
+|---|-----------|------|---------------|------------|---------|------------|--------|
+| 1 | {name} | {path} | {type} | {scope} | {signal count: strong/moderate/weak} | {high/medium/low} | {new/already-skilled} |
+
+For disqualified candidates, note reason:
+
+**Disqualified:**
+| Path | Reason |
+|------|--------|
+| {path} | {disqualification reason} |
+
+### 4. Detect Primary Language Per Unit
+
+For each qualifying unit, determine the primary programming language based on:
+- File extensions in the unit directory
+- Manifest file type (package.json → JS/TS, Cargo.toml → Rust, go.mod → Go, etc.)
+- Entry point file extension
+
+### 5. Present Classifications
+
+"**Unit Identification Complete**
+
+**Qualifying Units:** {count}
+
+{Classification table}
+
+**Disqualified Candidates:** {count}
+{Disqualification table}
+
+**Already-Skilled Units:** {count from existing_skills match}
+{List with recommendation to run update-skill if source has changed}
+
+**Notes:**
+- {Any observations about project structure patterns}
+- {Any ambiguous boundaries that need user clarification}
+
+Do these classifications look correct? Should any units be added, removed, or reclassified?"
+
+Wait for user feedback. Adjust classifications based on user input.
+
+### 6. Append to Report
+
+Append the complete "## Identified Units" section to {outputFile}:
+
+Replace the placeholder `[Appended by step-03-identify-units]` with:
+- Classification table (qualifying units)
+- Disqualification table
+- Already-skilled units list
+- Language detection results
+- Any user adjustments noted
+
+Update {outputFile} frontmatter:
+```yaml
+stepsCompleted: ['step-01-init', 'step-02-scan-project', 'step-03-identify-units']
+lastStep: 'step-03-identify-units'
+```
+
+### 7. Present MENU OPTIONS
+
+Display: "**Select:** [C] Continue to Export Mapping and Integration Detection"
+
+#### Menu Handling Logic:
+
+- IF C: Save classifications to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
+- IF Any other: help user, then [Redisplay Menu Options](#7-present-menu-options)
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN the Identified Units section has been appended to {outputFile} with complete classification tables, disqualification records, and language detection results, and frontmatter stepsCompleted has been updated, will you load and read fully {nextStepFile} to begin export mapping and integration detection.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Every detected boundary evaluated against heuristics
+- Detection signals cited with specific file paths
+- Scope types assigned to each qualifying unit
+- Disqualification rules applied and documented
+- Existing skills cross-referenced
+- Primary language detected per unit
+- Classifications presented to user for confirmation
+- Report updated with Identified Units section
+
+### ❌ SYSTEM FAILURE:
+
+- Classifying without citing detection signals
+- Missing disqualification checks
+- Not cross-referencing existing_skills
+- Mapping exports or integrations in this step (that's step 04)
+- Generating skill-brief.yaml in this step (that's step 06)
+- Not presenting classifications for user confirmation
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.