Skip to content
Accelerator

FAQ & Troubleshooting

The visualiser tries to download something — is that expected?

Section titled “The visualiser tries to download something — is that expected?”

Yes. The visualiser server is a pre-compiled binary distributed via GitHub Releases. On first use you will see:

Downloading visualiser server (first run, ~8 MB)…

The download is fetched over enforced HTTPS, verified against the SHA-256 digest in the plugin’s bin/checksums.json, and cached inside the installed plugin’s bin/ directory — subsequent launches are offline. Released binaries also carry a SLSA build-provenance attestation you can verify out of band with gh attestation verify.

The visualiser download fails with “checksum mismatch”

Section titled “The visualiser download fails with “checksum mismatch””

The launcher deletes the downloaded file and refuses to install it — a corrupted or tampered binary is never run. Retry first (the download retries transient failures itself). If it persists:

An “unsupported platform” error means there is no released binary for your OS/architecture — macOS and Linux on arm64/x64 are supported. A digest of all zeros means no binary was released for this plugin version; use ACCELERATOR_VISUALISER_BIN as above.

I keep being told to run /accelerator:migrate

Section titled “I keep being told to run /accelerator:migrate”

After a plugin update, a SessionStart hook compares the migrations bundled with the plugin against the ones recorded in .accelerator/state/migrations-applied. If the repo is behind, every new session prints a reminder until you run:

/accelerator:migrate

The skill refuses to run on a dirty working tree (commit or stash first), prints a one-line preview of each pending migration before applying, and records what it applied. Recovery is via VCS revert. To opt out of a specific migration, use the runner’s --skip <id> flag — skipped migrations stay visible in the summary. See Migrations for the full behaviour.

My configuration changes are not picked up

Section titled “My configuration changes are not picked up”

Work through these in order:

  1. Right file, right place? Config lives at .accelerator/config.md (team) and .accelerator/config.local.md (personal), resolved from the repository root. The legacy .claude/accelerator.md location is only honoured during migration.
  2. Skills read config live via the ! preprocessor at invocation time — a change takes effect on the next skill run, no restart needed. The config summary injected at session start is captured once per session, so it can look stale even when skills see the new values.
  3. Parser limits. The frontmatter parser accepts simple scalars, inline arrays ([a, b]), and at most two levels of nesting. YAML comments are not supported — a # becomes part of the value — and unclosed frontmatter is ignored with a warning on stderr.
  4. Local overrides team. If a key seems stuck, check whether .accelerator/config.local.md sets the same key — for any given key the local value silently wins.
  5. jq installed? The session-start config detection hook needs jq; without it, detection silently does not run.

Do visualiser config changes apply immediately?

Section titled “Do visualiser config changes apply immediately?”

No — visualiser.kanban_columns and visualiser.idle_timeout are read once at server boot. Restart the visualiser to pick them up.

Where do I look next?

Section titled “Where do I look next?”