flow-preflightlisted

## Procedure 1. Get the project name: `!`project-name.sh``. Stack is in the injected `<repo-context>` block. 2. Session continuity check. If a previous preflight artifact exists for this project from this session (`ls -t ~/.claude/scratch/preflight-<project-name>-*.md | head -1`), compare current `git status` and `git log -5 --oneline` against the artifact's recorded state. If unchanged AND the new task's target area is covered by the previous artifact, emit a delta-only report ("same context as preflight-<project-name>-<HHMM>, no new findings, target area X already covered") and stop. Otherwise proceed to step 3. This short-circuit is opt-in by signal: when it fires, state that it fired and why; when it does not hold, fall through to the full preflight, not a half-done one. `--full` in $ARGUMENTS skips this check and forces a full preflight. 3. Read `CLAUDE.md` at the project root in full. Read any `CLAUDE.md` in the path from project root to the target area. 4. Read project README only if it explicitly covers the task area, judged from headings. 5. Identify the minimum file set the task touches: the files that will change, plus the files that the changing files import or depend on. No more, no less. 6. Requirements clarity check. Before reading the minimum file set, evaluate the task statement from $ARGUMENTS or the prior conversation against: - Testable: can pass/fail be observed without ambiguity? If "improve X" or "make Y better" without a measurable signal, flag.