accelerator

A Claude Code plugin for structured, context-efficient software development.
Jump to installation if you're ready to get started.

Philosophy

Accelerator structures development into discrete phases — research, plan,
implement — where each phase runs with minimal context and communicates with
the next through the filesystem. This design is intentional: by writing
research findings, plans, and other artifacts to disk rather than holding them
in the conversation, each step stays focused and avoids the quality degradation
that comes with large, cluttered context windows.

The result is a development workflow where:

• Each phase has a clear purpose and bounded scope
• The filesystem (specifically the meta/ directory) serves as persistent
  shared memory between phases and sessions
• Subagents handle exploratory work in isolation, returning only summaries to
  the main context
• Human review happens at the highest-leverage points (research quality and
  plan quality) before implementation begins

For example, a research phase might read 50 files across a codebase, but only
a structured summary is written to disk and passed to the planning phase —
keeping the planner focused and accurate.

The Development Loop

The primary workflow is a three-phase loop:

research-codebase  →  create-plan  →  implement-plan
       ↓                   ↓                 ↓
  meta/research/      meta/plans/     checked-off plan

1. Research (/accelerator:research-codebase "how does auth work?"):
   Investigate the codebase using parallel subagents. Produces a structured
   research document in meta/research/ with findings, file references, and
   architectural context.

2. Plan (/accelerator:create-plan ENG-1234): Build a phased
   implementation plan informed by research. Produces a plan document in
   meta/plans/ with specific file changes, success criteria, and testing
   strategy. The plan is reviewed by the developer before proceeding.

3. Implement (/accelerator:implement-plan @meta/plans/plan.md): Execute
   the plan phase by phase, checking off success criteria as each phase
   completes. The plan file serves as both instructions and progress tracker.

Three complementary skills support this loop:

• /accelerator:review-plan @meta/plans/plan.md — Review a plan through
  multiple quality lenses before implementation
• /accelerator:stress-test-plan @meta/plans/plan.md — Interactively
  stress-test a plan through adversarial questioning to find issues,
  inconsistencies, and gaps
• /accelerator:validate-plan @meta/plans/plan.md — Verify after
  implementation that the code matches the plan

The meta/ Directory

Every project using Accelerator gets a meta/ directory (by default) that
serves as persistent state for the development workflow. Each skill reads from
and writes to predictable paths within it. Run /accelerator:init to
create all directories up front, or let skills create them on first use.
These paths can be overridden via the paths configuration section:

This approach means:

• No skill assumes access to another skill's conversation history
• Work survives session boundaries and context compaction
• Plans can be resumed after interruption (implement-plan picks up from the
  first unchecked item)
• Artifacts are structured and machine-parseable (YAML frontmatter, JSON
  schemas)

VCS Detection

Accelerator automatically detects whether a repository uses git or
jujutsu (jj) and adapts its behaviour
accordingly. A SessionStart hook inspects the working directory for .jj/ and
.git/ directories, injecting VCS-specific context (command references and
conventions) into the session. A complementary PreToolUse guard warns when raw
git commands are used in a jujutsu repository.

This means all VCS-aware skills — commit, respond-to-pr, and ad-hoc
interactions — use the correct CLI commands without manual configuration. The
detection covers three modes:

Configuration

Accelerator supports project-specific configuration through markdown files with
YAML frontmatter. Configuration allows you to provide project context, customise
agent behaviour, and tune review settings.

Config Files

Local settings override team settings for the same key. Markdown bodies from
both files are concatenated (team context first, then personal).

File Format

Both files use YAML frontmatter for structured settings and a markdown body for
free-form project context:

---
agents:
  reviewer: my-custom-reviewer
review:
  disabled_lenses: [ portability, compatibility ]
  max_inline_comments: 15
  pr_request_changes_severity: major
---

## Project Context

This is a Ruby on Rails application using PostgreSQL and Redis.

### Conventions
- Follow StandardRB for code style
- Use service objects for business logic
- All API endpoints require authentication

