AI Agent Workflow Collection

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.

Ignore actually-lsp nudges for an ecosystem in this project. Use when the user wants to silence, dismiss, or ignore the LSP setup nudges for a specific ecosystem (Rust, TypeScript, Ruby), or invokes /actually-lsp-ignore directly. Writes dismissed=true to .claude/actually-lsp.json. Persistent across sessions for this project only.

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 -…

Use when creating, modifying, or debugging Buildkite pipeline YAML files - ensures current syntax from official docs, validates configurations before proposing changes,…

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

Use when CI is failing on a branch, PR, or specific Buildkite build and the user wants to iteratively fix it through verify-locally → push → check → iterate. Strong signals: "fix CI", "make CI green", "CI is failing", "tests are failing in Buildkite", "iterate on this build", a Buildkite build URL paired with intent to push fixes, a PR with a red check the user wants to make green, or repeat-push debugging. Covers verify-fix-locally workflows (rspec, jest, lint, type checking before pushing), iteration tracking across multiple builds, and knowing when to step back after N failed attempts. Do NOT use for first-time investigation of a build (use buildkite:investigating-builds for "why did this fail" without a fix-and-push intent). Do NOT use for authoring pipeline YAML or adding pipeline steps (use buildkite:developing-pipelines). Do NOT use for GitHub Actions debugging or non-Buildkite CI. This skill drives the fix loop; investigation is delegated to buildkite:investigating-builds.

Use when about to lock in a non-trivial or hard-to-reverse decision, fire AskUserQuestion to offload a call, proceed on your own preferred option, or assert something is done / found / tested / fixed / "that's how it works" — especially when the basis is memory, the handoff, the first framing, or an unchecked assumption rather than something verified this session. Also invoked as /gut-check. Use even when you feel confident; confidence is the symptom, not the all-clear.

Use when the user is working with an existing Buildkite CI run and wants to understand, diagnose, or act on it. Strong signals: a buildkite.com URL, the word "buildkite", the bk CLI, the bktide tool, or a reference to a specific pipeline, build, or job. Covers intents like: "why did this build fail", "what's flaking", "summarize pass/fail rates across recent builds", "pull logs for this job", "figure out the exact command CI ran so I can reproduce it locally" (often via docker-compose), "why didn't my downstream build trigger", and debugging bk/bktide behavior itself (auth failures, query errors, sandbox issues). Do NOT use for authoring pipeline YAML or adding pipeline steps (that's buildkite:developing-pipelines). Do NOT use for meta-work on the Claude buildkite plugin itself (editing SKILL.md, reviewing pickled-claude-plugins PRs, adding reference docs under the plugin's directory). Do NOT use for GitHub Actions, PR review, app code changes, git merge conflicts, or local bk config (~/.bk/config.yml) that don't involve investigating an actual build. This skill reads and investigates CI runs that already exist.

Use whenever the user mentions a GitHub Actions / GHA run, even casually — invoke this skill before reaching for raw gh commands, because the bundled gha-snapshot helper distills gh run view --log-failed (a firehose) into a readable block with per-job status, failed-step log tails, and annotations. Specific triggers (any one is enough): a github.com/.../actions/runs/... URL; the phrase "GitHub Actions" or "GHA"; the gh run CLI; a failing workflow / job / step / check; a PR with red GHA checks; ::error file=...,line=... log annotations; "Resource not accessible by integration" permission errors; matrix or reusable-workflow failures; "is this flaking or a real bug"; "what failed on my last push"; "the CI on my PR is red"; "pull the log for the failing job"; "what step broke"; rerun-status check-ins ("did it pass this time?"); root-cause hunts across matrix legs or needs: cascades. Do NOT use for authoring .github/workflows/.yml YAML (not in scope). Do NOT use for Buildkite (use the buildkite plugin). Do NOT use for local-only test failures where no remote run exists, action-version migration questions, self-hosted runner setup, secret rotation, or meta-work on this plugin itself.

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

Save current work context for later…

Use when the user has authored a GitHub pull request and wants to work through review feedback on it. Triggers on phrases like "pull down the review on N", "address the feedback", "what did @reviewer say on my PR", "let's work through the comments", or any request to triage, respond to, or systematically handle review threads on the user's own PR. Do NOT use for reviewing someone else's PR, authoring PR content or replies, or checking which PRs are waiting on the user for review.

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

Resume work from a parked…

Use when working in repositories with multiple subprojects (monorepos) where commands need to run from specific directories - prevents directory confusion, redundant cd commands, and ensures commands execute from correct…

Use when user mentions MCPProxy/MCP tools (e.g., "check buildkite mcp", "use slack mcp") or when you need to discover or call tools through MCPProxy - immediately checks if mcpMCPProxy tools are available, suggests /mcp reconnect if missing (MCPProxy MCP server not connected), explains when to use MCP tools vs HTTP API for…

Use when adding, configuring, or troubleshooting mise-managed tools - ensures proper CLI usage, detects existing config files, and diagnoses PATH/activation issues when commands aren't…

Use when structuring prose so readers can skim it - drafting or restructuring READMEs, docs, PR or issue bodies, design docs, RFCs, or any long-form text where a wall of prose hides the structure. Also use when explicitly asked to make something scannable or skimmable, convert prose to a list, surface a buried list, fix a wall of text, or decide whether bullets or prose fit. Strong signal: text with parallel sentence shapes, contrast markers ("that's distinct from", "versus"), bolded terms followed by colons, or an embedded "X, Y, and Z" series. Composes with prose-clarity skills (concision) and voice skills (personality) rather than replacing them. Skip for source code and for casual one-line replies where formatting reads as overkill.