| name | ralplan |
| description | Produce an implementation-ready plan with risks, acceptance criteria, and test shape. Use with /ralplan when edits need planning first. |
Ralplan
Use /ralplan when the task needs planning before edits.
When to use
- The change touches multiple files or components
- There are unclear trade-offs or risks
- You need alignment before implementation
Steps
- Summarise the target result and constraints in 2–3 sentences
- List implementation slices in execution order — each slice should be independently verifiable
- Define acceptance criteria — what must be true when done
- Define test shape — which tests to write or run, what they cover
- Call out risks — what could go wrong, tradeoffs chosen, alternatives rejected. For any
auth, security, or data-handling feature, the plan must name the security specifics even
if the request didn't: secret/token expiry, single-use / replay protection, and
enumeration / rate-limiting. Leaving these implicit is how the plan ships a hole.
- Stop at the plan unless the user explicitly asked to implement
Output
Plan — ordered implementation slices with file-level specificity
Tests — acceptance criteria and test shape for each slice
Risks — tradeoffs, concerns, and what was deliberately not done
Ready for — recommended next skill: /team, /ralph, /ultrawork, or direct edit