@accelerationguy/accel 1.0.0

package/modules/drive/src/workflows/verify-work.md

@@ -0,0 +1,241 @@
+<purpose>
+Guide manual user acceptance testing of recently built features. Extract deliverables from SUMMARY.md, generate test checklist, guide user through each test, log issues to phase-scoped file.
+
+The USER performs all testing — Claude generates the checklist, guides the process, and captures issues.
+</purpose>
+
+<template>
+@src/templates/UAT-ISSUES.md
+</template>
+
+<process>
+
+<step name="identify">
+**Determine what to test:**
+
+If $ARGUMENTS provided:
+- Parse as phase number (e.g., "4") or plan number (e.g., "04-02")
+- Find corresponding SUMMARY.md file(s)
+
+If no arguments:
+- Find most recently modified SUMMARY.md
+
+```bash
+find .drive/phases -name "*SUMMARY.md" -type f -exec ls -lt {} + | head -5
+```
+
+Read the SUMMARY.md to understand what was built.
+
+Key extraction points:
+- Acceptance Criteria results
+- Files created/modified
+- Deviations (if any)
+</step>
+
+<step name="extract">
+**Extract testable deliverables from SUMMARY.md:**
+
+Parse for:
+1. **Acceptance Criteria** - Each AC becomes a test item
+2. **Files Created/Modified** - What changed
+3. **User-facing changes** - UI, workflows, interactions
+
+Focus on USER-OBSERVABLE outcomes, not implementation details.
+
+Map AC to tests:
+- AC-1: "Feature X exists" → User can see/use Feature X
+- AC-2: "Behavior Y works" → User can trigger and verify Behavior Y
+</step>
+
+<step name="generate">
+**Generate manual test checklist:**
+
+Create structured test plan:
+
+```
+# User Acceptance Test: [Plan Name]
+
+**Scope:** [What was built - from SUMMARY.md]
+**Source:** [path to SUMMARY.md]
+**Testing:** Manual user validation
+
+## Pre-flight
+- [ ] Application builds and runs without errors
+- [ ] Application launches to expected state
+
+## Acceptance Criteria Tests
+
+### AC-1: [Criteria from plan]
+**What to test:** [User-observable behavior]
+**Steps:**
+1. [Specific action to take]
+2. [What to look for]
+3. [Expected result]
+
+### AC-2: [Criteria from plan]
+...
+
+## Edge Cases
+- [ ] [Relevant edge case based on feature]
+- [ ] [Another edge case]
+
+## Visual/UX Check
+- [ ] UI matches expected design
+- [ ] No visual glitches or layout issues
+```
+
+Present this checklist to user.
+</step>
+
+<step name="guide">
+**Guide user through each test:**
+
+For each test item, use AskUserQuestion:
+- header: "[AC-N or Feature name]"
+- question: "[Test description] - Did this work as expected?"
+- options:
+  - "Pass" — Works correctly
+  - "Fail" — Doesn't work as expected
+  - "Partial" — Works but with issues
+  - "Skip" — Can't test right now
+
+**If Pass:** Move to next test
+
+**If Fail or Partial:**
+Follow up with AskUserQuestion:
+- header: "Issue details"
+- question: "What went wrong?"
+- options:
+  - "Crashes/errors" — Application error or exception
+  - "Wrong behavior" — Does something unexpected
+  - "Missing feature" — Expected functionality not present
+  - "UI/visual issue" — Looks wrong but functions
+  - "Let me describe" — Free-form description needed
+</step>
+
+<step name="collect">
+**Collect and categorize issues:**
+
+For each failed/partial test, gather:
+- Feature/AC affected
+- What went wrong (from user input)
+- Severity:
+  - **Blocker** — Can't use the feature at all
+  - **Major** — Feature works but significant problem
+  - **Minor** — Small issue, feature still usable
+  - **Cosmetic** — Visual only, no functional impact
+</step>
+
+<step name="log">
+**Log issues to phase-scoped file:**
+
+If any issues found:
+
+1. Create `.drive/phases/XX-name/{phase}-{plan}-UAT.md` if doesn't exist
+2. Use template from `@src/templates/UAT-ISSUES.md`
+3. Add each issue with UAT-NNN format:
+
+```markdown
+### UAT-001: [Brief description]
+
+**Discovered:** [date] during user acceptance testing
+**Phase/Plan:** [phase]-[plan] that was tested
+**Severity:** [Blocker/Major/Minor/Cosmetic]
+**AC:** [Which acceptance criteria this relates to]
+**Description:** [User's description of the problem]
+**Expected:** [What should have happened]
+**Actual:** [What actually happened]
+```
+
+**Note:** Issues go to phase-scoped UAT file, NOT global `.drive/ISSUES.md`.
+</step>
+
+<step name="summarize">
+**Present test summary:**
+
+```
+# Test Results: [Plan Name]
+
+**Tests run:** [N]
+**Passed:** [N]
+**Failed:** [N]
+**Partial:** [N]
+**Skipped:** [N]
+
+## Issues Found
+[List any issues with severity]
+
+## Verdict
+[Based on results:]
+- ALL PASS: "All tests passed. Feature validated."
+- MINOR ISSUES: "Feature works with minor issues logged."
+- MAJOR ISSUES: "Significant issues found - review before proceeding."
+- BLOCKERS: "Blocking issues found - must fix before continuing."
+
+## Next Steps
+[Based on verdict:]
+- If clean: Suggest proceeding to next phase/plan
+- If issues: Suggest creating FIX plan to address
+```
+</step>
+
+<step name="offer">
+**Offer next actions based on results:**
+
+Use AskUserQuestion:
+- header: "Next"
+- question: "What would you like to do?"
+- options (based on results):
+
+If all passed:
+- "Continue" — Proceed with confidence
+- "Test more" — Run additional manual tests
+- "Done" — Finish testing session
+
+If issues found:
+
+**Diagnostic classification — classify before fixing, instead of jumping to code patches, because fixing the wrong layer wastes loops and produces fragile patches:**
+
+Use AskUserQuestion:
+- header: "Classify Issues"
+- question: "Before planning fixes, what went wrong?"
+- options:
+  - "Intent issue" — The feature needs to work differently than planned
+  - "Spec issue" — The plan missed a requirement or got something wrong
+  - "Code issue" — The plan was right, the code doesn't match
+  - "Log and continue" — Issues logged, proceed without fixing now
+  - "Review issues" — Look at logged issues in detail
+
+**Routing per classification:**
+
+**Intent (1):** "Let's re-plan with updated intent."
+- Route to `/drive:plan` for affected phase with updated intent
+- Previous plan's issues inform the re-plan
+- Do NOT create a fix plan — the spec itself needs rethinking
+
+**Spec (2):** "The plan needs updating before we fix code."
+- Route to `/drive:plan-fix` with spec-level scope
+- Identify which ACs or tasks need revision
+- Update the plan FIRST, then generate code fixes from the corrected spec
+- This prevents patching code against a wrong spec
+
+**Code (3):** "Standard fix — plan was right, code needs patching."
+- Route to `/drive:plan-fix` with code-level scope (existing behavior)
+- Generate targeted fix plan from UAT issues
+
+**Log and continue (4):** Issues logged, proceed anyway (existing behavior)
+
+**Review issues (5):** Show logged issues in detail (existing behavior)
+</step>
+
+</process>
+
+<success_criteria>
+- [ ] Test scope identified from SUMMARY.md
+- [ ] Checklist generated based on acceptance criteria
+- [ ] User guided through each test via AskUserQuestion
+- [ ] All test results captured (pass/fail/partial/skip)
+- [ ] Any issues logged to phase-scoped UAT file
+- [ ] Summary presented with verdict
+- [ ] User knows next steps based on results
+</success_criteria>

