Inside any FlowRail-installed repo, drop a markdown spec under specs/. FlowRail watches for files matching specs/**/*.spec.md.
# Password reset flow ## Functional - POST /auth/reset accepts an email, sends a magic link. - Token is single-use, expires in 15 minutes. ## Security - Reveal nothing about whether the email is registered. - Token compared with timing-safe equality.
Now ask Claude to implement it. Before any code is written, FlowRail opens the review and returns a unique id (dr_…). You'll see it in Claude's tool stream. Nothing to confirm.
↳ flowrail-design-review spec specs/password-reset.spec.md threats 4 (2 high, 2 med) review dr_7f3a9e2c ↳ writing src/auth/reset.ts…
From here, every write Claude attempts is checked against the threats this review predicted. Every dependency it tries to install is checked against the approved list. In v1, every scanner finding that lands later is triaged with the review as context. You never pass dr_7f3a9e2c anywhere; the IDE attaches it to all of these calls.
How it threads
The skill writes the active id to .flowrail/context.json. Subsequent verify and dep-check calls read this file and forward design_review_id on every MCP call, so all downstream events thread under the same dr in your audit log.
.flowrail/context.json
{
"active_design_review_id": "dr_7f3a9e2c",
"spec_path": "specs/password-reset.spec.md",
"created_at": "2026-05-03T07:00:00Z"
}