@accelerationguy/accel 1.0.0

package/docs/getting-started.md

@@ -0,0 +1,164 @@
+# Getting Started with Accelerate
+
+Welcome to **Accelerate** — a unified Claude Code agent framework by Acceleration Guy.
+
+## Installation
+
+### Quick Install (all modules)
+
+```bash
+npx @accel/cli
+```
+
+Press Enter at the module selection screen to install everything. That's it.
+
+### Non-Interactive Install
+
+```bash
+npx @accel/cli --all --non-interactive
+```
+
+### Check What's Installed
+
+```bash
+npx @accel/cli status
+```
+
+## Requirements
+
+- **Claude Code** — Accelerate extends Claude Code with structured workflows
+- **Node.js >= 16** — for the installer
+- **Python >= 3.9** — only needed if you install Vector or Momentum (they use Python hooks)
+
+## Your First 5 Minutes
+
+After installing, restart Claude Code and try these:
+
+### 1. Check status
+```
+/accel status
+```
+Shows all installed modules and their health.
+
+### 2. Start a new project
+```
+/ignition
+```
+Ignition walks you through collaborative ideation to produce a structured PLANNING.md. Choose a project type (application, campaign, client, utility, or workflow) and answer the guided questions.
+
+### 3. Begin structured development
+```
+/drive:progress
+```
+Drive picks up your planning doc and enforces a Plan-Apply-Unify loop. No more cowboy coding — every change follows a plan.
+
+### 4. Check workspace health
+```
+/momentum:pulse
+```
+Momentum gives you a quick health check: what you're working on, what's in the backlog, and any issues.
+
+### 5. Run a security audit
+```
+/radar:audit
+```
+Radar deploys 12 engineering personas across 14 domains to audit your codebase.
+
+## Module Overview
+
+### Vector (Rules Engine)
+Vector runs automatically in the background. Define rules in your Vector config and they're injected into every Claude Code session based on context.
+
+**Key commands:**
+- `/vector:help` — see all Vector commands
+
+**How it works:** A Python hook runs on every prompt you send to Claude. It reads your rules config and injects relevant rules based on what you're working on.
+
+### Momentum (Workspace State)
+Momentum tracks your projects, tasks, and workspace health as structured JSON.
+
+**Key commands:**
+- `/momentum:pulse` — quick health check
+- `/momentum:scaffold` — set up a new workspace
+- `/momentum:groom` — clean up and prioritize backlog
+- `/momentum:audit` — deep workspace audit
+
+### Drive (Dev Workflow)
+Drive enforces structured development: plan first, then execute, then reconcile.
+
+**Key commands:**
+- `/drive:progress` — where am I in my current plan?
+- `/drive:resume` — pick up where I left off
+- `/drive:plan` — create a new plan
+- `/drive:apply` — execute the plan
+- `/drive:unify` — reconcile plan vs actual
+
+### Ignition (Project Incubation)
+Ignition guides new project ideation.
+
+**Key commands:**
+- `/ignition` — start ideation
+- `/ignition:status` — check ideation progress
+- `/ignition:graduate` — promote to managed build
+- `/ignition:launch` — hand off to Drive
+
+### Radar (Security Auditing)
+Radar performs comprehensive codebase audits.
+
+**Key commands:**
+- `/radar:audit` — run full audit
+- `/radar:status` — check audit progress
+- `/radar:report` — generate report
+- `/radar:remediate` — fix issues found
+
+### Forge (Skill Builder)
+Forge helps you create custom Claude Code skills.
+
+**Key commands:**
+- `/forge` — overview
+- `/forge:discover` — analyze a workflow to extract a skill
+- `/forge:scaffold` — generate skill file structure
+- `/forge:audit` — quality-check a skill
+
+### Mission Control (Orchestrator)
+Mission Control manages the entire Accelerate suite.
+
+**Key commands:**
+- `/accel status` — module health check
+- `/accel help` — see all commands
+
+## How Modules Talk to Each Other
+
+Accelerate uses a file-based event bus. When one module does something notable, it writes a JSON event to `~/.accel/events/`. Other modules pick up these events on their next invocation.
+
+**Example flow:**
+1. You run `/ignition` and create a planning doc
+2. Ignition writes a `plan-created` event
+3. Next time Drive runs, it sees the event and picks up the plan
+4. As Drive executes phases, it writes `phase-progress` events
+5. Momentum picks these up and updates workspace state
+
+You don't need to manage this — it happens automatically.
+
+## Updating
+
+```bash
+npx @accel/cli update
+```
+
+## Uninstalling
+
+Remove a single module:
+```bash
+npx @accel/cli remove radar
+```
+
+Remove everything:
+```bash
+npx @accel/cli uninstall
+```
+
+## Need Help?
+
+- Website: [accelerationguy.com](https://accelerationguy.com)
+- GitHub: [github.com/accelerationguy/accelerate](https://github.com/accelerationguy/accelerate)

package/docs/module-guide.md

@@ -0,0 +1,139 @@
+# Accelerate Module Guide
+
+## Module Architecture
+
+```
+~/.accel/                        # Accelerate home directory
+  manifest.json                  # Which modules are installed
+  events/                        # Cross-module event bus
+    archive/                     # Processed events
+    errors/                      # Invalid events
+    schemas/                     # Event type definitions
+  modules/
+    vector/                      # Rules engine files
+    momentum/                    # Workspace state files
+    drive/                       # Dev workflow files
+    ignition/                    # Project incubation files
+    radar/                       # Security audit files
+    forge/                       # Skill builder files
+    mission-control/             # Orchestrator files
+  mcp/
+    vector/                      # Vector MCP server
+    momentum/                    # Momentum MCP server
+
+~/.claude/
+  commands/
+    vector/                      # Vector slash commands
+    momentum/                    # Momentum slash commands
+    drive/                       # Drive slash commands
+    ignition/                    # Ignition slash commands
+    radar/                       # Radar slash commands
+    forge/                       # Forge slash commands
+    mission-control/             # Mission Control slash commands
+  hooks/
+    vector-hook.py               # Vector's prompt hook
+    momentum-*.py                # Momentum's hooks
+```
+
+## Module Dependencies
+
+```
+Mission Control (orchestrator)
+  ├── Vector (rules) ← no dependencies
+  ├── Momentum (state) ← REQUIRES Vector
+  ├── Drive (workflow) ← standalone, ENHANCED BY Momentum
+  ├── Ignition (ideation) ← standalone, ENHANCED BY Drive
+  ├── Radar (auditing) ← standalone, ENHANCED BY Momentum
+  └── Forge (skill building) ← standalone
+```
+
+**"Requires"** = won't install without the dependency.
+**"Enhanced by"** = works fine alone, gains features when the other module is present.
+
+## Standalone vs Enhanced Behavior
+
+| Module | Without other modules | With Momentum installed |
+|--------|----------------------|------------------------|
+| Drive | Full workflow, no state tracking | Progress auto-tracked in workspace |
+| Radar | Full auditing, findings to stdout | Findings auto-added to backlog |
+| Ignition | Full ideation, writes PLANNING.md | Plan creation event triggers Drive |
+
+## Event Bus
+
+Modules communicate via JSON files in `~/.accel/events/`.
+
+### Event Types
+
+| Event | Producer | Consumer | Trigger |
+|-------|----------|----------|---------|
+| `plan-created` | Ignition | Drive, Momentum | New PLANNING.md created |
+| `phase-progress` | Drive | Momentum | Phase started/completed |
+| `audit-complete` | Radar | Momentum | Security audit finished |
+
+### Event File Format
+
+```json
+{
+  "_producer": "radar",
+  "source": "radar",
+  "type": "audit-complete",
+  "timestamp": "2026-03-26T12:00:00Z",
+  "payload": {
+    "findings": 3,
+    "critical": 1,
+    "report": ".accel/radar/latest-report.json"
+  }
+}
+```
+
+### Security
+
+- Events must have a `_producer` field matching a registered module
+- Unknown producers are rejected and logged to `events/errors/`
+- Each event type has a JSON Schema in `events/schemas/`
+- Events older than 7 days are auto-cleaned
+
+## Configuration
+
+### Manifest (~/.accel/manifest.json)
+
+Tracks installed modules, versions, and installation dates. The installer manages this file — don't edit it manually.
+
+### Module Configs
+
+Each module may have its own config in `~/.accel/modules/<module>/`:
+- Vector: `~/.accel/modules/vector/vector.json` — rule definitions
+- Momentum: `~/.accel/modules/momentum/data/` — workspace data surfaces
+
+## Adding Custom Rules (Vector)
+
+Edit `~/.accel/modules/vector/vector.json` to add domain-specific rules:
+
+```json
+{
+  "domains": {
+    "security": {
+      "rules": [
+        "Always validate input at API boundaries",
+        "Never log sensitive data (passwords, tokens, PII)"
+      ],
+      "triggers": ["auth", "security", "password", "token"]
+    }
+  }
+}
+```
+
+Vector's hook will inject these rules when your prompt matches the trigger words.
+
+## Troubleshooting
+
+### Module not showing up after install
+Restart Claude Code. Slash commands are loaded at startup.
+
+### Python hooks not firing
+Check that Python 3.9+ is installed: `python3 --version`
+Check that hooks are in `~/.claude/hooks/`
+
+### MCP server not connecting
+Check `~/.mcp.json` has entries for the module's MCP server.
+Run the MCP server manually to check for errors: `node ~/.accel/mcp/vector/index.js`

package/modules/drive/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Chris Kahler
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/modules/drive/PAUL-VS-GSD.md

@@ -0,0 +1,171 @@
+# What Makes Drive Different
+
+> **Drive** (Plan-Apply-Unify Loop) builds on the foundation of GSD (Get Shit Done) while addressing key friction points that emerge during real-world AI-assisted development.
+
+---
+
+## The Core Insight
+
+GSD pioneered the concept of treating plans as executable prompts. Drive takes this further by recognizing that **execution without reconciliation creates drift** — and drift compounds across sessions.
+
+Where GSD focuses on *getting work done*, Drive focuses on *getting work done correctly, consistently, and with full traceability*.
+
+---
+
+## Key Differentiators
+
+### 1. Explicit Loop Discipline
+
+**GSD:** PLAN → EXECUTE → (implicit review)
+
+**Drive:** PLAN → APPLY → UNIFY (enforced)
+
+The UNIFY phase isn't optional. Every plan produces a SUMMARY.md that captures:
+- What actually happened vs. what was planned
+- Decisions made during execution
+- Issues deferred for later
+- Acceptance criteria results (pass/fail)
+
+*Why it matters:* Without explicit reconciliation, learnings evaporate between sessions. UNIFY creates an audit trail that makes context resumption reliable.
+
+---
+
+### 2. Context-Aware Execution (Token Economics)
+
+**GSD:** Spawns subagents for plan execution, pursuing speed through parallelization.
+
+**Drive:** Executes in the current context by default, optimizing for token-to-value efficiency.
+
+The parallel-subagent approach sounds fast on paper. In practice, it's expensive and wasteful:
+- Each subagent starts cold, requiring context injection
+- Subagents duplicate work the main session already understands
+- Coordination overhead compounds across agent boundaries
+- Output quality degrades without full project context
+
+Drive takes a different stance: **AI is already the speed enhancement.** We don't need to optimize speed at the cost of quality. What we need is to make every token count.
+
+Subagents in Drive are reserved for their optimal use case: **parallel research and discovery** — bounded, well-defined information gathering where cold-start overhead is acceptable. Execution stays in-session where the context lives.
+
+*Why it matters:* Parallel execution subagents generate more output faster, but "more garbage faster" isn't progress. Drive optimizes for exceptional value per token, consistently, from project start to finish. Token efficiency > speed to done.
+
+---
+
+### 3. Single Next Action
+
+**GSD:** Presents multiple options after each step ("Would you like to: A, B, C, or D?")
+
+**Drive:** Suggests ONE best path based on current state.
+
+Decision fatigue is real. Drive analyzes project state and recommends the most logical next step. Users can always redirect, but the default is momentum, not menu navigation.
+
+*Why it matters:* Every decision point is a potential context switch. Reducing decisions preserves focus.
+
+---
+
+### 4. Structured Session Continuity
+
+**GSD:** Implicit state via `.continue-here.md` in phase directories.
+
+**Drive:** Explicit `HANDOFF-{date}.md` files with loop position, decisions, and prioritized next actions.
+
+Drive handoffs are designed for zero-context resumption. They capture not just *where* you stopped, but *why* you were doing what you were doing and *what* decisions led there.
+
+*Why it matters:* Sessions end unexpectedly. Context windows reset. Drive handoffs make "resume from cold" a first-class operation.
+
+---
+
+### 5. Acceptance Criteria as First-Class Citizens
+
+**GSD:** Tasks describe what to do.
+
+**Drive:** Tasks link to numbered acceptance criteria (AC-1, AC-2, AC-3) with Given/When/Then format.
+
+Every PLAN.md includes explicit acceptance criteria. Every SUMMARY.md reports pass/fail against those criteria. This creates verifiable quality gates, not just completion checkboxes.
+
+*Why it matters:* "Done" is ambiguous. "AC-3: PASS" is not.
+
+---
+
+### 6. Boundaries That Stick
+
+**GSD:** Scope guidance in plans.
+
+**Drive:** Explicit `## Boundaries` section in every PLAN.md with DO NOT CHANGE declarations.
+
+When you specify boundaries, Drive treats them as hard constraints, not suggestions. Modifications to protected items require explicit confirmation.
+
+*Why it matters:* Scope creep happens subtly. Explicit boundaries make violations visible before they cascade.
+
+---
+
+### 7. Skill Tracking and Verification
+
+**GSD:** No mechanism for tracking specialized workflow usage.
+
+**Drive:** `SPECIAL-FLOWS.md` declares required skills per project. UNIFY audits whether they were invoked.
+
+If your project requires `/commit` or `/review-pr` or custom skills, Drive tracks whether they were actually used — preventing "forgot to run the linter" moments.
+
+*Why it matters:* Manual checklists get skipped. Automated audits don't.
+
+---
+
+### 8. Decimal Phases for Interruptions
+
+**GSD:** Integer phases only. Urgent work requires phase insertion and renumbering.
+
+**Drive:** Decimal phases (8.1, 8.2) for urgent interruptions without disrupting the roadmap.
+
+When something urgent lands mid-milestone, Drive slots it as a decimal phase. The original plan stays intact, and the interruption is clearly marked as an insertion.
+
+*Why it matters:* Real projects have interruptions. The planning system should accommodate them, not fight them.
+
+---
+
+## Philosophy Comparison
+
+| Aspect | GSD | Drive |
+|--------|-----|------|
+| Primary goal | Ship fast | Ship correctly |
+| Optimization target | Speed to done | Token-to-value efficiency |
+| Loop closure | Flexible | Mandatory |
+| Subagent role | Execution (parallel speed) | Discovery only (bounded research) |
+| Decision flow | Multiple options | Single best path |
+| Session handoff | Implicit | Explicit + dated |
+| Quality gates | Completion-based | Acceptance-based |
+| Scope control | Guidance | Enforcement |
+
+---
+
+## When to Use Which
+
+**Use GSD when:**
+- Speed is the primary constraint
+- Project scope is small and well-understood
+- Single-session completion is likely
+- You don't need audit trails
+
+**Use Drive when:**
+- Quality and traceability matter
+- Work spans multiple sessions
+- You need verifiable acceptance criteria
+- Scope creep is a concern
+- You want explicit reconciliation of plan vs. reality
+
+---
+
+## The Bottom Line
+
+GSD answers: *"How do I get Claude to execute a plan fast?"*
+
+Drive answers: *"How do I get maximum value from every token spent?"*
+
+The insight: AI development is already fast. Using Claude at all *is* the speed advantage. The marginal gains from parallel subagent execution come at significant cost — more tokens, more coordination, more garbage output, less coherent results.
+
+Drive doesn't try to enhance the enhancement. It takes what AI gives us and makes it **as valuable as possible** — through explicit reconciliation, preserved context, verifiable quality gates, and disciplined loop closure.
+
+Drive isn't a replacement for GSD — it's an evolution for projects where **sustainable quality** matters more than **raw throughput**.
+
+---
+
+*Drive Framework — Plan. Apply. Unify. Repeat.*