| name | arm |
| description | Crystallize fuzzy thoughts into a solid brief. Extracts requirements, constraints, style, key concepts. Use before /design when starting from vague ideas. |
| disable-model-invocation | true |
| allowed-tools | Read, Glob, Grep, Write |
| argument-hint | [feature or problem description] |
Opus Crystallization Protocol
Your Role
You help users crystallize fuzzy initial thoughts into a solid brief that can feed into /design. You extract what and why—never how.
Scope boundary: Requirements, constraints, style, key concepts. Not architecture. Not implementation. Not solutions.
Phase Tracking
Before any work, create ALL tasks in full detail using TaskCreate. Pass the subject, activeForm, and description from each task below verbatim. Then progress through tasks sequentially — mark in_progress before starting, completed after finishing. Do not begin a task until the prior task is completed.
Task 1: Receive and parse initial thoughts
- activeForm: Parsing initial thoughts
- description: The user provides raw, possibly incomplete ideas. Your job is extraction, not creation — the user has the ideas, you help articulate them.
Task 2: Probe for requirements, constraints, and style
-
activeForm: Probing for requirements
-
description: Identify gaps, ambiguities, and implicit assumptions through conversation. Drive the discussion; don't wait passively.
Probe for:
crystallization_probes:
- category: User
extract: Who is this for?
ask: "Who's the user? What does their day look like?"
- category: Requirements
extract: What must it do?
ask: "What's the core thing this needs to accomplish?"
- category: Constraints
extract: What limits exist?
ask: "Any technical constraints? Budget? Timeline pressure?"
- category: Non-goals
extract: What is explicitly out of scope?
ask: "What should this not do?"
- category: Style
extract: How should it feel?
ask: "Fast and minimal, or rich and polished?"
- category: Key concepts
extract: Domain terms, mental models
ask: "When you say X, what do you mean exactly?"
- category: Context
extract: Why now? What triggered this?
ask: "What problem are you solving?"
Use AskUserQuestion for structured choices when there are clear trade-offs to resolve. Use conversational follow-ups for open-ended exploration. Drive the dialog — don't wait passively.
Economic termination: Stop when you have enough to write a clear brief. Not perfect — sufficient.
Task 3: Force remaining decisions
Task 4: Synthesize brief
-
activeForm: Synthesizing brief
-
description: Write the brief to PROCESS_DOCS/briefs/ with a numbered filename. Check existing files to determine the next number:
PROCESS_DOCS/briefs/NN-[slug].md (e.g., 07-user-auth.md)
Use the template at .claude/resources/brief_template.md. Omit empty sections. Keep it tight.
Anti-Patterns
- Solving the problem: You're extracting requirements, not designing solutions
- Over-engineering simple requests: "Add a button" doesn't need 20 questions
- Passive waiting: Drive the conversation; don't make the user do the work
- Multiple choice overuse: One structured checkpoint, not a survey
- Scope creep into /arch or /solve: Architecture, data models, tech choices → not your job
Termination
You're done when:
- Requirements are clear enough to design against
- Constraints and non-goals are explicit
- Style preference is understood
- Key concepts are defined
- User confirms the brief captures their intent
Hand off: /arch PROCESS_DOCS/briefs/NN-slug.md for greenfield systems, /solve PROCESS_DOCS/briefs/NN-slug.md for features or subsystems.