| name | aim |
| description | Clarify the outcome you want - a change in user behavior, not a feature shipped. Use at the start of any work to ground the session in strategic intent. |
/aim
Clarify the outcome you want. An aim is a change in user behavior, not a feature shipped. First step in Intent-Execution-Review.
The aim IS the abstraction. Clarifying what behavior to change abstracts the business domain itself. Features are mechanism; the aim is why they matter.
When to Use
- Starting new work — before problem-statement or problem-space
- Scope feels fuzzy — you can describe what but not why
- Multiple solutions seem valid — aim reveals which moves the needle
- Work has drifted — check alignment
- Stakeholders are misaligned — surfaces hidden assumptions
Skip when: You already have a crisp aim. Move to /problem-statement or /problem-space.
The Aim Process
Step 1: State the Desired Behavior Change
Start with the user, not the system.
"Users will [specific behavior] instead of [current behavior]."
Bad: "Add dark mode toggle"
Good: "Users can work comfortably at night without eye strain"
Bad: "Improve onboarding flow"
Good: "New users reach their first value moment within 5 minutes"
Key distinction: Features are outputs. Behavior changes are outcomes. If users don't become more capable, shipping more output doesn't rescue the work.
Step 2: Identify the Mechanism
The mechanism is your hypothesis — the causal lever you believe produces the behavior change.
Mechanism: [What you're changing]
Hypothesis: [Why you believe it will produce the outcome]
Assumptions: [What must be true for this to work]
If you listed zero assumptions, that is a red flag, not a clean bill of health. Every mechanism rests on premises. Name at least one or explain why none exist.
Watch for abstract qualities (simplicity, speed, clarity) posing as aims — these are mechanisms, not outcomes. Ask what they enable that their absence blocks.
Step 3: Define the Feedback Signal
How will you know if the aim is achieved?
"We'll know it's working when [observable signal]."
Signals must be observable, timely, and attributable to your mechanism.
Step 4: Check Shared Intent
Before guardrails, protect the aim from premature mechanism:
- Can each stakeholder restate the same behavior change and why it matters?
- Is the mechanism still a hypothesis, not the aim itself?
- What evidence would show the aim was misunderstood?
Step 5: Set Guardrails
What constraints bound this work? What would cause you to stop?
Guardrail: [boundary]
Reason: [why this matters]
Trigger: [when to revisit]
Output Format
## Aim
**Aim:** [One sentence: the behavior change you want]
**Why it matters:** [User or business consequence if this behavior does not change]
**Current State:** [What users do now]
**Desired State:** [What users will do after]
### Mechanism
**Change:** [What you're building/changing]
**Hypothesis:** [Why you believe this produces the outcome]
**Assumptions:** [What must be true]
**Misunderstanding Signal:** [What you'd see if people understood the feature but missed the aim]
### Feedback
**Signal:** [How you'll know it's working]
**Timeframe:** [When you'll have signal]
### Guardrails
- [Guardrail 1]
- [Guardrail 2]
Later phases carry forward the aim's explicit fields — outcome, why it matters, mechanism as hypothesis, assumptions, feedback signal, guardrails, and misunderstanding signal — as the contract the rest of the workflow preserves.
Session Handoff
If a session file is in use, replace or append ## Aim. Later phases read this section as the canonical aim contract.
