{"id":49408618,"url":"https://github.com/atomicinnovation/accelerator","last_synced_at":"2026-06-14T22:01:42.793Z","repository":{"id":344497628,"uuid":"1182028661","full_name":"atomicinnovation/accelerator","owner":"atomicinnovation","description":"Development acceleration toolkit with multi-lens code review, implementation planning, codebase research, and git workflow automation.","archived":false,"fork":false,"pushed_at":"2026-06-02T11:41:16.000Z","size":31374,"stargazers_count":19,"open_issues_count":0,"forks_count":1,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-06-02T13:26:01.060Z","etag":null,"topics":["ai-assisted-development","ai-coding","ai-workflow","claude","claude-code","rpi","skills"],"latest_commit_sha":null,"homepage":"https://go-atomic.io","language":"HTML","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/atomicinnovation.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-03-15T00:07:31.000Z","updated_at":"2026-06-02T11:41:20.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/atomicinnovation/accelerator","commit_stats":null,"previous_names":["atomicinnovation/accelerator"],"tags_count":92,"template":false,"template_full_name":null,"purl":"pkg:github/atomicinnovation/accelerator","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/atomicinnovation%2Faccelerator","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/atomicinnovation%2Faccelerator/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/atomicinnovation%2Faccelerator/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/atomicinnovation%2Faccelerator/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/atomicinnovation","download_url":"https://codeload.github.com/atomicinnovation/accelerator/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/atomicinnovation%2Faccelerator/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34057158,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-08T02:00:07.615Z","response_time":111,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["ai-assisted-development","ai-coding","ai-workflow","claude","claude-code","rpi","skills"],"created_at":"2026-04-28T23:01:25.340Z","updated_at":"2026-06-08T10:01:05.002Z","avatar_url":"https://github.com/atomicinnovation.png","language":"HTML","funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003cp align=\"center\"\u003e\n  \u003cpicture\u003e\n    \u003csource media=\"(prefers-color-scheme: dark)\" srcset=\"assets/accelerator_logo_dark_bg.png\"\u003e\n    \u003csource media=\"(prefers-color-scheme: light)\" srcset=\"assets/accelerator_logo_light_bg.png\"\u003e\n    \u003cimg alt=\"Accelerator\" src=\"assets/accelerator_logo_light_bg.png\" width=\"342px\"\u003e\n  \u003c/picture\u003e\n\u003c/p\u003e\n\nA Claude Code plugin for structured, context-efficient software development.\n[Jump to installation](#installation) if you're ready to get started.\n\n## Philosophy\n\nAccelerator structures development into discrete phases — research, plan,\nimplement — where each phase runs with minimal context and communicates with\nthe next through the filesystem. This design is intentional: by writing\nresearch findings, plans, and other artifacts to disk rather than holding them\nin the conversation, each step stays focused and avoids the quality degradation\nthat comes with large, cluttered context windows.\n\nThe result is a development workflow where:\n\n- Each phase has a clear purpose and bounded scope\n- The filesystem (specifically the `meta/` directory) serves as persistent\n  shared memory between phases and sessions\n- Subagents handle exploratory work in isolation, returning only summaries to\n  the main context\n- Human review happens at the highest-leverage points (research quality and\n  plan quality) before implementation begins\n\nFor example, a research phase might read 50 files across a codebase, but only\na structured summary is written to disk and passed to the planning phase —\nkeeping the planner focused and accurate.\n\n## The Development Loop\n\nThe primary workflow is a three-phase loop:\n\n```\nresearch-codebase    →  create-plan  →  implement-plan\n        ↓                    ↓                 ↓\nmeta/research/codebase/ meta/plans/    checked-off plan\n```\n\n1. **Research** (`/accelerator:research-codebase \"how does auth work?\"`):\n   Investigate the codebase using parallel subagents. Produces a structured\n   research document in `meta/research/codebase/` with findings, file\n   references, and architectural context.\n\n2. **Plan** (`/accelerator:create-plan ENG-1234`): Build a phased\n   implementation plan informed by research. Produces a plan document in\n   `meta/plans/` with specific file changes, success criteria, and testing\n   strategy. The plan is reviewed by the developer before proceeding.\n\n3. **Implement** (`/accelerator:implement-plan @meta/plans/plan.md`): Execute\n   the plan phase by phase, checking off success criteria as each phase\n   completes. The plan file serves as both instructions and progress tracker.\n\nA companion skill handles issue investigation:\n\n- `/accelerator:research-issue \"auth timeout on token refresh\"` — Investigate\n  production issues through hypothesis-driven debugging. Accepts stacktraces,\n  logs, or behavioral descriptions and produces an RCA document in\n  `meta/research/issues/`.\n\nThree complementary skills support this loop:\n\n- `/accelerator:review-plan @meta/plans/plan.md` — Review a plan through\n  multiple quality lenses before implementation\n- `/accelerator:stress-test-plan @meta/plans/plan.md` — Interactively\n  stress-test a plan through adversarial questioning to find issues,\n  inconsistencies, and gaps\n- `/accelerator:validate-plan @meta/plans/plan.md` — Verify after\n  implementation that the code matches the plan\n\n## The `meta/` Directory\n\nEvery project using Accelerator gets a `meta/` directory (by default) that\nserves as persistent state for the development workflow. Each skill reads from\nand writes to predictable paths within it. Run `/accelerator:init` to\ncreate all directories up front, or let skills create them on first use.\nThese paths can be overridden via the `paths` configuration section:\n\n`research/` is itself subdivided into four subcategories — codebase\nresearch, issue/RCA research, design inventories, and design gaps:\n\n| Directory                       | Purpose                                                        | Written by                                                   |\n|---------------------------------|----------------------------------------------------------------|--------------------------------------------------------------|\n| `research/`                     | (parent — see subcategories below)                             | —                                                            |\n| `  ├─ codebase/`                | Codebase research findings with YAML frontmatter               | `research-codebase`                                          |\n| `  ├─ issues/`                  | Issue / RCA research findings                                  | `research-issue`                                             |\n| `  ├─ design-inventories/`      | Per-source design inventory snapshots (markdown + screenshots) | `inventory-design`                                           |\n| `  └─ design-gaps/`             | Design-gap analysis artifacts                                  | `analyse-design-gaps`                                        |\n| `plans/`                        | Implementation plans with phased changes                       | `create-plan`                                                |\n| `decisions/`                    | Architecture decision records (ADRs)                           | `create-adr`, `extract-adrs`, `review-adr`                   |\n| `reviews/`                      | Review summaries and per-lens results                          | `review-pr`, `review-plan`                                   |\n| `validations/`                  | Plan validation reports                                        | `validate-plan`                                              |\n| `prs/`                          | PR descriptions                                                | `describe-pr`                                                |\n| `work/`                         | Work item files referenced by planning                         | `create-work-item`, `extract-work-items`, `update-work-item` |\n| `notes/`                        | Notes and working documents                                    | manual                                                       |\n\nThis approach means:\n\n- No skill assumes access to another skill's conversation history\n- Work survives session boundaries and context compaction\n- Plans can be resumed after interruption (implement-plan picks up from the\n  first unchecked item)\n- Artifacts are structured and machine-parseable (YAML frontmatter, JSON\n  schemas)\n\n## Migrations\n\nWhen a new plugin version renames directories, config keys, or file formats, a\nmigration script handles the upgrade. Run `/accelerator:migrate` after updating\nthe plugin to apply any pending migrations.\n\n```\n/accelerator:migrate\n```\n\nSafety guards: the skill refuses to run on a dirty working tree, prints a\npre-run banner listing each pending migration, and previews each one before\napplying. All mutations are tracked in `.accelerator/state/migrations-applied`.\nRecovery is via VCS revert. Set `ACCELERATOR_MIGRATE_FORCE=1` to bypass the\nclean-tree check if needed.\n\nTo opt out of an individual migration, run\n`bash skills/config/migrate/scripts/run-migrations.sh --skip \u003cid\u003e` (and\n`--unskip \u003cid\u003e` to re-enable it). Skipped IDs are tracked in\n`.accelerator/state/migrations-skipped` and surfaced by name in the runner's\nsummary line so a permanent skip is never invisible. A migration can also\nself-defer by emitting `MIGRATION_RESULT: no_op_pending` on stdout — useful\nfor migrations whose preconditions (e.g. a `{project}` pattern in\n`work.id_pattern`) aren't yet configured.\n\nA `SessionStart` hook fires automatically when the bundled migrations have not\nall been applied, reminding you to run `/accelerator:migrate`. (On repos that\nhaven't run migration `0003` yet, the hook reads the legacy\n`meta/.migrations-applied` file as a fallback.)\n\n## VCS Detection\n\nAccelerator automatically detects whether a repository uses git or\n[jujutsu (jj)](https://github.com/jj-vcs/jj) and adapts its behaviour\naccordingly. A `SessionStart` hook inspects the working directory for `.jj/` and\n`.git/` directories, injecting VCS-specific context (command references and\nconventions) into the session. A complementary `PreToolUse` guard warns when raw\ngit commands are used in a jujutsu repository.\n\nThis means all VCS-aware skills — `commit`, `respond-to-pr`, and ad-hoc\ninteractions — use the correct CLI commands without manual configuration. The\ndetection covers three modes:\n\n| Mode               | Detected when      | VCS commands used |\n|--------------------|--------------------|-------------------|\n| **git**            | `.git/` only       | `git`             |\n| **jj (colocated)** | `.jj/` and `.git/` | `jj`              |\n| **jj (pure)**      | `.jj/` only        | `jj`              |\n\n## Configuration\n\nAccelerator supports project-specific configuration through markdown files with\nYAML frontmatter. Configuration allows you to provide project context, customise\nagent behaviour, and tune review settings.\n\n### Config Files\n\n| File                              | Scope                   | Purpose                             |\n|-----------------------------------|-------------------------|-------------------------------------|\n| `.accelerator/config.md`          | Team-shared (committed) | Shared project context and settings |\n| `.accelerator/config.local.md`    | Personal (gitignored)   | Personal overrides and preferences  |\n\nLocal settings override team settings for the same key. Markdown bodies from\nboth files are concatenated (team context first, then personal).\n\n### File Format\n\nBoth files use YAML frontmatter for structured settings and a markdown body for\nfree-form project context:\n\n```yaml\n---\nagents:\n  reviewer: my-custom-reviewer\nreview:\n  disabled_lenses: [ portability, compatibility ]\n  max_inline_comments: 15\n  pr_request_changes_severity: major\n---\n\n## Project Context\n\n  This is a Ruby on Rails application using PostgreSQL and Redis.\n\n### Conventions\n- Follow StandardRB for code style\n- Use service objects for business logic\n- All API endpoints require authentication\n\n### Build \u0026 Test\n- `bundle exec rspec` to run tests\n- `bin/dev` to start the development server\n```\n\nThe YAML frontmatter supports `agents` (override which agents skills spawn),\n`review` (customise review behaviour), `paths` (override where skills write\noutput documents), `templates` (point to custom document templates), and\n`work` (customise work-item ID filename pattern and default project code).\nSee `/accelerator:configure help` for the full key reference.\n\n### Template Management\n\nTemplates control the structure of documents produced by skills (plans, ADRs,\nresearch, validation reports, PR descriptions). The configure skill provides\nsubcommands for managing templates without manually locating plugin internals:\n\n| Command                                        | Description                                            |\n|------------------------------------------------|--------------------------------------------------------|\n| `/accelerator:configure templates list`        | List all templates with resolution source and path     |\n| `/accelerator:configure templates show \u003ckey\u003e`  | Display the effective template content                 |\n| `/accelerator:configure templates eject \u003ckey\u003e` | Copy plugin default to your templates directory        |\n| `/accelerator:configure templates eject --all` | Eject all templates at once                            |\n| `/accelerator:configure templates diff \u003ckey\u003e`  | Show differences between your template and the default |\n| `/accelerator:configure templates reset \u003ckey\u003e` | Remove your customisation, revert to plugin default    |\n\nAvailable template keys: `plan`, `research`, `adr`, `validation`,\n`pr-description`, `work-item`, `design-inventory`, `design-gap`.\n\nA typical customisation workflow:\n\n1. `templates list` to see what's available and where each resolves from\n2. `templates eject plan` to copy the plugin default to your templates directory\n3. Edit the ejected file to match your project's conventions\n4. `templates diff plan` to review your changes against the default\n5. `templates reset plan` if you want to revert to the plugin default\n\nTemplates are resolved in order: config path (`templates.\u003ckey\u003e`) → templates\ndirectory (`paths.templates`, default `.accelerator/templates/`) → plugin default.\n\n### Getting Started\n\nRun `/accelerator:configure` to create or view your configuration. The skill\nwalks you through gathering project context and writes the config file for you.\n\n### How It Works\n\n- A `SessionStart` hook detects config files and injects a summary into the\n  session context\n- Skills read project context at invocation time via the `!` preprocessor\n- Config changes take effect on the next skill invocation (no session restart\n  needed for skills); the SessionStart summary updates on session restart\n\n### Custom Review Lenses\n\nYou can add custom review lenses alongside the 13 built-in ones. Place them in\n`.accelerator/lenses/` following the `[name]-lens/SKILL.md` convention.\nCustom lenses are auto-discovered and included in the lens catalogue. See\n`/accelerator:configure help` for details and a minimal template.\n\n### Per-Skill Customisation\n\nBeyond global context, you can provide context or instructions targeted at\nindividual skills by placing files in\n`.accelerator/skills/\u003cskill-name\u003e/`:\n\n```\n.accelerator/skills/\n  review-pr/\n    context.md          # Context specific to PR review\n    instructions.md     # Additional instructions for PR review\n  create-plan/\n    instructions.md     # Additional instructions for plan creation\n```\n\n- **`context.md`** — Injected after global project context. Use for information\n  only one skill needs (e.g., review criteria for `review-pr`, architecture\n  context for `create-plan`).\n- **`instructions.md`** — Appended to the end of the skill's prompt. Use to add\n  steps, enforce conventions, or modify output format. Instructions at the end\n  of the prompt typically take precedence when they conflict with earlier\n  instructions.\n\nBoth files are optional. Directory names must match the skill name exactly (the\npart after `/accelerator:`). The SessionStart hook warns about unrecognised\ndirectory names. See `/accelerator:configure help` for the full reference.\n\n## Work Item Management\n\nWork item skills capture work items — features, bugs, tasks, spikes, and epics —\nas structured documents that feed into planning. The filename prefix\ndefaults to a 4-digit number (`meta/work/0042-add-search.md`) but is\nconfigurable via `work.id_pattern` and `work.default_project_code` —\ne.g. `{project}-{number:04d}` with `default_project_code: PROJ` produces\n`meta/work/PROJ-0042-add-search.md`. The `work.integration` key (allowed\nvalues `jira`, `linear`, `trello`, `github-issues`; empty by default)\nselects the active remote tracker. When unset, all work-management skills\noperate purely against `meta/work/` with no external API calls. See\n[`skills/config/configure/SKILL.md`](skills/config/configure/SKILL.md#work)\nfor the full reference.\n\n```\nexisting docs (specs, PRDs, notes)\n       │\n       ├── extract-work-items ──┐\n       │                     ↓\n       create-work-item ──→  meta/work/  ←── update-work-item\n                              │\n                         list-work-items ──┬──→  review-work-item → meta/reviews/work/\n                                        └──→  create-plan → implement-plan\n```\n\n| Skill                  | Usage                                                      | Description                                                                                |\n|------------------------|------------------------------------------------------------|--------------------------------------------------------------------------------------------|\n| **create-work-item**   | `/accelerator:create-work-item [topic-or-ref]`             | Interactively create a work item from a topic, or enrich an existing one by path or number |\n| **extract-work-items** | `/accelerator:extract-work-items [doc paths...]`           | Batch-extract work items from existing specs, PRDs, research, plans, or notes              |\n| **list-work-items**    | `/accelerator:list-work-items [filter]`                    | List and filter work items by status, type, priority, tag, parent, or title                |\n| **update-work-item**   | `/accelerator:update-work-item [work-item-ref] [field-op]` | Update work item fields with diff preview and confirmation                                 |\n| **review-work-item**   | `/accelerator:review-work-item [work-item-ref]`            | Review a work item through completeness, testability, and clarity lenses                   |\n\nWork items use a shared template with YAML frontmatter (`work_item_id`, `title`,\n`type`, `status`, `priority`, `parent`, `tags`) and structured body sections\n(Summary, Context, Requirements, Acceptance Criteria, Open Questions,\nDependencies, Assumptions, Technical Notes, Drafting Notes, References).\nThe template is customisable via\n`/accelerator:configure templates eject work-item`.\n\n## Jira Integration\n\nAccelerator includes a full set of skills for interacting with a Jira Cloud\ntenant — searching for and reading issues, creating and updating them,\ncommenting, transitioning through workflows, and uploading attachments. Run\n`/accelerator:init-jira` once to verify credentials and persist the\nteam-shared field and project catalogue before using the other skills.\n\n### Configuration\n\nAdd the shared site setting to `.accelerator/config.md` and personal\ncredentials to `.accelerator/config.local.md` (gitignored):\n\n```yaml\n# .accelerator/config.md — commit this\n---\njira:\n  site: your-subdomain   # e.g. \"atomic-innovation\" for atomic-innovation.atlassian.net\n---\n```\n\n```yaml\n# .accelerator/config.local.md — do not commit\n---\njira:\n  email: you@example.com\n  token_cmd: \"op read op://Work/Atlassian/credential\"  # any password-manager command\n---\n```\n\nThe default project key reuses `work.default_project_code`; set\n`work.integration: jira` to enable auto-scoping. See\n`/accelerator:configure help` for the full credential resolution chain and\n`token_cmd` examples (1Password, `pass`, macOS Keychain, AWS Secrets Manager).\n\n### Skills\n\n| Skill                     | Usage                                              | Description                                                                                                                                       |\n|---------------------------|----------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------|\n| **init-jira**             | `/accelerator:init-jira`                           | Verify credentials, discover projects and custom fields, persist the team-shared catalogue to `.accelerator/state/integrations/jira/`             |\n| **search-jira-issues**    | `/accelerator:search-jira-issues [flags]`          | Search via structured flags (assignee, status, label, type, component, reporter, parent, watching); composes safe JQL with a `--jql` escape hatch |\n| **show-jira-issue**       | `/accelerator:show-jira-issue \u003cKEY\u003e`               | Fetch a single issue with optional comment slice and Markdown rendering of ADF descriptions                                                       |\n| **create-jira-issue**     | `/accelerator:create-jira-issue [flags]`           | Create a new issue; body accepted inline, from a file, from stdin, or via `$EDITOR`                                                               |\n| **update-jira-issue**     | `/accelerator:update-jira-issue \u003cKEY\u003e [flags]`     | Edit summary, description, assignee, priority, labels, components, parent, and custom fields                                                      |\n| **comment-jira-issue**    | `/accelerator:comment-jira-issue \u003csub\u003e \u003cKEY\u003e`      | Add, list, edit, or delete comments (`add`, `list`, `edit`, `delete` sub-actions)                                                                 |\n| **transition-jira-issue** | `/accelerator:transition-jira-issue \u003cKEY\u003e \u003cstate\u003e` | Move an issue through its workflow by state name (case-insensitive lookup), with optional resolution and comment                                  |\n| **attach-jira-issue**     | `/accelerator:attach-jira-issue \u003cKEY\u003e \u003cfile...\u003e`   | Upload one or more files as issue attachments                                                                                                     |\n\nRead skills (`search-jira-issues`, `show-jira-issue`) trigger automatically on\nnatural-language phrasing. Write skills are slash-only — they display a\npayload preview and require explicit confirmation before making any change to\nthe tenant.\n\n### ADF / Markdown\n\nJira Cloud v3 stores rich-text fields in Atlassian Document Format (ADF).\nAccelerator converts bidirectionally using pure bash + awk + jq with no\nadditional dependencies:\n\n- **Reading** — ADF is rendered to Markdown by default on `show-jira-issue`\n  (pass `--no-render-adf` for raw JSON) and on `comment-jira-issue list`.\n  `search-jira-issues` defaults render-off; pass `--render-adf` for bulk\n  results with description text.\n- **Writing** — `create-jira-issue`, `update-jira-issue`, and\n  `comment-jira-issue add`/`edit` convert Markdown input to ADF before\n  sending.\n\nSupported Markdown: paragraphs, headings (`#`–`######`), fenced code blocks\nwith language, single-level bullet/ordered lists, GitHub-style checklists\n(`- [ ]` / `- [x]`), inline bold/italic/code/links, and hard breaks.\n\n### State cache\n\n`/init-jira` persists the field catalogue, project list, and site metadata to\n`.accelerator/state/integrations/jira/`. This directory is version-controlled\nand team-shared — instance-specific custom field IDs are not secrets and are\nworth committing so teammates don't need to re-run init. Per-developer\ncredentials live in `.accelerator/config.local.md` and env vars only.\n\n## Architecture Decision Records\n\nADR skills capture architectural decisions that emerge from research and\nplanning:\n\n```\nresearch-codebase  → create-plan → implement-plan\n       ↓                  ↓\nmeta/research/codebase/ meta/plans/\n       ↓                  ↓\n  extract-adrs ←──────────┘\n       ↓\n  meta/decisions/\n       ↓\n  review-adr → accepted ADRs inform future research \u0026 planning\n```\n\n| Skill            | Usage                                      | Description                                                |\n|------------------|--------------------------------------------|------------------------------------------------------------|\n| **create-adr**   | `/accelerator:create-adr [topic]`          | Interactively create an ADR with context gathering         |\n| **extract-adrs** | `/accelerator:extract-adrs [doc paths...]` | Extract decisions from existing meta documents into ADRs   |\n| **review-adr**   | `/accelerator:review-adr [path to ADR]`    | Review proposed ADRs; accept, reject, or suggest revisions |\n\nADRs follow an append-only lifecycle: once accepted, an ADR's content becomes\nimmutable. To revise a decision, create a new ADR that supersedes the original.\n\n## VCS and PR Workflow Skills\n\nAlongside the development loop, Accelerator provides skills for version control\nand team workflows around pull requests:\n\n| Skill             | Usage                            | Description                                                              |\n|-------------------|----------------------------------|--------------------------------------------------------------------------|\n| **commit**        | `/accelerator:commit`            | Create well-structured, atomic commits (works with both git and jujutsu) |\n| **describe-pr**   | `/accelerator:describe-pr 123`   | Generate comprehensive PR descriptions from a configurable template      |\n| **review-pr**     | `/accelerator:review-pr 123`     | Review a PR through multiple quality lenses with inline comments         |\n| **respond-to-pr** | `/accelerator:respond-to-pr 123` | Address PR review feedback interactively with code changes               |\n\n## Visualiser\n\n`/accelerator:visualise` opens a browser-based companion view of your project's\n`meta/` directory. Three views cover the breadth of the directory:\n\n| View          | What it shows                                                         |\n|---------------|-----------------------------------------------------------------------|\n| **Library**   | Markdown reader for every doc type (plans, research, ADRs, tickets …) |\n| **Lifecycle** | Slug-clustered timelines grouping related documents across phases     |\n| **Kanban**    | Ticket board driven by `status:` frontmatter; drag-and-drop to update |\n\n### Launching\n\n```bash\n/accelerator:visualise            # from inside a Claude Code session\naccelerator-visualiser            # CLI wrapper — optionally symlink onto $PATH\n```\n\nThe server binds to `localhost` on a dynamic port. It has no authentication\nand emits no telemetry. Re-running the command while the server is alive\nreturns the same URL.\n\n### Lifecycle\n\n```bash\n/accelerator:visualise status     # JSON: running | stale | not_running\n/accelerator:visualise stop       # SIGTERM, escalating to SIGKILL after 2s\n```\n\nBoth subcommands also work via the `accelerator-visualiser` CLI wrapper.\nThe server auto-exits after 8 hours idle or when the process that\nlaunched it exits, so explicit `stop` is rarely necessary.\n\n### First-run binary download\n\nThe server is distributed as a pre-compiled native binary (~8 MB). On first\nrun the launcher:\n\n1. Reads `bin/checksums.json` (committed in the plugin) to find the SHA-256\n   for your platform and the current plugin version.\n2. Downloads the matching binary from the plugin's GitHub Releases over HTTPS.\n3. Verifies the download against the manifest and caches it under the plugin\n   root. Subsequent launches skip the download.\n\nEvery plugin version — pre-release (`X.Y.Z-pre.N`) and stable (`X.Y.Z`) —\nships four-platform binaries. There is no need to build locally to use a\npre-release version.\n\n### Customisation\n\n| Mechanism                                  | Purpose                                                            |\n|--------------------------------------------|--------------------------------------------------------------------|\n| `ACCELERATOR_VISUALISER_BIN`               | One-shot override pointing at a locally-built binary               |\n| `visualiser.binary` config key             | Persistent binary override in `.accelerator/config.local.md`       |\n| `ACCELERATOR_VISUALISER_IDLE_TIMEOUT`      | One-shot override of the idle auto-shutdown window (duration string, or `never`/`0` to disable) |\n| `visualiser.idle_timeout` config key       | Persistent idle auto-shutdown window (humantime duration; default `8h`; `never`/`0` to disable) |\n| `ACCELERATOR_VISUALISER_RELEASES_URL`      | Alternative HTTPS mirror for air-gapped or self-hosted installs    |\n| `ACCELERATOR_VISUALISER_VERIFY_PROVENANCE` | Set to `1` to verify SLSA build-provenance after the SHA-256 check |\n\nThe `ACCELERATOR_VISUALISER_RELEASES_URL` mirror must be HTTPS. A localhost\nexemption (`127.0.0.1`, `::1`, `localhost`) accepts HTTP for integration\ntesting; any other plaintext URL is rejected by the launcher.\n\n### Provenance verification\n\nEvery released binary carries a SLSA build-provenance attestation\n(sigstore-keyless, GitHub Actions OIDC, transparency-log-backed). The default\nSHA-256 check proves the cached binary matches what the build runner produced.\nSetting `ACCELERATOR_VISUALISER_VERIFY_PROVENANCE=1` adds a second layer: the\nlauncher calls `gh attestation verify --repo atomicinnovation/accelerator`\nand refuses to start if the attestation is missing or invalid. Requires\n`gh \u003e= 2.49.0` and network reachability to `api.github.com`.\n\n## Review System\n\nThe `review-pr`, `review-plan`, and `review-work-item` skills use a multi-lens\nreview system. Each lens is a specialised subagent that evaluates the artefact\nthrough a specific quality perspective.\n\n**Code review lenses** (used by `review-pr` and `review-plan`):\n\n| Lens              | Focus                                                                |\n|-------------------|----------------------------------------------------------------------|\n| **Architecture**  | Modularity, coupling, dependency direction, structural drift         |\n| **Code Quality**  | Complexity, design principles, error handling, code smells           |\n| **Compatibility** | API contracts, cross-platform, protocol compliance, deps             |\n| **Correctness**   | Logical validity, boundary conditions, state management, concurrency |\n| **Database**      | Migration safety, schema design, query correctness, integrity        |\n| **Documentation** | Documentation completeness, accuracy, audience fit                   |\n| **Performance**   | Algorithmic efficiency, resource usage, concurrency, caching         |\n| **Portability**   | Environment independence, deployment flexibility, vendor lock        |\n| **Safety**        | Data loss prevention, operational safety, protective mechanisms      |\n| **Security**      | OWASP Top 10, input validation, auth/authz, secrets, data flows      |\n| **Standards**     | Project conventions, API standards, naming, accessibility            |\n| **Test Coverage** | Coverage adequacy, assertion quality, test pyramid, anti-patterns    |\n| **Usability**     | Developer experience, API ergonomics, configuration, migration paths |\n\n**Work item review lenses** (used by `review-work-item`):\n\n| Lens             | Focus                                                          |\n|------------------|----------------------------------------------------------------|\n| **Completeness** | Section presence, content density, type-appropriate content    |\n| **Testability**  | Measurable criteria, verifiable outcomes, verification framing |\n| **Clarity**      | Unambiguous referents, internal consistency, jargon handling   |\n\nLenses are automatically selected based on scope, or you can specify focus\nareas:\n\n```\n/accelerator:review-pr 123 focus on security and architecture\n/accelerator:review-work-item 0042 focus on testability\n```\n\n## Design Convergence\n\nDesign convergence skills capture two design surfaces — a current frontend and a\ntarget prototype — as structured inventory artifacts, then compute a structured\ngap between them. The gap artifact's prose paragraphs satisfy the cue-phrase\ncontract that `extract-work-items` consumes, so the workflow plugs straight into\nthe existing work-item lifecycle. Each inventory snapshot is self-contained\n(markdown plus screenshots in a dated directory); re-running for the same source\nsupersedes the prior snapshot without losing it.\n\n```\ninventory-design (current)  ─┐\n                             ├─▶ analyse-design-gaps ─▶ extract-work-items ─▶ meta/work/*\ninventory-design (target)   ─┘\n```\n\n| Skill                   | Usage                                                                     | Description                                                                               |\n|-------------------------|---------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|\n| **inventory-design**    | `/accelerator:inventory-design [source-id] [location] [--crawler MODE]`   | Generate a design inventory (tokens, components, screens, features) for a frontend source |\n| **analyse-design-gaps** | `/accelerator:analyse-design-gaps [current-source-id] [target-source-id]` | Compute a structured gap between two inventories as actionable prose                      |\n\nThree-step example:\n\n```\n/accelerator:inventory-design current ./apps/webapp\n/accelerator:inventory-design prototype https://prototype.example.com\n/accelerator:analyse-design-gaps current prototype\n```\n\nThe resulting gap artifact under `meta/research/design-gaps/` feeds straight into\n`/accelerator:extract-work-items \u003cgap-file\u003e`.\n\n`inventory-design` supports three crawler modes: `code` (static analysis only,\nno Playwright needed), `runtime` (Playwright executor only), and `hybrid`\n(both, default for code-repo sources).\n\nNew flags: `--allow-internal` (permit RFC1918 / loopback-variant hosts) and\n`--allow-insecure-scheme` (permit plain `http://` to non-localhost public\nhosts). `http://localhost` and `http://127.0.0.1` are accepted without any\nflag.\n\n### Requirements\n\nFor `--crawler runtime` or `--crawler hybrid`:\n\n- **Node ≥ 20** — executor bootstrap and daemon require Node.js 20 or later\n- **macOS or Linux** — Windows is not supported\n- **~500 MB free disk** — first-run Chromium install writes to the cache\n\nRun `ensure-playwright.sh` to bootstrap the executor manually; the skill runs\nit automatically on first use.\n\n### Runtime browser dependency\n\nThe executor (`run.sh`) wraps a Node.js daemon that drives Playwright's\nChromium. On first use with `--crawler runtime|hybrid`, the skill runs\n`ensure-playwright.sh` to install Playwright and Chromium into a per-machine\ncache. Subsequent runs reuse the cache without a network round-trip.\n\nCache root: `~/.cache/accelerator/playwright/\u003csha8\u003e/` (namespace keyed on the\nskill-shipped `package-lock.json` hash).\n\nFor the executor wire protocol see\n[`skills/design/inventory-design/PROTOCOL.md`](skills/design/inventory-design/PROTOCOL.md).\n\n### Cache \u0026 cleanup\n\n| Path | Purpose |\n|------|---------|\n| `~/.cache/accelerator/playwright/` | Per-machine Playwright + Chromium cache |\n| `\u003cproject\u003e/.accelerator/tmp/inventory-design-playwright/` | Per-project daemon state (port file, PID) |\n\nTo reset both:\n\n```bash\nrun.sh daemon-stop\nrm -rf ~/.cache/accelerator/playwright .accelerator/tmp/inventory-design-playwright\n```\n\n### Troubleshooting\n\n- **Hung daemon**: run `run.sh daemon-stop` to shut it down cleanly.\n- **Bootstrap failure**: run `ensure-playwright.sh` directly to see the full\n  error output. Check `NPM_CONFIG_REGISTRY`, `NODE_EXTRA_CA_CERTS`,\n  `HTTPS_PROXY`, and `PLAYWRIGHT_DOWNLOAD_HOST`.\n- **Downgrade to code**: if bootstrap fails in `hybrid` mode the skill\n  automatically falls back to `code`-only crawl with a printed notice.\n\n### Authenticated browser crawls\n\n`/accelerator:inventory-design` reads the following environment variables when\nthe location is a hosted prototype or running app and authentication is\nrequired. They are also read by any future skill that uses the `browser-*`\nagents.\n\n| Variable                          | Purpose                                                          |\n|-----------------------------------|------------------------------------------------------------------|\n| `ACCELERATOR_BROWSER_AUTH_HEADER` | Header injected on navigations to the resolved location's origin |\n| `ACCELERATOR_BROWSER_USERNAME`    | Form-login username (used with `_PASSWORD` and `_LOGIN_URL`)     |\n| `ACCELERATOR_BROWSER_PASSWORD`    | Form-login password                                              |\n| `ACCELERATOR_BROWSER_LOGIN_URL`   | Login form URL                                                   |\n\nPrecedence: if `AUTH_HEADER` is set it takes precedence and the form-login\nvars are ignored (with a warning). If `AUTH_HEADER` is unset, all three of\n`USERNAME`, `PASSWORD`, and `LOGIN_URL` must be set together — partial sets\ncause the skill to fail with a clear error. With none set, auth-walled routes\nare skipped and noted in the inventory's Crawl Notes.\n\nSecurity: `AUTH_HEADER` is sent **only** on navigations whose origin matches\nthe resolved location (or the login URL); cross-origin navigations strip it.\nScreenshots mask password and token fields. The skill refuses to write an\ninventory if any env-var literal appears in the generated body.\n\n### Security considerations\n\n- **Env vars**: store `ACCELERATOR_BROWSER_*` values in your shell profile or\n  a local `.env` file (gitignored), not in committed config.\n- **Screenshots**: each inventory directory contains screenshots committed to\n  the repo. Avoid pointing `inventory-design` at screens that display\n  sensitive personal data, PII, or credentials.\n- **Side-effecting forms**: the `browser-analyser` agent uses `browser_click`\n  and `browser_type` for state-transition testing. Do not point\n  `inventory-design` at production systems with forms that have real-world\n  side effects (payments, email sends, account mutations).\n- **Executor isolation**: the Playwright executor runs as a local TCP daemon on\n  `127.0.0.1` only. It never binds to an external interface. Screenshots mask\n  `[type=password]`, `[autocomplete*=token]`, and `[data-secret]` fields\n  automatically.\n\n## Agents\n\nAccelerator uses specialised subagents to keep the main context lean. Each\nagent runs in its own context window with restricted tools, returning only a\nfocused summary to the parent:\n\n| Agent                       | Role                                                              | Tools                                                                                                                                                                                                                                               |\n|-----------------------------|-------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| **codebase-locator**        | Finds files and components by description                         | Grep, Glob, LS                                                                                                                                                                                                                                      |\n| **codebase-analyser**       | Analyses implementation details of specific components            | Read, Grep, Glob, LS                                                                                                                                                                                                                                |\n| **codebase-pattern-finder** | Finds similar implementations and usage examples                  | Read, Grep, Glob, LS                                                                                                                                                                                                                                |\n| **documents-locator**       | Discovers relevant documents in configured directories            | Grep, Glob, LS                                                                                                                                                                                                                                      |\n| **documents-analyser**      | Extracts insights from meta documents                             | Read, Grep, Glob, LS                                                                                                                                                                                                                                |\n| **reviewer**                | Evaluates code/plans through a specific quality lens              | Read, Grep, Glob, LS                                                                                                                                                                                                                                |\n| **web-search-researcher**   | Researches external documentation and resources                   | WebSearch, WebFetch, Read, Grep, Glob, LS                                                                                                                                                                                                           |\n| **browser-locator**         | Locates routes/screens/components in a running app via Playwright | `Bash(run.sh navigate)`, `Bash(run.sh snapshot)`                   |\n| **browser-analyser**        | Analyses screens, captures state and screenshots via Playwright   | `Bash(run.sh navigate\\|snapshot\\|screenshot\\|evaluate\\|click\\|type\\|wait_for)` |\n\nThe separation between locators (find, no Read) and analysers (understand, with\nRead) is deliberate: it prevents any single agent from needing to both search\nbroadly and read deeply, keeping each agent's context bounded.\n\n`browser-*` agents drive Playwright through the skill-shipped executor\n(`run.sh`), a Bash wrapper around a Node.js TCP daemon that runs Chromium.\nNo MCP server is required. See `skills/design/inventory-design/PROTOCOL.md`\nfor the executor wire protocol.\n\n## Installation\n\nAdd the marketplace and install the plugin:\n\n```bash\n/plugin marketplace add atomicinnovation/accelerator\n/plugin install accelerator@atomic-innovation\n```\n\n### Prerelease Versions\n\nPrerelease versions (`X.Y.Z-pre.N`) are published to GitHub Releases on every\npush to `main`. A separate marketplace file always points to the latest\nprerelease. Add it once:\n\n```bash\n/plugin marketplace add https://raw.githubusercontent.com/atomicinnovation/accelerator/main/.claude-plugin/marketplace-prerelease.json\n/plugin install accelerator@atomic-innovation-prerelease\n```\n\nRe-run `/plugin install accelerator@atomic-innovation-prerelease` to pick up a\nnewer prerelease as they are published.\n\nTo return to the stable channel, uninstall the prerelease plugin and remove its\nmarketplace:\n\n```bash\n/plugin uninstall accelerator@atomic-innovation-prerelease\n/plugin marketplace remove atomic-innovation-prerelease\n/plugin marketplace add atomicinnovation/accelerator\n/plugin install accelerator@atomic-innovation\n```\n\n### Development\n\nTo load from a local checkout:\n\n```bash\nclaude --plugin-dir /path/to/accelerator\n```\n\n### Claude Code compatibility\n\nThis plugin relies on Claude Code's subagent `skills:` preload mechanism\nto inject configuration context into agents (e.g. `accelerator:paths`\ninto the `documents-*` agents, `accelerator:browser-executor` into the\n`browser-*` agents). **Minimum supported Claude Code: v2.1.144.**\nEarlier releases may not support the mechanism; later releases that\nchange subagent skill-preloading semantics will surface the failure via\nthe agents' Preload guards.\n\n## License\n\nMIT — see [LICENSE](LICENSE).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fatomicinnovation%2Faccelerator","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fatomicinnovation%2Faccelerator","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fatomicinnovation%2Faccelerator/lists"}