Back to Details

aim

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/aim

/aim

Clarify the outcome you want. An aim is a change in user behavior, not a feature shipped. This is the first step in the Intent-Execution-Review loop.
The aim IS the abstraction. When you clarify what behavior you want to change, you're abstracting the business domain itself. Features are just the mechanism; the aim is why they matter.
明确你想要达成的目标。目标指的是用户行为的改变，而非功能的交付。这是“意图-执行-复盘”循环的第一步。
目标是一种抽象概念。当你明确想要改变的用户行为时，你其实是在对业务领域本身进行抽象。功能只是实现手段；目标才是功能的意义所在。

When to Use

适用场景

Invoke 
/aim
when:
  • Starting new work - Before diving into problem-statement or problem-space
  • Scope feels fuzzy - You can describe what you're building but not why
  • Multiple solutions seem valid - Aim clarifies which one actually moves the needle
  • Work has drifted - Return to aim to check if you're still on track
  • Team is misaligned - Shared aim surfaces hidden assumptions
Do not use when: You already have a crisp aim and need to explore the problem space or solution space. Move to 
/problem-statement
or 
/problem-space
instead.
在以下场景中调用
/aim
：
  • 启动新工作时 - 在深入问题陈述或问题领域之前
  • 范围模糊时 - 你能描述要构建的内容，但说不清原因
  • 存在多种可行方案时 - 目标能明确哪种方案真正能产生实际效果
  • 工作偏离方向时 - 回到目标，检查是否仍在正轨上
  • 团队意见不一致时 - 共同的目标能暴露隐藏的假设
不适用场景：你已经有清晰的目标，需要探索问题领域或解决方案领域时。此时应转向
/problem-statement
或
/problem-space
。

The Aim Process

目标设定流程

Step 1: State the Desired Behavior Change

步骤1：陈述期望的行为改变

Start with the user, not the system. What do you want users to do differently after this work ships?
"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.
从用户而非系统出发。在完成这项工作后，你希望用户有哪些不同的行为？
“用户将[具体行为]，而非[当前行为]。”
反面示例：“添加深色模式切换按钮” 正面示例：“用户可以在夜间舒适工作，不会感到眼睛疲劳”
反面示例：“改进引导流程” 正面示例：“新用户能在5分钟内体验到产品的核心价值”
关键区别：功能是产出物，行为改变是成果。

Step 2: Identify the Mechanism

步骤2：确定实现机制