package/modules/forge/README.md

@@ -0,0 +1,281 @@
+<div align="center">
+  <img src="terminal.svg" alt="Forge terminal" width="740"/>
+</div>
+
+<div align="center">
+
+# Forge
+
+**Build consistent Claude Code skills using standardized syntax and guided workflows.**
+
+[![Claude Code](https://img.shields.io/badge/Claude%20Code-compatible-8b5cf6?style=flat-square)](https://claude.ai/code)
+[![License](https://img.shields.io/badge/license-MIT-blue?style=flat-square)](LICENSE)
+
+</div>
+
+---
+
+## Contents
+
+- [What Forge Does](#what-forge-does)
+- [Commands](#commands)
+- [The Problem](#the-problem)
+- [How It Works](#how-it-works)
+- [Architecture](#architecture)
+- [Syntax Specs](#syntax-specs)
+- [Ecosystem](#ecosystem)
+- [Install](#install)
+
+---
+
+## What Forge Does
+
+Claude Code skills are markdown files that give Claude a persona, routing logic, and domain knowledge. They're powerful — but there's no standard for how to write them. Every skill looks different. Entry points mix routing with process logic. Tasks miss required sections. Templates use inconsistent placeholders. When you share a skill, someone else has to reverse-engineer your conventions.
+
+Forge fixes this. It's a meta-skill — a skill that builds other skills — with four workflows:
+
+1. **Discover** — Guided interview that captures every design decision and produces a structured skill spec
+2. **Scaffold** — Takes a skill spec and generates a compliant directory with all files following syntax standards
+3. **Distill** — Transforms raw source material (books, courses, transcripts) into structured framework chunks ready for skill consumption
+4. **Audit** — Checks existing skills against the syntax specs and produces a compliance report with remediation priorities
+
+The result: skills that are consistent, portable, and immediately understandable by anyone who reads them.
+
+---
+
+## Commands
+
+| Command | What It Does |
+|---------|-------------|
+| `/forge` | Show available workflows |
+| `/forge discover` | Guided interview to design a new skill — produces a skill spec |
+| `/forge scaffold` | Generate a compliant skill directory from a spec |
+| `/forge distill` | Transform raw source material into framework chunks |
+| `/forge audit` | Audit skill compliance against syntax specs |
+
+---
+
+## The Problem
+
+Claude Code's slash command system is a superpower. Drop markdown files in `.claude/commands/` and Claude gets new capabilities — personas, workflows, domain knowledge, quality gates. But there's no enforced structure. Skills built without conventions end up with:
+
+- **Entry points doing too much.** Routing mixed with process logic. Bloated files that Claude loads entirely even when you only need one command.
+- **Inconsistent file types.** Tasks that look like frameworks. Templates without placeholder conventions. Context files that never get updated.
+- **Missing sections.** No acceptance criteria. No user stories. No "Not For" boundaries. Claude interprets vaguely and produces inconsistent results.
+- **No portability.** Your skill works in your workspace because you know the conventions. Someone else installs it and gets confused immediately.
+
+Forge defines seven file types — entry points, tasks, templates, frameworks, context, checklists, and rules — each with a syntax spec. The specs define what sections are required, what format they use, and what anti-patterns to avoid. Then it gives you workflows to build skills that follow those specs from the start.
+
+---
+
+## How It Works
+
+### Discovery Flow
+
+```
+/forge discover
+      │
+      ▼
+  Identity ──▶ Persona ──▶ Scope ──▶ Content ──▶ Review
+  (name,type)  (role,style) (commands)  Architecture  (confirm)
+      │                                    │
+      ▼                                    ▼
+  "revops-expert"               tasks: 3, frameworks: 5,
+  standalone, operations        templates: 2, context: 1
+                                           │
+                                           ▼
+                                    SKILL-SPEC.md
+```
+
+Discovery asks one question group at a time, validates as it goes, and produces a structured spec. No guessing at conventions — the interview covers every decision.
+
+### Scaffold Flow
+
+```
+/forge scaffold
+      │
+      ▼
+  Read spec ──▶ Choose ──▶ Create ──▶ Generate ──▶ Validate
+  (parse all    location    dirs       all files    against
+   sections)    (apps/,              (entry point,  rules
+                local,                tasks,
+                custom)               frameworks...)
+                                          │
+                                          ▼
+                                  Complete skill directory
+                                  ready to customize
+```
+
+Scaffold reads a skill spec and generates every file with meaningful scaffolded content — not empty shells. Entry points get proper YAML frontmatter and all five XML sections. Tasks get purpose, user story, steps with wait points, and acceptance criteria. For skills with 10+ files, it offers a Drive-managed phased build.
+
+### Distill Flow
+
+```
+/forge distill
+      │
+      ▼
+  Assess source ──▶ Chunking plan ──▶ Extract chunks ──▶ Validate
+  (read material,    (concept-based,   (core concept,     (framework
+   estimate scope)    not chapters)      frameworks,        rules
+                                         templates,         compliance)
+                                         decision tools)
+```
+
+Distill takes raw knowledge — a book, a course transcript, collected notes — and turns it into structured framework chunks. Each chunk stands alone, has a core concept synthesis (not a summary), frameworks with "When to use" triggers, fill-in templates, and IF/THEN decision tools.
+
+### Audit Flow
+
+```
+/forge audit [path]
+      │
+      ▼
+  Inventory ──▶ Entry point ──▶ Each folder ──▶ Report
+  structure      assessment       vs its spec    (compliance %,
+  (classify      (frontmatter,    (tasks.md,     violations,
+   components)    5 XML sections,  frameworks.md, remediation
+                  conventions)     templates.md)  priorities)
+```
+
+Audit reads an existing skill, checks every file against its corresponding syntax spec, and produces a scored compliance report. Supports single skill or batch mode across an entire commands directory.
+
+---
+
+## Architecture
+
+```
+forge/
+├── forge/                     The skill itself
+│   ├── forge.md               Entry point (Forge-compliant, naturally)
+│   ├── tasks/
+│   │   ├── discover.md             5-phase guided interview
+│   │   ├── scaffold.md             Spec-to-directory generator
+│   │   ├── distill.md              Source material chunker
+│   │   └── audit.md                Compliance checker
+│   ├── rules/                      Authoring rules per file type
+│   │   ├── entry-point-rules.md    Entry point validation rules
+│   │   ├── tasks-rules.md          Task file validation rules
+│   │   ├── frameworks-rules.md     Framework file validation rules
+│   │   ├── templates-rules.md      Template file validation rules
+│   │   ├── context-rules.md        Context file validation rules
+│   │   └── checklists-rules.md     Checklist file validation rules
+│   └── templates/
+│       └── skill-spec.md           Output format for discovery
+├── specs/                          Syntax specifications (reference docs)
+│   ├── entry-point.md              How to write entry points
+│   ├── tasks.md                    How to write task files
+│   ├── frameworks.md               How to write framework files
+│   ├── templates.md                How to write template files
+│   ├── context.md                  How to write context files
+│   ├── checklists.md               How to write checklist files
+│   └── rules.md                    How to write rules (meta-skill only)
+├── bin/
+│   └── install.js                  npm installer
+├── package.json
+└── README.md
+```
+
+**Two layers by design:**
+- **`forge/`** — The operational skill. Tasks, rules, templates. This is what Claude loads and executes.
+- **`specs/`** — Reference documentation. The syntax specifications that define how each file type should be written. Tasks and audits reference these on-demand — they're never loaded upfront.
+
+Rules vs Specs: Rules are compact enforcement checklists ("must have X, anti-pattern Y"). Specs are the full documentation ("here's what X means, here's why, here are examples"). The audit task loads rules for fast checking. The scaffold task loads specs for correct generation.
+
+---
+
+## Syntax Specs
+
+Forge defines seven file types. Each has a syntax specification that defines structure, conventions, and anti-patterns.
+
+| File Type | Purpose | Mutable? | Frontmatter? |
+|-----------|---------|----------|--------------|
+| **Entry Point** | Identity + routing | No | Yes (YAML) |
+| **Task** | Guided workflow | No | No |
+| **Framework** | Domain knowledge | No | No |
+| **Template** | Structured output | No | Yes (YAML) |
+| **Context** | User/business state | Yes | No |
+| **Checklist** | Quality gate | No | No |
+| **Rules** | Validation rules | No | Yes (YAML) |
+
+### Placeholder Conventions
+
+Every skill built with Forge uses consistent placeholders:
+
+| Syntax | Meaning | Example |
+|--------|---------|---------|
+| `{curly-braces}` | Variable interpolation — replaced with exact input | `{skill-name}` becomes `revops-expert` |
+| `[square-brackets]` | Human-written prose — replaced with descriptive text | `[role definition]` becomes `Senior revenue operations strategist` |
+
+### Skill Tiers
+
+| Tier | Structure | When to Use |
+|------|-----------|-------------|
+| `suite` | Orchestrator with sub-commands | Multi-workflow tools (Forge itself) |
+| `standalone` | Single skill with auxiliary folders | Most skills |
+| `task-only` | Entry point only, no auxiliary folders | Lightweight single-purpose |
+
+---
+
+## Ecosystem
+
+Forge is part of a broader Claude Code extension ecosystem:
+
+| System | What It Does | Link |
+|--------|-------------|------|
+| **Radar** | Multi-agent codebase auditing — diagnosis + controlled evolution | [GitHub](https://github.com/accelerationguy/radar) |
+| **Momentum** | Builder's Automated State Engine — workspace lifecycle, health tracking, drift prevention | [GitHub](https://github.com/accelerationguy/base) |
+| **Vector** | Context Augmentation & Reinforcement Layer — dynamic rules loaded JIT by intent | [GitHub](https://github.com/accelerationguy/vector) |
+| **Drive** | Project orchestration — Plan, Apply, Unify Loop | [GitHub](https://github.com/accelerationguy/drive) |
+| **Ignition** | Typed project incubator — guided ideation through graduation | [GitHub](https://github.com/accelerationguy/ignition) |
+| **Forge** | Skill builder — standardized syntax specs + guided workflows | You are here |
+| **CC Strategic AI** | Skool community — courses, community, live support | [Skool](https://accelerationguy.com) |
+
+All tools are standalone. Ignition was built with Forge. Scaffold can optionally hand off to Drive for phased builds. No dependencies required.
+
+---
+
+## Install
+
+```bash
+npx @accel/forge
+```
+
+One command. Installs the skill to `~/.claude/commands/forge/` — available in every workspace.
+
+```bash
+# Global install (default) — available everywhere
+npx @accel/forge
+
+# Install to current project only
+npx @accel/forge --local
+
+# Custom Claude config directory
+npx @accel/forge --config-dir /path/to/.claude
+```
+
+Then open Claude Code and type `/forge` to start.
+
+### What Gets Installed
+
+```
+~/.claude/
+├── commands/forge/
+│   ├── forge.md        Entry point (routing + persona)
+│   ├── tasks/               4 task files (discover, scaffold, distill, audit)
+│   ├── rules/               6 authoring rule files
+│   └── templates/           Skill spec output template
+└── forge-specs/
+    └── 7 syntax specifications (entry-point, tasks, templates, etc.)
+```
+
+No hooks, no MCP servers, no workspace data. Forge is pure markdown — zero runtime dependencies.
+
+### Requirements
+
+- [Claude Code](https://claude.ai/code)
+- Node.js >= 16 (for install script only — Forge itself has no runtime deps)
+
+---
+
+## License
+
+MIT — [Acceleration Guy](https://github.com/accelerationguy)