重要前提
安装AI Skills的关键前提是:必须科学上网,且开启TUN模式,这一点至关重要,直接决定安装能否顺利完成,在此郑重提醒三遍:科学上网,科学上网,科学上网。查看完整安装教程 →
npx skills add https://github.com/open-horizon-labs/skills --skill aim明确你期望的结果。一个目标(aim)是用户行为的改变,而非交付的功能特性。这是“意图-执行-回顾”循环的第一步。
目标本身就是抽象。 当你明确想要改变何种行为时,你就是在对业务领域本身进行抽象。功能特性只是实现机制;而目标是它们之所以重要的原因。
在以下情况下调用 /aim:
不要使用的情况: 你已经有一个清晰的目标,需要探索问题空间或解决方案空间。此时应转向 /problem-statement 或 /problem-space。
从用户出发,而非系统。在这项工作完成后,你希望用户的行为有何不同?
"用户将 [特定行为] 而不是 [当前行为]。"
反面例子: "添加深色模式切换" 正面例子: "用户可以在夜间舒适工作,无需忍受眼睛疲劳"
"改进新用户引导流程" "新用户在 5 分钟内达到他们的第一个价值时刻"
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
关键区别: 功能特性是产出。行为改变是结果。
机制是你的假设——你相信能产生行为改变的因果杠杆。它是连接你的工作和结果的“因为”。
"这将发生是因为 [机制]。"
格式:
Mechanism: [你要改变什么]
Hypothesis: [你为什么相信这会产生结果]
Assumptions: [要使此机制生效,哪些条件必须为真]
你如何知道目标是否达成?什么信号能验证或否定该机制?
"当 [可观察的信号] 出现时,我们就知道它起作用了。"
好的反馈信号应具备:
哪些约束应限制这项工作?什么情况会导致你停止或改变方向?
格式:
Guardrail: [边界]
Reason: [为什么这很重要]
Trigger: [何时重新审视此约束]
始终按此结构生成目标陈述:
## Aim Statement
**Aim:** [一句话:你期望的行为改变]
**Current State:** [用户当前的行为]
**Desired State:** [用户之后将采取的行为]
### Mechanism
**Change:** [你正在构建/改变什么]
**Hypothesis:** [你为什么相信这会产生结果]
**Assumptions:** [哪些条件必须为真]
### Feedback
**Signal:** [你将如何知道它起作用了]
**Timeframe:** [你何时能获得信号]
### Guardrails
- [防护栏 1]
- [防护栏 2]
输入:
/aim
We need to add a dark mode toggle to the settings page.
输出:
## 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.
### 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)
### Feedback
**Signal:** Session duration in evening hours (6pm-midnight) increases
**Timeframe:** 2 weeks post-launch to see pattern
### 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
输入:
/aim
We need to improve developer experience.
输出:
## 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.
### 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)
### Feedback
**Signal:** Time from clone to first passing test (measured in onboarding script)
**Timeframe:** Immediate per-developer, aggregate after 5 new devs
### 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)
输入:
/aim
I'm three days into this auth refactor and not sure if I'm still solving the right problem.
输出:
## 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?
此技能可以将上下文持久化到 .oh/<session>.md 中,供后续技能使用。
如果提供了会话名称 (/aim auth-refactor):
.oh/auth-refactor.md如果未提供会话名称 (/aim):
"Save to session? [suggested-name] [custom] [skip]"
feature/auth-flow → auth-flow)或目标内容建议一个名称.oh/<session>.md读取: 检查是否存在现有的会话文件。如果找到,则读取先前技能的输出(问题陈述、问题空间等)以获取上下文。
写入: 生成输出后,将目标陈述写入会话文件:
# Session: <session>
## Aim
**Updated:** <timestamp>
[aim statement content]
如果该部分已存在,则替换它。如果不存在,则创建它。
随处可用。生成用于讨论的目标陈述。无持久化。
.oh/<session>.md 以获取先前上下文/problem-statement、/solution-space 等)可以读取该目标之前步骤: 无——目标是入口点。 导向步骤: /problem-space 以描绘地形,或者如果问题已清晰,则导向 /solution-space。 可循环返回自: /salvage(带着所学重新开始)、/review(如果目标已偏离)。
建立目标后,通常进行:
/problem-space - 描绘地形和约束/problem-space - 描绘约束和你正在优化的方面/review - 检查当前工作是否仍服务于目标记住: 目标本身就是抽象。功能特性是产出;行为改变是结果。从你希望用户做出何种不同行为开始。
每周安装次数
58
代码仓库
GitHub 星标数
1
首次出现
Jan 27, 2026
安全审计
安装于
claude-code44
opencode28
gemini-cli18
codex17
github-copilot14
cursor14
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.
Invoke /aim when:
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.
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.
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]
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:
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]
Always produce an aim statement in this structure:
## 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]
Input:
/aim
We need to add a dark mode toggle to the settings page.
Output:
## 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.
### 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)
### Feedback
**Signal:** Session duration in evening hours (6pm-midnight) increases
**Timeframe:** 2 weeks post-launch to see pattern
### 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
Input:
/aim
We need to improve developer experience.
Output:
## 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.
### 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)
### Feedback
**Signal:** Time from clone to first passing test (measured in onboarding script)
**Timeframe:** Immediate per-developer, aggregate after 5 new devs
### 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)
Input:
/aim
I'm three days into this auth refactor and not sure if I'm still solving the right problem.
Output:
## 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?
This skill can persist context to .oh/<session>.md for use by subsequent skills.
If session name provided (/aim auth-refactor):
.oh/auth-refactor.md directlyIf no session name provided (/aim):
"Save to session? [suggested-name] [custom] [skip]"
feature/auth-flow → auth-flow) or the aim content.oh/<session>.mdReading: 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:
# Session: <session>
## Aim
**Updated:** <timestamp>
[aim statement content]
If the section exists, replace it. If not, create it.
Works anywhere. Produces aim statement for discussion. No persistence.
.oh/<session>.md for prior context from other skills/problem-statement, /solution-space, etc.) can read the aimComes 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).
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 aimRemember: The aim IS the abstraction. Features are outputs; behavior changes are outcomes. Start with what you want users to do differently.
Weekly Installs
58
Repository
GitHub Stars
1
First Seen
Jan 27, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
claude-code44
opencode28
gemini-cli18
codex17
github-copilot14
cursor14
任务估算指南:敏捷开发故事点、计划扑克、T恤尺码法详解
10,500 周安装