Goal Definition
Take a raw idea or request and turn it into a clear, actionable goal with explicit success criteria, assumptions, and constraints.
When to Use
- You have a vague idea or user request that needs sharpening
- Before brainstorming approaches — define the "what" before the "how"
- Requirements are ambiguous or incomplete
- You need to align on success criteria before investing in design
- Assumptions are lurking but haven't been stated
When NOT to use: The goal is already crystal clear with written success criteria, or a goal-definition.md already exists and is still accurate.
Input
- Raw idea or request from the user
context-map.mdfrom the artifact folder (recommended but not required)- See
references/context-sources.mdfor additional project documentation that may provide context
Output
goal-definition.mdsaved to the artifact folder (seereferences/formats.mdfor template)
The Process
Step 1: Locate Artifact Folder
If context-map.md exists in a known artifact folder, use that same folder. Otherwise, ask the user for the artifact folder path (same as research Step 1).
Step 2: Restate as "How Might We"
Take the raw idea and reframe it as a crisp problem statement:
Raw: "We need better search" Reframed: "How might we help users find the content they need in under 3 seconds?"
This forces clarity on what's actually being solved. Present the reframed statement and confirm with the user before proceeding.
Step 3: Ask Sharpening Questions
Ask 3-5 targeted questions — no more. One question per message. Focus on:
- Who is this for? — The specific user and their situation
- What does success look like? — Concrete, observable outcomes
- What are the real constraints? — Time, tech, resources, compatibility
- What's been tried before? — Prior attempts, why they failed or didn't happen
- Why now? — What changed that makes this important
Use structured options where possible:
What is the primary user for this feature?
A. New users during onboarding
B. Power users with large datasets
C. All users equally
D. Internal team / admin usersDo NOT proceed until you understand who this is for and what success looks like. These two answers shape everything downstream.
Step 4: Surface Assumptions
Before writing the goal document, list every assumption you're making:
ASSUMPTIONS I'M MAKING:
1. The existing search index can handle the new query patterns
2. Users primarily search by title, not content
3. We can add a new API endpoint without breaking existing clients
4. Response time under 500ms is achievable with current infrastructure
→ Correct me now or I'll proceed with these.Wait for confirmation. Unvalidated assumptions are the #1 source of wasted work downstream.
Step 5: Reframe as Testable Success Criteria
Turn vague goals into concrete, testable conditions:
Vague: "Make search better" Testable: - Search returns relevant results for 90% of common queries - Results appear within 500ms - Users can filter by date, type, and author - Zero-results page suggests alternative queries
Present and confirm with the user.
Step 6: Define Scope Boundaries
State explicitly what is NOT included and why:
- Not Doing: [Thing] — [Reason]
- Not Doing: [Thing] — [Reason]
The "Not Doing" list is arguably the most valuable part. Focus is about saying no to good ideas.
Step 7: Write Goal Definition
Write goal-definition.md to the artifact folder using the template from references/formats.md. Include all findings from Steps 2-6.
Announce the saved path:
"Goal definition saved to [path]/goal-definition.md."Common Rationalizations
| Rationalization | Reality |
|---|---|
| "The goal is obvious" | Obvious goals have hidden assumptions. Write them down — it takes 5 minutes. |
| "We'll figure out success criteria later" | Without success criteria, you can't know when you're done. Define them now. |
| "I don't want to constrain the solution" | Goal definition constrains the problem, not the solution. Brainstorming handles solutions. |
| "The user already told me what they want" | Users describe solutions. Your job is to uncover the underlying problem. |
| "Assumptions are too early to surface" | The earlier you surface assumptions, the cheaper they are to correct. |
Red Flags
- Jumping to solutions before defining the problem
- No "who is this for" answer
- Success criteria that say "works correctly" or "is fast"
- No assumptions listed
- Empty "Not Doing" list — everything has scope boundaries
- Proceeding without user confirmation on reframed problem
Verification
Before handing off, confirm:
- Problem restated as "How Might We" and confirmed by user
- 3-5 sharpening questions asked and answered
- Assumptions listed and confirmed
- Success criteria are specific and testable
- "Not Doing" list has at least 2 items
goal-definition.mdsaved to artifact folder
Next
"Goal defined. Next recommended skill: brainstorming — explore approaches to achieve this goal."