@accelerationguy/accel 1.0.0

package/modules/forge/skillsmith/tasks/audit.md

@@ -0,0 +1,277 @@
+<purpose>
+Assess existing skills against Forge syntax specs. Reads a skill's directory structure, checks each component against the corresponding spec, and produces a structured compliance report with violations and remediation priorities.
+</purpose>
+
+<user-story>
+As a skill builder, I want to audit existing skills against the syntax standards so that I can identify compliance gaps and fix them before distribution or deployment.
+</user-story>
+
+<when-to-use>
+- Checking a skill for compliance after building or modifying it
+- Quality gate before distributing a skill via Skool, GitHub, or courses
+- Auditing legacy skills that predate the Forge standards
+- Entry point routes here via /forge audit
+</when-to-use>
+
+<context>
+@rules/entry-point-rules.md
+@rules/tasks-rules.md
+</context>
+
+<references>
+@../specs/entry-point.md (when assessing entry point compliance)
+@../specs/tasks.md (when assessing task files)
+@../specs/templates.md (when assessing template files)
+@../specs/frameworks.md (when assessing framework files)
+@../specs/context.md (when assessing context files)
+@../specs/checklists.md (when assessing checklist files)
+@../specs/rules.md (when assessing rules files)
+</references>
+
+<steps>
+
+<step name="identify_target" priority="first">
+Determine what to audit.
+
+**Ask:**
+1. **Skill path** — Provide the path to a skill directory, or say "batch" to audit all skills in a parent directory.
+
+**Wait for response.**
+
+**Single skill mode:**
+1. Validate the path exists
+2. Locate the entry point file:
+   - Look for `{directory-name}.md` first (spec convention)
+   - Fall back to `SKILL.md`, `skill.md`, or any single `.md` at root
+   - If no entry point found: note as first violation
+3. Confirm: "Auditing `{skill-name}` at `{path}`. Proceed?"
+
+**Batch mode:**
+1. Ask for the parent directory path (e.g., `~/.claude/skills/` or `~/.claude/commands/`)
+2. Discover all subdirectories that appear to be skills (contain `.md` files)
+3. List discovered skills and confirm: "Found {N} skills. Audit all?"
+
+**Wait for confirmation before proceeding.**
+</step>
+
+<step name="inventory_structure">
+Catalog what exists in the skill directory before checking compliance.
+
+1. List all files and subdirectories
+2. Classify each component:
+
+| Component | Present? | Files | Maps to Spec |
+|-----------|----------|-------|-------------|
+| Entry point | Yes/No | {filename} | entry-point.md |
+| tasks/ | Yes/No | {count} files | tasks.md |
+| templates/ | Yes/No | {count} files | templates.md |
+| frameworks/ | Yes/No | {count} files | frameworks.md |
+| context/ | Yes/No | {count} files | context.md |
+| checklists/ | Yes/No | {count} files | checklists.md |
+| rules/ | Yes/No | {count} files | rules.md |
+| {other}/ | Yes/No | {count} files | No spec coverage |
+
+3. Identify the skill tier based on structure:
+   - Has sub-skill entry points at root → `suite`
+   - Has auxiliary folders → `standalone`
+   - Entry point only → `task-only`
+
+4. Note non-standard directories (data/, scripts/, utils/, output/) — these are informational, not violations
+
+5. Skip from audit: `node_modules/`, `output/`, `.git/`, any generated directories
+
+Display the inventory table to establish what will be audited.
+</step>
+
+<step name="assess_entry_point">
+Load @../specs/entry-point.md and check the entry point file against it.
+
+**Check each requirement:**
+
+**1. YAML Frontmatter:**
+- [ ] Frontmatter present (delimited by `---`)
+- [ ] `name` field present and kebab-case
+- [ ] `type` field present and valid (`suite`, `standalone`, `task-only`)
+- [ ] `version` field present and semver format
+- [ ] `category` field present
+- [ ] `description` field present and one-line
+
+**2. XML Sections (check presence and order):**
+- [ ] `<activation>` present with What, When to Use, Not For subsections
+- [ ] `<persona>` present with Role, Style, Expertise subsections
+- [ ] `<commands>` present (if not task-only) with table format
+- [ ] `<routing>` present with Always Load / Load on Command / Load on Demand structure
+- [ ] `<greeting>` present with available actions listed
+
+**3. Conventions:**
+- [ ] Entry point filename matches directory name
+- [ ] Entry point is thin (routing, not process logic)
+- [ ] Placeholders use correct convention ([square]=prose, {curly}=variable)
+- [ ] @-references in routing point to existing files
+
+**Score:** Count checks passed vs total applicable checks.
+- All pass → **Compliant**
+- 70%+ pass → **Partial**
+- Below 70% → **Non-compliant**
+
+Record each failed check with the specific line or section that violates the spec.
+</step>
+
+<step name="assess_folder_types">
+For each folder that maps to a spec, load the corresponding spec and check files.
+
+**For each folder present:**
+
+1. Load the corresponding spec from `@../specs/{folder-type}.md`
+2. Read all files in the folder (if 5 or fewer) or a representative sample (first 3 + last, if more)
+3. Check each file against the spec's requirements
+
+**tasks/ — Check against specs/tasks.md:**
+- [ ] No YAML frontmatter (tasks are execution files)
+- [ ] Has `<purpose>` section
+- [ ] Has `<user-story>` in format: As a [role], I want [action], so that [outcome]
+- [ ] Has `<when-to-use>` with trigger conditions
+- [ ] Has `<steps>` with named steps (`<step name="snake_case">`)
+- [ ] Steps use imperative voice
+- [ ] Steps have explicit wait points where user input needed
+- [ ] Has `<output>` section specifying artifacts
+- [ ] Has `<acceptance-criteria>` as plain checklists (not BDD)
+
+**templates/ — Check against specs/templates.md:**
+- [ ] Has YAML frontmatter with `name` and `description`
+- [ ] Uses placeholder convention consistently
+- [ ] Template is fill-in-ready (not just documentation)
+- [ ] Sections are clearly labeled
+
+**frameworks/ — Check against specs/frameworks.md:**
+- [ ] No YAML frontmatter (frameworks are read-only knowledge)
+- [ ] Has teaching orientation (explains why, not just what)
+- [ ] Has examples grounding the concepts
+- [ ] Structured for on-demand loading (standalone, no cross-dependencies)
+
+**context/ — Check against specs/context.md:**
+- [ ] Has YAML frontmatter (context is the mutable file type)
+- [ ] Clearly scoped to one domain of state
+- [ ] Has default/empty state structure
+- [ ] Designed for session-to-session persistence
+
+**checklists/ — Check against specs/checklists.md:**
+- [ ] Uses checkbox format (`- [ ]` items)
+- [ ] Each item is independently verifiable
+- [ ] Items have clear pass/fail criteria
+- [ ] Organized by concern (not just a flat list)
+
+**rules/ — Check against specs/rules.md:**
+- [ ] Has Must Have section (positive requirements)
+- [ ] Has Anti-Patterns section (what to avoid)
+- [ ] Rules are compact enforcement, not spec copies
+- [ ] Scoped to one consumer folder type
+
+**Score each folder** using the same Compliant / Partial / Non-compliant scale.
+Record specific violations with file:line references where possible.
+</step>
+
+<step name="generate_report">
+Compile all findings into a structured compliance report.
+
+**Report structure:**
+
+```markdown
+# Skill Audit Report: {skill-name}
+
+**Path:** {skill-path}
+**Tier:** {suite/standalone/task-only}
+**Audit Date:** {date}
+**Overall Score:** {N}% ({compliant-count}/{total-audited} components compliant)
+
+---
+
+## Summary
+
+| Component | Spec | Status | Issues |
+|-----------|------|--------|--------|
+| Entry point | entry-point.md | {Compliant/Partial/Non-compliant} | {N} |
+| tasks/ | tasks.md | {status} | {N} |
+| templates/ | templates.md | {status} | {N} |
+| frameworks/ | frameworks.md | {status} | {N} |
+| context/ | context.md | {status} | {N} |
+| checklists/ | checklists.md | {status} | {N} |
+| rules/ | rules.md | {status} | {N} |
+
+**Non-standard folders:** {list any unaudited folders}
+
+---
+
+## Violations Detail
+
+### Entry Point
+{For each failed check: what's wrong, where, and how to fix it}
+
+### tasks/
+{Per-file violations}
+
+### {each folder with issues}
+{Per-file violations}
+
+---
+
+## Remediation Priorities
+
+Priority order (fix these first):
+1. {Highest impact — entry point structural issues}
+2. {Next highest — missing required sections in tasks}
+3. {Lower priority — convention violations}
+
+---
+
+*Generated by /forge audit*
+```
+
+**Ask:** "Where should I save this report?"
+- Default: `{skill-path}/{skill-name}-AUDIT.md`
+- User can specify alternate location
+
+**Wait for response, then write the report.**
+
+**For batch mode:**
+After all individual reports, generate a rollup:
+
+```markdown
+# Batch Audit Summary
+
+**Directory:** {parent-path}
+**Skills Audited:** {N}
+**Date:** {date}
+
+| Skill | Tier | Score | Top Issue |
+|-------|------|-------|-----------|
+| {name} | {tier} | {N}% | {brief description} |
+
+**Cross-cutting issues:** {patterns that appear in multiple skills}
+**Highest priority:** {which skill needs the most work}
+```
+
+Save rollup to `{parent-path}/AUDIT-SUMMARY.md`.
+</step>
+
+</steps>
+
+<output>
+## Artifacts
+- Individual audit report: `{skill-name}-AUDIT.md` (per skill)
+- Batch summary: `AUDIT-SUMMARY.md` (batch mode only)
+
+## Format
+Markdown report with summary table, per-component violations, and prioritized remediation list.
+</output>
+
+<acceptance-criteria>
+- [ ] Target skill path validated and entry point located
+- [ ] Skill structure inventoried with folder-to-spec mapping
+- [ ] Entry point assessed against entry-point.md spec
+- [ ] Each present folder assessed against its corresponding spec
+- [ ] Compliance scored per component (Compliant / Partial / Non-compliant)
+- [ ] Violations recorded with specific details and file references
+- [ ] Report generated with summary table and remediation priorities
+- [ ] User confirmed report location
+</acceptance-criteria>

