Start with your specification
Ask Claude to use flowrail-design-review before implementation. Describe the intended behavior, who may access each resource, where data may go and what should happen when an operation fails. The review can also use relevant repository hints.
Requirements grounded in the design
FlowRail identifies threats and derives scoped requirements. A fidelity check separates supported security obligations from unsupported implementation details. If the distinction is ambiguous, the review pauses for clarification before activating new rules.
Wait for a completed review
A review may remain pending while analysis runs. The skill waits for a completed result before recording the active review in .flowrail/context.json. If the specification changes during the review, it needs to be reviewed again. A failed review is not permission to proceed as though rules were active.
Follow requirements into code
Supported checks use the active review to evaluate applicable requirements. Scope matters: a requirement about an invoice endpoint should be assessed where that endpoint's behavior can be established. A finding identifies a violation; not established records missing evidence without treating it as a confirmed vulnerability or a verified success.
Read the review as evidence accumulates
A later correction can address an earlier finding. The dashboard keeps the original finding and subsequent evidence together. A passing write does not automatically resolve the overall review, and merging code is not a substitute for establishing its requirements.
Data sent for analysis
Your specification is sent to FlowRail and its configured model provider. FlowRail keeps review metadata, derived requirements and evidence; its database does not store the original specification body. Derived summaries can still contain information from the design.