From buildkite
Runs Buildkite CI builds against changes in the local working tree. Use when asked to run preflight or run CI.
npx claudepluginhub buildkite/skills --plugin buildkiteThis skill uses the workspace's default tool permissions.
Preflight runs CI builds against changes in the local working directory. It's intended to provide a feedback loop for evaluating local changes in CI by providing a single command to run the entire commit/push/run loop.
This skill should be used when the user asks to "write a pipeline", "add caching", "make this build faster", "show test failures in the build page", "add annotations", "only run tests when code changes", "set up dynamic pipelines", "add retry", "parallel steps", "matrix build", "add plugins", or "work with artifacts in pipeline YAML". Also use when the user mentions .buildkite/ directory, pipeline.yml, buildkite-agent pipeline upload, step types (command, wait, block, trigger, group, input), if_changed, notify, concurrency, or asks about Buildkite CI configuration.
Automates CI/CD pipeline setup with quality gates for linting, type checking, testing, building, security audits, and deployments using GitHub Actions. Use for new projects, modifying pipelines, or debugging failures.
Monitors Nx Cloud CI pipelines for current branch, tracks status, and applies self-healing fixes via Nx Cloud integration.
Share bugs, ideas, or general feedback.
Preflight runs CI builds against changes in the local working directory. It's intended to provide a feedback loop for evaluating local changes in CI by providing a single command to run the entire commit/push/run loop.
{org}/{pipeline} formbk auth is pointed at the right Buildkite organization when the pipeline slug relies on local configoriginread_builds, write_builds, and read_pipelines scopes; and read_suites for Test Engine results.# Human-readable output that works well in agent shells
bk preflight --pipeline my-org/my-pipeline --watch --text
# Start a run and return as soon as the build enters the failing state
bk preflight --pipeline my-org/my-pipeline --watch
# Wait for a terminal build state instead of fast-failing
bk preflight --pipeline my-org/my-pipeline --watch --exit-on=build-terminal
# Start the build and exit immediately
bk preflight --pipeline my-org/my-pipeline --no-watch
# Leave the remote preflight branch and build running on early exit
bk preflight --pipeline my-org/my-pipeline --watch --no-cleanup
# Wait for 30s after build completion for Test Engine summaries
bk preflight --pipeline my-org/my-pipeline --watch --await-test-results 30s
Do not set a timeout on a watched preflight run.
Preflight executes the following workflow:
HEAD, even when the tree is clean, so the run has its own commit status context.refs/heads/bk/preflight/<uuid> on origin.PREFLIGHT=true, PREFLIGHT_SOURCE_COMMIT, and PREFLIGHT_SOURCE_BRANCH when available.--no-cleanup is set. With the default --exit-on=build-failing, early exit also cancels the remote build unless --no-cleanup is set.The working tree is never disrupted, so you can keep editing while the build runs.
build-failing, so the preflight command exits as soon as the build enters the failing state.--exit-on=build-terminal waits for a terminal build state (passed, failed, canceled).--await-test-results waits after build completion for Test Engine rollups when test runs exist.bk job log -b <build-number> -p <org>/<pipeline> <job-id> to inspect logs.Extracting results from the JSON build_summary event:
Just the failed jobs from the summary:
bk preflight --pipeline my-org/my-pipeline --watch --json \
| jq -nrc --unbuffered 'inputs | select(.type == "build_summary") | .failed_jobs'
Just the failed tests from the summary:
bk preflight --pipeline my-org/my-pipeline --watch --json \
| jq -nrc --unbuffered 'inputs | select(.type == "build_summary") | .tests.failures'
--text for plain text logs that are easy to read in tool output--json when you need structured event databk uses the interactive TTY UI when stdout is a terminal and plain text otherwise# Run preflight and watch until completion
bk preflight --pipeline my-org/my-pipeline --watch
# Run without watching (starts the build and exits)
bk preflight --pipeline my-org/my-pipeline --no-watch
# Skip confirmation prompts (useful in scripts)
bk preflight --pipeline my-org/my-pipeline --watch --yes
# Keep the remote preflight branch after the build finishes
bk preflight --pipeline my-org/my-pipeline --watch --no-cleanup
# Use plain text output in non-interactive environments
bk preflight --pipeline my-org/my-pipeline --watch --text
# Use JSONL output when another tool needs structured events
bk preflight --pipeline my-org/my-pipeline --watch --json
# Wait for 10s for Test Engine results after build completion
bk preflight --pipeline my-org/my-pipeline --watch --await-test-results 10s
Do not set a timeout on the bash tool running preflight.
The --pipeline flag accepts either a pipeline slug or {org slug}/{pipeline slug}:
# With org prefix (explicit)
bk preflight --pipeline my-org/my-pipeline --watch
# Pipeline slug only (org resolved from bk config)
bk preflight --pipeline my-pipeline --watch
| Flag | Short | Default | Description |
|---|---|---|---|
--pipeline | -p | - | Pipeline to build ({slug} or {org}/{slug}) (required) |
--[no-]watch | - | Watch the build until completion | |
--exit-on | build-failing | Exit on build-failing or build-terminal | |
--interval | 2 | Polling interval in seconds when watching | |
--no-cleanup | false | Skip deleting the remote preflight branch after the build finishes | |
--await-test-results | Wait for Test Engine summaries after build completion | ||
--text | false | Use plain text output instead of the interactive UI | |
--json | false | Emit one JSON object per event (JSONL) | |
--yes | -y | false | Skip all confirmation prompts |
--no-input | false | Disable all interactive prompts | |
--quiet | -q | false | Suppress progress output |
--no-pager | false | Disable pager for text output | |
--debug | false | Enable debug output for REST API calls |
Check the exit code to determine the build result:
| Exit Code | Meaning | Action |
|---|---|---|
0 | All command jobs passed | Proceed with commit/push |
1 | Generic error | Check error message for details |
9 | Build completed with failures | Examine failed jobs and fix |
10 | Build incomplete but failures observed | Build still running; failures already detected |
11 | Build incomplete (scheduled/running/blocked) | Build hasn't finished yet |
12 | Unknown build state | Investigate the build on Buildkite |
130 | User aborted (Ctrl+C) | Re-run when ready |
Begin fixing the first failure as soon as preflight exits with an incomplete build result because the build is failing, and then check back on the same build with bk build view for subsequent failures. This allows you to quickly iterate on the first failure, and gather further failures in parallel. Use the bk preflight --no-cleanup option to ensure that build is not cancled on fast failure.
bk preflight --pipeline my-org/my-pipeline --watch --no-cleanup --text
bk preflight will return as soon as the build transitions to failing, using the default --exit-on=build-failing behavior. Setting the --no-cleanup flag is required if you want the build to continue running to completion.
Workflow:
bk build view to check the same build again while it continues running:bk build view <build-number> -p my-org/my-pipeline --text
bk preflight cleanup --pipeline my-org/my-pipeline --preflight-uuid <uuid> --yes --text
bk preflight cleanup only deletes completed preflight branches, so run it after the build has finished.