/crisp-brief
Turn a vague request into a clear brief.
(What it does)
Turns vague requests into clear ones. /crisp-brief takes something like "can we improve the dashboard?" and questions it until it becomes a scoped, unambiguous .brief.md. The brief covers the real problem, the specific user, success criteria you can observe, what is in and out of scope, constraints, anti-goals (what the design must not become), and the CRISP dimension that matters most.
It will not write the brief while anything is still unclear. If a request describes a solution, defines success as a feature, or has no limits on scope, it pushes back with a sharpening question first.
(When to use it)
Use it before design work starts:
- A request arrived as one vague sentence and everyone has a different idea of what it means
- Success is defined as a feature ("build a dashboard") rather than an outcome
- Scope keeps growing because nothing was ever ruled out
- You want
/feature-designto start from a real problem statement instead of a guess
(What you get)
- .brief.md saved to your project root
- Scoped problem statement
- Success criteria you can observe
- CRISP dimension priority
(Example output)
Illustrative example only. This is not a real audit.
(Problem sharpening)
It flags four patterns before writing the brief:
- The request describes a solution, not a problem. What makes users need this in the first place?
- Success is described as a feature, not an outcome. What could a user do if this worked?
- The scope has no limits. What is explicitly not included?
- The user is not named. Who exactly will use this design?
(Common questions)
How many questions will it ask?
Two if .crisp.md exists: the request in one sentence, and the outcome that would prove it worked. Five if there is no project context. The interview is short on purpose. The sharpening comes from the pushback, not the number of questions.
How does it choose the CRISP priority?
It reads the request for clues, proposes the most likely main dimension, and asks you to confirm or correct it. You get a recommendation, not a menu. For example, an interrupted workflow points to Seamless, and confusion about what just happened points to Contextual.
What is an anti-goal?
A clear statement of what the design should not be: not a modal, not a settings page, not optimised for first-time users. Anti-goals stop the wrong reference pattern creeping in during design and review.
What do I do with the finished brief?
Run /feature-design. It reads .brief.md and .crisp.md together, so the flow it designs is based on the problem, the user, and the success criteria you have just agreed.
(Install)
Installs all fourteen CRISP skills and detects which AI coding tool you use. Run /crisp-teach once per project, before the other skills.
(Related skills)