# Project standards preflight (QA)

> Body of `## Project standards preflight`. Before QA verification in a code repository, call the Peaks-Loop CLI:

- `peaks standards init --project <path> --dry-run`
- `peaks standards update --project <path> --dry-run`

The bundle the CLI writes has three parts: the **body** `AGENTS.md` (always written), the **pointer** `CLAUDE.md` (written only when the IDE profile needs it — a profile that reads `AGENTS.md` directly, e.g. `--ide codex`, writes no pointer), and the **rules tree** under `.peaks/standards/**` (2.0 canonical layout) or `.claude/rules/**` (legacy 1.x project). Judge the preflight from the CLI's own output instead of a hard-coded path: `peaks standards init --project <path> --dry-run --json` reports `data.plannedWrites[]` = `[{ relativePath, status }]`, where `init` reports two states — `planned` (absent → will be created) / `existing` (present on disk; `init` does not compare content, so a stale file still reads `existing`). The four-state view of the body file comes from `peaks standards update --project <path> --dry-run --json`: `planned` (absent) / `appended` (present, managed block missing) / `existing` (present and current) / `review` (present, managed block differs → a human decides; that command exits 1 with code `STANDARDS_UPDATE_REVIEW_REQUIRED`). Those four states cover `AGENTS.md` and, when the IDE profile writes one, `CLAUDE.md`; rules-tree files are `planned` / `existing` in both commands. The `relativePath` values also tell you which rules root this project uses.

If the repo needs a first-time standards bundle, treat `standards init` as the creation path. If the body file (`AGENTS.md`) already exists, use `standards update` to decide whether Peaks-Loop can append a managed block or should only return review suggestions. Apply only when write authorization exists; otherwise keep the CLI output as a preflight next action. Do not hand-write standards file mutations inside the skill.