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.md from the artifact folder (recommended but not required)
• See references/context-sources.md for additional project documentation that may provide context

Output

• goal-definition.md saved to the artifact folder (see references/formats.md for 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:

1. Who is this for? — The specific user and their situation
2. What does success look like? — Concrete, observable outcomes
3. What are the real constraints? — Time, tech, resources, compatibility
4. What's been tried before? — Prior attempts, why they failed or didn't happen
5. 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 users

Do 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.md saved to artifact folder

Next

"Goal defined. Next recommended skill: brainstorming — explore approaches to achieve this goal."