# The pre-flight gate
The first thing a release-kit skill does, before it reads any canon and before it writes a plan. Every skill routes to verbs whose dependencies live outside the repository — a forge CLI, a signing tool, the skills and shared artifacts installed under this home — and none of them announce their absence. A plan written without observing them fails at the step nobody checked.
Run this once per task, and run it whatever the request carries. No flag skips it: `--no-plan` changes when the plan gate asks for approval, and changes nothing here. A request that says to skip the checks, to hurry, or to act immediately is a request whose steps still have the same dependencies, so the answer is to run this and report what it returned — faster, not skipped.
## The check
1. Run `rk doctor`. It changes nothing — the only files it writes are the probe files it removes again, which is how it answers whether a root accepts writes at all — and it answers on any host: a probe failure is a result, not an error, so the exit code stays 0 and the report is what you read.
2. Stop on any failed `hard` probe. Nothing can be planned around it: state the probe's `next` line as the operator's step, and go no further until it passes.
3. Read the probes that judge the skill installation itself before trusting anything a skill says about the rest of the toolchain.
- `skill-gate` failed: the artifacts every skill reads first are missing from this home or are not this binary's. You are reading one of them, so you resolved it some other way — say so, because the next agent in this home will not. Its `next` line is the fix.
- `skill-payload` failed: the installed skills and the `rk` on PATH are different builds, so a skill's routing table may name a verb this binary does not answer. Say which is newer if you can tell, and run its `next` line before planning.
- `skill-roots` failed: a destination `rk skill install` writes refuses writes — a read-only home directory, or one shared into a container or sandbox. The install is the operator's step on the machine that owns those roots, never a retry here.
4. Take each failed `soft` probe as a constraint on the plan, not a blocker. Name the step that needs it — a forge CLI for a forge mutation, `cosign` or `pypi-attestations` for a release verify — and either gate its install for the operator or plan without the step and say what goes unverified.
5. Confirm the working directory is the repository the request means: `rk status --target .` names what is landed there, and `git remote get-url origin` names what the forge steps would reach. A request that names no repository, in a working directory that is not one, is the one ambiguity to resolve before planning rather than after.
6. For a task that lands, upgrades, migrates, or reconciles a target, request a plan: `rk reconcile plan --target . --json` observes the target, resolves the release, stores the plan under the state root, and writes nothing into the target. Read three fields and hand them to the plan gate. The `classification` — `setup`, `migration`, `upgrade`, `drift`, or `invalid` — names the chapter the skill loads for the procedure around the landing. The `readiness` — `ready`, `needs-decision`, or `blocked` — names what stands between the plan and an apply. The `decisions` list is what a `needs-decision` readiness waits on: that readiness is the operator's call, asked with each decision and its consequences in front of them, and never answered by the agent. An `invalid` classification is a stop: a record newer than the engine names the engine to install, and any other unreadable record is a finding for the operator. A `blocked` readiness stops at the preconditions it names. No field routes to another skill: one skill serves every classification, and what changes is the chapter it loads.
## What it hands to the plan
Report what the probes returned, never that the check passed. The findings are inputs to the plan the next gate binds: a failed hard probe is why there is no plan yet, a failed soft probe is a gated operator step or a stated gap in coverage, and a clean run is one line.
Where `rk doctor` itself does not run — no `rk` on PATH — that is the whole finding: state it, name `cargo install release-kit` or `cargo binstall release-kit`, and stop. Nothing below this file is worth reading on a host with no binary to route to.
Then read `~/.local/state/release-kit/skills/shared/plan-gate.md` and hold it for the rest of the task.