Run a deterministic preflight before your agent starts building

An agent will happily build from a spec that can't be verified, has no constraints, and states its outcome as a vibe. You find out three hours of compute later. The preflight is the gate before that: a deterministic readiness check that scores the spec against six calibrated gates and names the exact blockers, before a line of code changes. No model call, no account, no API key. The same spec always gets the same verdict.

The input

An intent.md in your repo. Rough is fine; the point of the preflight is to tell you precisely where it's rough. If you don't have one yet, the compile conversation drafts it first.

The flow

1. Install once, keyless. In Claude Code: /plugin marketplace add pathmodeio/claude-plugin, then /preflight. In any other MCP client, npx @pathmode/mcp-server with no key runs in local mode and exposes check_intent_readiness. Nothing leaves your machine; your spec stays in your repo. There's also a zero-install version: paste a spec at preflight.pathmode.io.

2. The gate runs six checks. Title, objective, outcomes, constraints, edge cases, verification. Each is a pure function calibrated against a labeled corpus of real specs, not a model's opinion. That's what makes the verdict worth gating on: it's reproducible, and you can enforce it in CI.

3. A failing verdict names the blockers. Not "this spec could be stronger" but "outcomes are not observable, verification has no fastest check." Each blocker is a specific field with a specific defect.

4. Repair one question at a time. This is where the conversation earns its place: for each named blocker, the agent asks one targeted question, folds your answer into the spec, and re-runs the gate. Every save stamps the current verdict into the file's frontmatter, so the spec carries its own readiness state.

5. Hand off when it passes. A passing verdict means the agent starts from outcomes it can verify and constraints it must respect, instead of improvising both.

The output

• A verdict you can gate on: deterministic, named blockers, same input same output
• A repaired intent.md in your repo, round-trippable, with the verdict in its frontmatter
• An agent run that starts grounded, because the gaps were closed before the build, not discovered during it

Why this beats asking the model "is this spec ready?"

A model's answer changes run to run, flatters what you wrote, and can't be enforced anywhere. The preflight is the opposite kind of thing: calibrated pure functions with a stable contract. You can disagree with a gate, but you can't get a different answer by asking again nicely. That's what lets a team (or a CI job) treat readiness as a real gate instead of a mood.

Try it yourself

1. /plugin marketplace add pathmodeio/claude-plugin in Claude Code
2. Run /preflight on the repo's intent.md (or paste one at preflight.pathmode.io)
3. Answer the repair questions until the verdict flips
4. Hand the passing spec to your agent

Related

• Use case: Hand off a spec to Claude Code without losing context
• Use case: Audit a draft spec for missing edge cases
• Playbook: The Anatomy of an Agent-Ready Spec