/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
Team is 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: 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 Statement

**Aim:** [One sentence: the behavior change you want]

**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]

### 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, mechanism, assumptions, feedback signal, guardrails — as the contract the rest of the workflow preserves.

Session Persistence

If session name provided (/aim auth-refactor): reads/writes .oh/auth-refactor.md directly. If no session name provided (/aim): offer to save with suggested name from git branch or aim content.

Reads: existing session file; prior skill outputs for context. Writes: aim statement (outcome, mechanism, assumptions, feedback signal, guardrails) as the contract later phases reuse:

## Aim
**Updated:** <timestamp>

[aim statement content]

If the section exists, replace it.

Position in Framework

Comes after: Nothing — aim is the entry point. Leads to: /problem-space to map the terrain, or /solution-space if the problem is already clear. Can loop back from: /salvage (restart with learning), /review (if aim has drifted).