The mechanism is your hypothesis - the causal lever you believe will produce the behavior change. It's the "because" that connects your work to the outcome.
"This will happen because [mechanism]."
Format:
Mechanism: [What you're changing]
Hypothesis: [Why you believe it will produce the outcome]
Assumptions: [What must be true for this to work]
机制是你的假设——你认为能引发行为改变的因果杠杆。它是连接你的工作与成果的“原因”。
“这将实现，因为[机制]。”
格式：
Mechanism: [你要改变的内容]
Hypothesis: [你认为它能产生成果的原因]
Assumptions: [要让这一机制生效必须成立的前提]

Step 3: Define the Feedback Signal

步骤3：定义反馈信号

How will you know if the aim is achieved? What signal validates or disproves the mechanism?
"We'll know it's working when [observable signal]."
Good feedback signals are:
  • Observable - You can actually measure or see them
  • Timely - You'll know within a reasonable timeframe
  • Attributable - The signal connects to your mechanism, not noise
你如何知道目标是否达成？什么信号能验证或推翻你的机制假设？
“当[可观察的信号]出现时，我们就知道目标正在实现。”
好的反馈信号具备以下特点：
  • 可观察 - 你能够实际测量或观察到
  • 及时性 - 你能在合理时间内得到结果
  • 可归因 - 信号与你的机制相关，而非无关干扰

Step 4: Set Guardrails

步骤4：设定约束条件

What constraints should bound this work? What would cause you to stop or change direction?
Format:
Guardrail: [boundary]
Reason: [why this matters]
Trigger: [when to revisit this constraint]
这项工作应受到哪些约束？什么情况会导致你停止或改变方向？
格式：
Guardrail: [约束边界]
Reason: [该约束的重要性]
Trigger: [重新审视该约束的时机]

Output Format

输出格式

Always produce an aim statement in this structure:
undefined
始终按照以下结构生成目标陈述：
undefined

Aim Statement

Aim Statement

Aim: [One sentence: the behavior change you want]
Current State: [What users do now] Desired State: [What users will do after]
Aim: [一句话：你期望的行为改变]
Current State: [用户当前的行为] Desired State: [完成工作后用户的行为]

Mechanism

Mechanism

Change: [What you're building/changing] Hypothesis: [Why you believe this produces the outcome] Assumptions: [What must be true]
Change: [你要构建/改变的内容] Hypothesis: [你认为这能产生成果的原因] Assumptions: [必须成立的前提]

Feedback

Feedback

Signal: [How you'll know it's working] Timeframe: [When you'll have signal]
Signal: [你如何判断目标正在实现] Timeframe: [你何时能得到反馈信号]

Guardrails

Guardrails

  • [Guardrail 1]
  • [Guardrail 2]
undefined
  • [约束条件1]
  • [约束条件2]
undefined

Examples

示例

Example 1: Feature Request to Aim

示例1：从功能需求到目标

Input:
/aim

We need to add a dark mode toggle to the settings page.
Output:
undefined
输入：
/aim

我们需要在设置页面添加深色模式切换按钮。
输出：
undefined

Aim Statement

Aim Statement

Aim: Users can work comfortably during extended evening sessions without eye strain.
Current State: Users either strain their eyes or stop using the app after dark. Desired State: Users work as long as they need, regardless of ambient lighting.
Aim: 用户可以在长时间的夜间工作中舒适操作，不会感到眼睛疲劳。
Current State: 用户要么在暗光下用眼疲劳，要么在天黑后停止使用应用。 Desired State: 用户可以根据环境光线随时工作，不受时间限制。

Mechanism

Mechanism

Change: Theme system with dark variant, exposed via settings toggle Hypothesis: Reducing screen brightness and contrast in low-light environments reduces eye strain, increasing comfortable usage time. Assumptions:
  • Users actually work in low-light conditions (validate with usage time data)
  • Eye strain is the blocker, not just preference (could survey)
  • A toggle is discoverable enough (vs. auto-detect)
Change: 支持深色主题的主题系统，通过设置页面的切换按钮暴露给用户 Hypothesis: 在低光环境下降低屏幕亮度和对比度能减少眼睛疲劳，从而延长舒适使用时间。 Assumptions:
  • 用户确实有在低光环境下工作的需求（可通过使用时间数据验证）
  • 眼睛疲劳是用户停止使用的主要障碍，而非单纯的偏好问题（可通过调研确认）
  • 切换按钮的可发现性足够（与自动检测模式对比）

Feedback

Feedback

Signal: Session duration in evening hours (6pm-midnight) increases Timeframe: 2 weeks post-launch to see pattern
Signal: 晚间时段（18:00-24:00）的会话时长增加 Timeframe: 上线后2周观察模式

Guardrails

Guardrails

  • Don't break existing light theme (test both paths)
  • Don't over-engineer: one dark theme, not a theme builder
  • Revisit if <5% of users actually enable it after 30 days
undefined
  • 不要破坏现有的浅色主题（需测试两种主题路径）
  • 不要过度设计：仅提供一种深色主题，不构建主题编辑器
  • 如果30天后启用深色模式的用户占比<5%，则重新审视该功能
undefined

Example 2: Vague Strategic Goal to Aim

示例2：从模糊战略目标到明确目标

Input:
/aim

We need to improve developer experience.
Output:
undefined
输入：
/aim

我们需要提升开发者体验。
输出：
undefined

Aim Statement

Aim Statement

Aim: Developers spend less than 10 minutes from git clone to running their first successful test.
Current State: New developers report 45-90 minutes to get a working dev environment. Some give up. Desired State: Developers are productive within their first coffee break.
Aim: 开发者从
git clone
到运行首次成功测试的时间不超过10分钟。
Current State: 新开发者反馈搭建可工作的开发环境需要45-90分钟，部分开发者因此放弃。 Desired State: 开发者在首次休息前就能投入工作。

Mechanism

Mechanism

Change: Containerized dev environment with pre-configured dependencies Hypothesis: Most setup time is spent on environment configuration, not understanding code. A working container removes the configuration variable. Assumptions:
  • Docker is acceptable for dev workflow (some devs resist containers)
  • Environment issues are the primary friction (not docs, not code complexity)
  • Container startup time is acceptable (<2 min)
Change: 包含预配置依赖项的容器化开发环境 Hypothesis: 大部分设置时间花费在环境配置上，而非理解代码。可直接使用的容器消除了配置变量的问题。 Assumptions:
  • Docker在开发工作流中是可接受的（部分开发者抵触容器）
  • 环境问题是主要的摩擦点（而非文档或代码复杂度）
  • 容器启动时间在可接受范围内（<2分钟）

Feedback

Feedback

Signal: Time from clone to first passing test (measured in onboarding script) Timeframe: Immediate per-developer, aggregate after 5 new devs
Signal: 从克隆到首次测试通过的时间（通过引导脚本测量） Timeframe: 每位开发者可立即得到数据，收集5位新开发者的数据后进行汇总分析

Guardrails

Guardrails

  • Container must work on Mac, Linux, and Windows (WSL2)
  • Don't require Docker for those who prefer native setup
  • Revisit if container approach creates new friction (debugging, IDE integration)
undefined
  • 容器必须支持Mac、Linux和Windows（WSL2）系统
  • 不强制要求使用Docker，为偏好原生设置的开发者保留选项
  • 如果容器方案带来新的摩擦（如调试、IDE集成问题），则重新审视
undefined

Example 3: Checking Aim Mid-Work

示例3：工作中途检查目标

Input:
/aim

I'm three days into this auth refactor and not sure if I'm still solving the right problem.
Output:
undefined
输入：
/aim

我已经进行了三天的认证重构工作，但不确定是否仍在解决正确的问题。
输出：
undefined

Aim Check

Aim Check

Original aim (inferred): Simplify the authentication flow for easier maintenance.
Let me ask clarifying questions to validate:
  1. What behavior change were you targeting?
    • Faster feature development in auth-adjacent code?
    • Fewer auth-related bugs in production?
    • Easier onboarding for new devs to the auth system?
  2. What's the current state?
    • How long does an auth change take today?
    • What breaks most often?
    • What do devs complain about?
  3. What signal will tell you this worked?
    • PR cycle time for auth changes?
    • Bug count in auth module?
    • Onboarding feedback?
Without clear answers, consider 
/salvage
to extract what you've learned, then restart with a crisp aim.
Red flag: If "simplify" is the aim, you need a measurable definition. Simplicity is a mechanism, not an outcome. What does simpler auth enable that complex auth blocks?
undefined
Original aim (inferred): 简化认证流程，便于维护。
让我提出一些澄清问题以验证：
  1. 你针对的是哪种行为改变？
    • 加快认证相关代码的功能开发速度？
    • 减少生产环境中与认证相关的bug？
    • 让新开发者更容易上手认证系统？
  2. 当前状态是怎样的？
    • 现在进行一次认证变更需要多长时间？
    • 最常出现问题的部分是什么？
    • 开发者们抱怨的点是什么？
  3. 什么信号能告诉你这项工作成功了？
    • 认证相关变更的PR周期时间？
    • 认证模块的bug数量？
    • 新开发者的上手反馈？
如果没有明确答案，建议使用
/salvage
提取已学到的经验，然后重新设定清晰的目标。
警示信号：如果“简化”是你的目标，你需要一个可衡量的定义。简洁性是一种机制，而非成果。简化的认证能实现什么复杂认证无法做到的事情？
undefined

Session Persistence

会话持久化

This skill can persist context to 
.oh/<session>.md
for use by subsequent skills.
If session name provided (
/aim auth-refactor
):
  • Reads/writes 
    .oh/auth-refactor.md
    directly
If no session name provided (
/aim
):
  • After producing the aim statement, offer to save it:
    "Save to session? [suggested-name] [custom] [skip]"
  • Suggest a name based on git branch (e.g., 
    feature/auth-flow
    → 
    auth-flow
    ) or the aim content
  • If user accepts, create 
    .oh/<session>.md
Reading: Check for existing session file. If found, read prior skill outputs (problem-statement, problem-space, etc.) for context.
Writing: After producing output, write the aim statement to the session file:
markdown
undefined
该技能可将上下文持久化到
.oh/<session>.md
，供后续技能使用。
若提供了会话名称（如
/aim auth-refactor
）：
  • 直接读写
    .oh/auth-refactor.md
若未提供会话名称（如
/aim
）：
  • 生成目标陈述后，会询问是否保存：
    “Save to session? [suggested-name] [custom] [skip]”
  • 根据git分支（如
    feature/auth-flow
    → 
    auth-flow
    ）或目标内容建议一个名称
  • 如果用户同意，创建
    .oh/<session>.md
读取：检查是否存在会话文件。如果找到，读取之前的技能输出（如problem-statement、problem-space等）以获取上下文。
写入：生成输出后，将目标陈述写入会话文件：
markdown
undefined

Session: <session>

Session: <session>

Aim

Aim

Updated: <timestamp>
[aim statement content]

If the section exists, replace it. If not, create it.
Updated: <timestamp>
[aim statement content]

如果该部分已存在，则替换；如果不存在，则创建。

Adaptive Enhancement

自适应增强

Base Skill (prompt only)

基础技能（仅提示）

Works anywhere. Produces aim statement for discussion. No persistence.
可在任何场景使用。生成用于讨论的目标陈述，无持久化功能。

With .oh/ session file

配合.oh/会话文件使用

  • Reads 
    .oh/<session>.md
    for prior context from other skills
  • Writes aim statement to the session file
  • Subsequent skills (
    /problem-statement
    , 
    /solution-space
    , etc.) can read the aim
  • 读取
    .oh/<session>.md
    获取其他技能的历史上下文
  • 将目标陈述写入会话文件
  • 后续技能（如
    /problem-statement
    、
    /solution-space
    等）可读取该目标

With Open Horizons MCP

配合Open Horizons MCP使用

  • Queries related endeavors to see if aim already exists
  • Pulls relevant tribal knowledge that might inform mechanism choice
  • Logs aim statement to graph database
  • Links aim to active endeavors
  • Session file serves as local cache for MCP data
  • 查询相关项目，查看目标是否已存在
  • 获取相关的团队经验，为机制选择提供参考
  • 将目标陈述记录到图形数据库
  • 将目标与活跃项目关联
  • 会话文件作为MCP数据的本地缓存

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).
之前的步骤：无——目标是入口点。 后续的步骤：
/problem-space
用于梳理领域和约束，若问题已明确则转向
/solution-space
。 可从以下步骤返回：
/salvage
（基于所学重新开始）、
/review
（若目标已偏离）。

Leads To

后续流程

After establishing aim, typically:
  • /problem-space
    - Map the terrain and constraints
  • /problem-space
    - Map constraints and what you're optimizing
  • /review
    - Check if current work still serves the aim
Remember: The aim IS the abstraction. Features are outputs; behavior changes are outcomes. Start with what you want users to do differently.
确定目标后，通常可进行：
  • /problem-space
    - 梳理领域和约束
  • /problem-space
    - 梳理约束和优化方向
  • /review
    - 检查当前工作是否仍符合目标
记住：目标是一种抽象概念。功能是产出物，行为改变是成果。从你期望用户做出的行为改变开始。