aim
/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
More from open-horizon-labs/skills
dissent
Devil's advocate. Seek contrary evidence before locking in. Use when about to make a significant decision, when confidence is high but stakes are higher, or when the team is converging too quickly.
89review
Check work and detect drift before committing. A second opinion that catches misalignment early. Use at natural pause points, before PRs, or when something feels off.
82ship
Deliver code to users. Optimize the path from merged code to working install. Use when execution is complete and you need to get changes into users' hands.
82problem-space
Map what we're optimizing and what constraints we treat as real. Use before jumping to solutions, when hitting repeated blockers, or when patches keep accumulating.
80execute
Do the work. Pre-flight, build, detect drift, salvage if needed. Use when you have a clear aim and are ready to implement.
79problem-statement
Define the framing of a problem. Change the statement, change the solution space. Use when starting work, when solutions feel wrong, or when you suspect an X-Y problem.
78