package/modules/forge/skillsmith/tasks/discover.md

@@ -0,0 +1,145 @@
+<purpose>
+Guided conversational interview that captures all design decisions needed to scaffold a new Claude Code skill. Produces a structured skill spec as output.
+</purpose>
+
+<user-story>
+As a skill builder, I want a structured interview that walks me through every design decision so that I get a complete skill spec without missing anything or guessing at conventions.
+</user-story>
+
+<when-to-use>
+- Creating a new skill from scratch
+- Documenting an existing skill's design for future scaffolding
+- Exploring what a skill should look like before building it
+</when-to-use>
+
+<context>
+@specs/entry-point.md
+</context>
+
+<references>
+@specs/tasks.md (when discussing task structure)
+@specs/templates.md (when discussing template structure)
+@specs/frameworks.md (when discussing framework structure)
+@specs/context.md (when discussing context structure)
+@specs/checklists.md (when discussing checklist structure)
+@specs/rules.md (when discussing rules — meta-skill only)
+</references>
+
+<steps>
+
+<step name="phase-1-identity" label="Identity">
+Capture the skill's core identity. Ask as a group, wait for responses.
+
+**Ask:**
+1. **Skill name** — What should this skill be called? (kebab-case, e.g., `revops-expert`)
+2. **Type** — What tier?
+   - `suite` — Orchestrator with sub-skills (e.g., forge itself)
+   - `standalone` — Single skill with auxiliary folders (most common)
+   - `task-only` — Lightweight single-purpose, no auxiliary folders
+3. **Category** — What domain? (common: operations, content, development, design, analysis)
+4. **Description** — One sentence: what does this skill do?
+
+**Validate:**
+- Name must be kebab-case (lowercase, hyphens only)
+- Type must be one of: suite, standalone, task-only
+- Description should be one line, action-oriented
+
+**After responses:** Confirm back: "Got it — `{name}` is a `{type}` skill in `{category}`: {description}. Correct?"
+</step>
+
+<step name="phase-2-persona" label="Persona">
+Define who this skill acts as. Ask as a group, wait for responses.
+
+**Ask:**
+1. **Role** — Who does this skill act as? (e.g., "Senior revenue operations strategist", "Content pipeline manager")
+2. **Style** — How does it communicate? Pick or describe:
+   - Structured / casual / opinionated / minimal / technical / conversational
+   - Any specific behaviors (e.g., "uses frameworks by name", "challenges weak inputs")
+3. **Expertise** — What domains does it know deeply? List 2-5 areas.
+
+**After responses:** Summarize persona in 3 bullets (role, style, expertise) and confirm.
+</step>
+
+<step name="phase-3-scope" label="Scope & Commands">
+Define what the skill does and doesn't do, plus its command structure.
+
+**Ask:**
+1. **What** — What does this skill do? (1-2 sentences for the activation section)
+2. **When to Use** — When should someone reach for this skill? (list 2-4 triggers)
+3. **Not For** — What is explicitly NOT this skill's job? (list 1-3 boundaries, reference other skills if applicable)
+4. **Commands** (skip for task-only):
+   - What actions/workflows does this skill offer?
+   - For each: command name, brief description, what it routes to
+
+**After responses:** Display activation scope and command table for confirmation.
+</step>
+
+<step name="phase-4-content-architecture" label="Content Architecture">
+Walk through each auxiliary folder type to determine what the skill needs.
+
+**For each folder type below, ask:** "Does this skill need [type]? If yes, what files?"
+
+**Tasks** (`tasks/*.md`):
+- What guided workflows does this skill perform?
+- For each: file name (kebab-case), purpose, loading condition (on-command)
+
+**Frameworks** (`frameworks/*.md`):
+- What domain knowledge does this skill carry?
+- For each: file name, what it teaches, loading condition (on-demand typical)
+
+**Templates** (`templates/*.md`):
+- What structured outputs does this skill produce?
+- For each: file name, what it generates
+
+**Context** (`context/*.md`):
+- What user or business state does this skill need to remember between sessions?
+- For each: file name, what it stores, loading condition (always typical for context)
+
+**Checklists** (`checklists/*.md`):
+- What quality gates does this skill enforce?
+- For each: file name, what it validates
+
+**Note:** Rules folder is meta-skill only (Forge carries rules, individual skills don't).
+
+**After each "yes":** Capture file name, purpose, and loading condition.
+**After all types reviewed:** Display content architecture summary table and confirm.
+</step>
+
+<step name="phase-5-review" label="Review & Confirm">
+Present the complete skill spec for final review.
+
+1. Generate the full skill spec using @templates/skill-spec.md format
+2. Display it to the user with all captured decisions filled in
+3. Ask: "Does this look right? Say **confirm** to finalize, or tell me what to change."
+
+**On confirm:**
+- Output the finalized skill spec
+- Report: "Skill spec complete. Run `/forge scaffold` to generate the directory. (Phase 3)"
+
+**On edit requests:**
+- Apply changes to the spec
+- Re-display affected sections
+- Re-confirm
+</step>
+
+</steps>
+
+<output>
+Filled skill spec following templates/skill-spec.md format, containing:
+- Identity (name, type, category, description)
+- Persona (role, style, expertise)
+- Activation scope (what, when, not for)
+- Commands table
+- Content architecture (tasks, frameworks, templates, context, checklists with file names and loading conditions)
+</output>
+
+<acceptance-criteria>
+- [ ] All 5 phases completed in order
+- [ ] Skill name validated as kebab-case
+- [ ] Skill type is one of: suite, standalone, task-only
+- [ ] Persona captured with role, style, expertise
+- [ ] Activation scope has What, When to Use, and Not For
+- [ ] Each auxiliary folder type explicitly addressed (yes with details, or no)
+- [ ] Skill spec output generated with all fields populated
+- [ ] User confirmed the final spec
+</acceptance-criteria>

package/modules/forge/skillsmith/tasks/distill.md

@@ -0,0 +1,276 @@
+<purpose>
+Transform raw source material (books, courses, transcripts, notes) into structured framework chunks ready for skill consumption. Reads source content, designs a chunking architecture, extracts discrete framework chunks, and validates output against framework syntax rules.
+</purpose>
+
+<user-story>
+As a skill builder, I want to turn raw knowledge sources into structured, skill-ready framework chunks so that my skills can reference clean domain knowledge instead of wading through raw text.
+</user-story>
+
+<when-to-use>
+- You have a book, course transcript, or raw notes that need to become framework files
+- Building the knowledge layer for a new or existing skill
+- Entry point routes here via /forge distill
+</when-to-use>
+
+<context>
+@rules/frameworks-rules.md
+</context>
+
+<references>
+@../specs/frameworks.md (framework syntax spec — output format rules)
+</references>
+
+<steps>
+
+<step name="assess_source" priority="first">
+Understand the raw material before planning how to chunk it.
+
+**Ask:**
+1. **Source material** — Provide the file path(s) or paste the content. What is this? (book, course, transcript, notes, article collection)
+2. **Target skill** — Which skill will consume these frameworks? (existing skill name, or "new skill — not yet built")
+3. **Output location** — Where should chunks land? (default: `{skill-name}/frameworks/chunks/`)
+
+**Wait for response.**
+
+Once source is provided:
+
+1. Read the source material fully
+2. Assess structure:
+   - How is it organized? (chapters, sections, modules, flat)
+   - Approximate size (lines, pages, word count)
+   - How many distinct concepts/frameworks are present?
+3. Identify the natural seams — where does one concept end and another begin?
+4. Check for existing chunking:
+   - Does a chunking plan already exist for this source?
+   - Are there partial chunks already extracted?
+
+**Report:**
+```
+Source: {title/description}
+Type: {book/course/transcript/notes}
+Size: ~{N} lines / ~{N} pages
+Structure: {chapters/sections/modules/flat}
+Estimated concepts: {N}
+Existing work: {none / partial — describe}
+```
+
+**Confirm:** "Ready to design the chunking plan?"
+</step>
+
+<step name="create_chunking_plan">
+Design the chunk architecture — how to break the source into discrete, skill-ready pieces.
+
+**Principles:**
+- Group by **functional outcome** (what the chunk helps you DO), not by source structure (chapters)
+- Each chunk should be independently useful — loadable without needing other chunks
+- Target 5-15 chunks per source (fewer than 5 = too coarse, more than 15 = too granular)
+- Name chunks by concept, not by source chapter number
+
+**For each proposed chunk, define:**
+
+| Field | Description |
+|-------|-------------|
+| **Number** | Sequential ID (01, 02, ...) |
+| **Name** | Concept-based name (kebab-case for filename, title case for display) |
+| **Source range** | Which sections/chapters/lines this covers |
+| **Frameworks to extract** | List of specific frameworks, models, or templates in this chunk |
+| **Skill output** | What this chunk enables — one sentence describing the actionable outcome |
+
+**Present the chunking plan as a table:**
+
+```
+| # | Chunk Name | Source Range | Core Frameworks | Skill Output |
+|---|-----------|-------------|-----------------|--------------|
+| 1 | {name}    | {range}     | {frameworks}    | {output}     |
+```
+
+**Write the chunking plan** to `{output-location}/../{source-name}-chunks.md` following the proven format from the Expert Secrets chunking plan.
+
+**Ask:** "Does this chunking architecture look right? Any chunks to merge, split, or rename?"
+
+**Wait for approval before extracting.**
+</step>
+
+<step name="extract_chunks">
+Extract each chunk from the source into a standalone framework file.
+
+**For each chunk in the approved plan:**
+
+1. Read the relevant source range
+2. Distill into the standard chunk format:
+
+```markdown
+# Chunk {N}: {Display Name}
+## Source: {Source Title} — {Section/Chapter Reference}
+
+---
+
+## Core Concept
+
+[2-4 sentence synthesis of the central idea. Not a summary — a distillation
+that captures the essence someone needs to understand before diving into
+frameworks. Written in teaching voice.]
+
+---
+
+## Frameworks
+
+### Framework: {Framework Name}
+
+**When to use:** [Specific trigger condition — when should this framework be applied?]
+
+**Steps/Template:**
+
+[The actual framework content — steps, tables, templates, fill-ins.
+Structured for immediate application, not academic understanding.
+Include tables for comparisons, code blocks for fill-in templates,
+numbered steps for processes.]
+
+**Example from source:** [Concrete example that illustrates the framework in action]
+
+---
+
+[Repeat ### Framework for each framework in this chunk]
+
+## Key Principles
+
+- [Distilled principle 1 — actionable, not abstract]
+- [Distilled principle 2]
+- [Distilled principle 3]
+
+---
+
+## Templates and Fill-Ins
+
+[Consolidated fill-in templates from this chunk's frameworks.
+Use fenced code blocks with bracket placeholders for user input.]
+
+---
+
+## Decision Tools
+
+[IF/THEN decision logic extracted from the source.
+Help the user make choices without re-reading the full framework.]
+
+---
+
+*Chunk {N} of {total} — {Source Title} Framework Reference*
+```
+
+**Chunk quality rules:**
+- Core Concept is a synthesis, not a copy-paste summary
+- Frameworks have **When to use** triggers (not just what they are)
+- Templates use `[_______________]` fill-in blanks for user input
+- Decision Tools use `IF/THEN` logic for quick application
+- Each chunk stands alone — no "see Chunk 3 for details" cross-references
+- Key Principles are actionable statements, not vague platitudes
+- Include source examples where they illustrate the framework
+
+3. Write each chunk to `{output-location}/{NN}-{chunk-name}.md`
+4. After each chunk, briefly report: "Chunk {N}/{total}: {name} — {frameworks extracted} frameworks"
+
+**Do NOT rush.** Each chunk is a knowledge artifact that will be referenced many times. Quality over speed.
+</step>
+
+<step name="build_consolidated_framework">
+Create a single consolidated framework file that ties all chunks together.
+
+**This is optional but recommended for sources with 5+ chunks.**
+
+Create `{output-location}/../{source-name}.md` (the parent framework file):
+
+```markdown
+# {Source Title} — Framework Reference
+
+## Purpose
+[What this framework collection teaches and when to reference it]
+
+## Chunk Index
+
+| # | Chunk | Key Frameworks | Load When |
+|---|-------|---------------|-----------|
+| 1 | {name} | {frameworks} | {trigger condition} |
+| 2 | {name} | {frameworks} | {trigger condition} |
+
+## Quick Reference
+
+### Decision Tree
+[High-level decision tree that routes to the right chunk based on what the user needs]
+
+### Framework Inventory
+[Complete list of all frameworks across all chunks with chunk reference]
+```
+
+**Ask:** "Consolidated framework created. Want to review it, or proceed to validation?"
+</step>
+
+<step name="validate_output">
+Validate all generated files against framework rules.
+
+1. Load @rules/frameworks-rules.md
+2. For each chunk file, verify:
+   - [ ] No YAML frontmatter (frameworks are read-only knowledge)
+   - [ ] Has Core Concept section (purpose/synthesis)
+   - [ ] Has at least one Framework with "When to use" trigger
+   - [ ] Frameworks teach (not prescribe) — teaching orientation
+   - [ ] Has examples (not abstract-only)
+   - [ ] File named kebab-case: `{NN}-{chunk-name}.md`
+   - [ ] Stands alone without cross-chunk dependencies
+3. If consolidated framework exists, verify:
+   - [ ] Has Purpose section
+   - [ ] Has Chunk Index with load triggers
+   - [ ] Has Quick Reference / Decision Tree
+
+**Report:**
+```
+Distillation Complete: {source-title}
+
+Chunks: {N} extracted
+Location: {output-location}/
+Consolidated: {yes/no} at {path}
+
+Validation: {N}/{N} chunks pass rules
+
+Files:
+- {NN}-{chunk-name}.md ({N} frameworks)
+- {NN}-{chunk-name}.md ({N} frameworks)
+- ...
+- {source-name}.md (consolidated index)
+
+Next steps:
+1. Review chunks for domain accuracy (you know the source better than I do)
+2. Add chunks to your skill's routing as on-demand framework references
+3. Test by asking the skill to apply a specific framework
+```
+</step>
+
+</steps>
+
+<output>
+## Artifacts
+- Chunking plan: `{source-name}-chunks.md`
+- Individual chunks: `chunks/{NN}-{chunk-name}.md` (one per chunk)
+- Consolidated framework: `{source-name}.md` (optional, for 5+ chunks)
+
+## Structure
+```
+{skill-name}/frameworks/
+├── {source-name}.md              (consolidated index)
+├── {source-name}-chunks.md       (chunking plan)
+└── chunks/
+    ├── 01-{chunk-name}.md
+    ├── 02-{chunk-name}.md
+    └── ...
+```
+</output>
+
+<acceptance-criteria>
+- [ ] Source material fully read and assessed
+- [ ] Chunking plan created with concept-based groupings (not chapter-based)
+- [ ] Each chunk follows the standard format (Core Concept, Frameworks with triggers, Templates, Decision Tools)
+- [ ] All chunks stand alone without cross-chunk dependencies
+- [ ] Chunk files named kebab-case with sequential numbering
+- [ ] Consolidated framework created (if 5+ chunks)
+- [ ] All files pass frameworks-rules.md validation
+- [ ] User reviewed and approved chunking plan before extraction
+</acceptance-criteria>