Diagnose and fix LSP setup for the current project's detected ecosystems (Rust, TypeScript, Ruby). Use when the SessionStart hook nudged about a missing LSP plugin, when the env isn't ready (no `bundle install`, no `cargo build`, missing server binary), when LSP calls are failing, or when the user invokes `/actually-lsp-doctor` directly. Walks the per-ecosystem state machine, reports what's missing, then runs the fix.

Use when adding Renovate to a repo, moving a repo's renovate.json onto the shared technicalpickles/renovate-config presets, or previewing what Renovate would open before a config merges. Detects ecosystems and CI, writes the one-line config, dry-runs it, and opens the PR.

Use when APIs fail repeatedly with version-related errors (method not found, wrong arguments, unknown flag) or when about to use library APIs with uncertain knowledge - guides finding current, accurate documentation instead of guessing from training data

Use when a command mentions `av`, Automic Vault or automic-vault, when a task needs a credential (GitHub token, API key, SSH key, GPG signing) on a Mac that has Automic Vault installed, or when gh, git push, git commit signing or an `av` command fails with an approval, sandbox, "agent refused operation" or -25308 error

Use when a reply will hand the user a result they'll act on or repeat to others. You MUST load this at the start of the turn, before other tools, when the user asks you to finish or fix something and confirm it works, report whether something is done, shipped, merged, fixed, or still broken, fetch or refresh data and report a value they need for other work, pick up work from a handoff, notes, or an earlier session, choose between approaches ("should we X or Y", "what would you do"), or summarize work for someone who wasn't there. Also load it whenever the user pushes back on something you said earlier in this conversation, like asking you to retry what you called failed or blocked, "is it really", "are you sure", "confirm first", asking whether you verified a claim, or asking what a term or label you used means. Load it even when you already plan to verify. Skip for a single command or edit the user fully specified where the reply is just its outcome, and for pure writing or explaining tasks.

Use when building, improving, or reviewing command-line interfaces for better user experience - before implementing commands/output/errors, when users report confusion or frustration, or when CLI feels hard to use - provides UX principles, visual design techniques, and practical patterns for creating discoverable, delightful CLIs

Use when creating, modifying, or debugging Buildkite pipeline YAML files - ensures current syntax from official docs, validates configurations before proposing changes, and references Buildkite best practices instead of relying on training data

Review routing corrections and propose updates to vault CLAUDE.md routing rules.

Turn an ingested insight into a proper zettelkasten note with clean prose. Stage 2 of the processing pipeline.

Use when working with Buildkite CI - checking status, investigating failures, and reproducing issues locally. Provides workflows for monitoring builds, progressive failure investigation, and local reproduction strategies. Use when tempted to use GitHub tools instead of Buildkite-native tools, or when a Buildkite tool fails and you want to fall back to familiar alternatives.

Link a processed note to today's daily note. Stage 5 of the processing pipeline.

Save current work context for later resumption

Process accumulated inbox notes through the full pipeline (ingest, enrich, route, connect, link). User-facing orchestrator.

Use when a Bash command fails in the sandbox, or when considering whether to use dangerouslyDisableSandbox. Guides sandbox-first execution and sandbox config diagnosis.

Use when creating handoff documentation for branched conversations in stay-on-target focused mode