### Build & Test
- `bundle exec rspec` to run tests
- `bin/dev` to start the development server

The YAML frontmatter supports agents (override which agents skills spawn),
review (customise review behaviour), paths (override where skills write
output documents), and templates (point to custom document templates). See
/accelerator:configure help for the full key reference.

Template Management

Templates control the structure of documents produced by skills (plans, ADRs,
research, validation reports, PR descriptions). The configure skill provides
subcommands for managing templates without manually locating plugin internals:

Available template keys: plan, research, adr, validation,
pr-description.

A typical customisation workflow:

1. templates list to see what's available and where each resolves from
2. templates eject plan to copy the plugin default to your templates directory
3. Edit the ejected file to match your project's conventions
4. templates diff plan to review your changes against the default
5. templates reset plan if you want to revert to the plugin default

Templates are resolved in order: config path (templates.<key>) → templates
directory (paths.templates, default meta/templates/) → plugin default.

Getting Started

Run /accelerator:configure to create or view your configuration. The skill
walks you through gathering project context and writes the config file for you.

How It Works

• A SessionStart hook detects config files and injects a summary into the
  session context
• Skills read project context at invocation time via the ! preprocessor
• Config changes take effect on the next skill invocation (no session restart
  needed for skills); the SessionStart summary updates on session restart

Custom Review Lenses

You can add custom review lenses alongside the 13 built-in ones. Place them in
.claude/accelerator/lenses/ following the [name]-lens/SKILL.md convention.
Custom lenses are auto-discovered and included in the lens catalogue. See
/accelerator:configure help for details and a minimal template.

Per-Skill Customisation

Beyond global context, you can provide context or instructions targeted at
individual skills by placing files in
.claude/accelerator/skills/<skill-name>/:

.claude/accelerator/skills/
  review-pr/
    context.md          # Context specific to PR review
    instructions.md     # Additional instructions for PR review
  create-plan/
    instructions.md     # Additional instructions for plan creation

• context.md — Injected after global project context. Use for information
  only one skill needs (e.g., review criteria for review-pr, architecture
  context for create-plan).
• instructions.md — Appended to the end of the skill's prompt. Use to add
  steps, enforce conventions, or modify output format. Instructions at the end
  of the prompt typically take precedence when they conflict with earlier
  instructions.

Both files are optional. Directory names must match the skill name exactly (the
part after /accelerator:). The SessionStart hook warns about unrecognised
directory names. See /accelerator:configure help for the full reference.

Architecture Decision Records

ADR skills capture architectural decisions that emerge from research and
planning:

research-codebase → create-plan → implement-plan
       ↓                ↓
  meta/research/    meta/plans/
       ↓                ↓
  extract-adrs ←────────┘
       ↓
  meta/decisions/
       ↓
  review-adr → accepted ADRs inform future research & planning

ADRs follow an append-only lifecycle: once accepted, an ADR's content becomes
immutable. To revise a decision, create a new ADR that supersedes the original.

VCS and PR Workflow Skills

Alongside the development loop, Accelerator provides skills for version control
and team workflows around pull requests:

Review System

The review-pr and review-plan skills use a multi-lens review system. Each
lens is a specialised subagent that evaluates changes through a specific quality
perspective:

Lenses are automatically selected based on scope, or you can specify focus
areas:

/accelerator:review-pr 123 focus on security and architecture

Agents

Accelerator uses specialised subagents to keep the main context lean. Each
agent runs in its own context window with restricted tools, returning only a
focused summary to the parent:

The separation between locators (find, no Read) and analysers (understand, with
Read) is deliberate: it prevents any single agent from needing to both search
broadly and read deeply, keeping each agent's context bounded.

Installation

Add the marketplace and install the plugin:

/plugin marketplace add atomicinnovation/accelerator
/plugin install accelerator@atomic-innovation

Development

To load from a local checkout:

claude --plugin-dir /path/to/accelerator

License

MIT — see LICENSE.