Hai Idea

Hai Idea

For Chinese readers, see SKILL.zh_CN.md. The English SKILL.md is the execution source of truth.

Overview

Return one clear verdict per idea, never a survey of considerations. When the user hands you two or more ideas, rank them by decision value, not novelty.

Core Principle

Make bold judgments, then verify carefully.

Give a clear call, but attach the call to evidence. Do not hide behind "it depends" when the audience is vague, the pain is weak, the cost is high, timing is wrong, or no proof path exists.

Evaluation Frame

Evaluate only the dimensions that affect the decision:

• Pain: what real problem does it solve? Is the pain frequent, urgent, expensive, or emotionally sharp?
• Audience: who specifically benefits? Is the user, buyer, reviewer, maintainer, or operator clear?
• Current workaround: what do people do today? If the workaround is cheap and good enough, the idea is weaker.
• Leverage: does it create repeated value, reduce future cost, improve decisions, or compound across workflows?
• Timing: is now the right moment, or is the idea blocked by infrastructure, demand, trust, data, distribution, or attention?
• Differentiation: why is this not a generic clone, tiny convenience, or local preference?
• Feasibility: can it be done with available tools, skills, time, permissions, and dependencies?
• Cost: what does it consume: time, focus, architecture complexity, coordination, maintenance, reputation, or money?
• Risk: how could it fail, mislead, regress, create lock-in, or make later work harder?
• Proof path: what evidence would make the idea clearly stronger or weaker?

Workflow

1. Restate the idea in one sentence. Remove decoration and excitement, name the target user or affected system, and state the expected outcome.

2. Identify the decision. Is the current decision to do, validate, prioritize, reframe, or kill? If comparing ideas, rank by decision value rather than novelty.

3. Evaluate the decisive dimensions from the Evaluation Frame above. Penalize vague users, fake urgency, high maintenance cost, missing evidence, and high opportunity cost. Reward sharp pain, repeated use, cheap validation, high leverage, and clear exit criteria.

4. Make the call. Pick exactly one verdict from the Verdict Guide below, explain the reason directly, and state your confidence (high / medium / low). If the idea has potential but is not executable yet, state what must become true first.

5. State the strongest objection. Name the single best reason not to do this now, even if your verdict is Do — a call you cannot argue against yourself is not yet verified.

6. Offer a stronger version. If the current idea is weak or only partly right, give the strongest nearby reframe. Skip only when the idea is already at its best form.

7. Define the smallest useful validation. What is the cheapest test that could change the decision? What signal would prove demand, feasibility, quality, or strategic value, and what result would show the idea is not worth continuing? Bound it with a timebox when one applies.

Read references/output-template.md — it is the canonical output shape — before finalizing.

Verdict Guide

The verdict is exactly one of these five calls:

• Do: clear audience, real pain, good timing, manageable cost, and enough evidence to proceed.
• Validate first: plausible upside, but a key assumption is unproven.
• Reframe: the current idea is weak, but a stronger nearby direction exists.
• Defer: potentially good, but timing, dependencies, or opportunity cost are wrong now.
• Kill: weak pain, unclear audience, low leverage, high cost, or no credible proof path.

Common Mistakes

• Treating an interesting idea as a good idea.
• Confusing "I can build it" with "it is worth doing".
• Accepting vague audiences like "everyone", "developers", or "teams" without a concrete scenario.
• Designing the full solution before deciding whether the idea deserves one.

Use a different skill when

• The decision to build is already made and the user wants phases, todos, or an execution plan: use hai-goal.
• The idea is solid and now needs product requirements: use hai-prd.
• The user wants to challenge scope or ambition without a do/kill verdict — open the frame and think bigger: use geju.
• The problem is purely choosing or fixing a name: use hai-naming.

Hai Idea 输出模板

用于判断一个想法值得做、先验证、重塑、延后还是砍掉。

# Hai Idea: <idea name>

## Verdict
- **结论**: 做 / 先验证 / 重塑 / 延后 / 砍掉
- **置信度**: 高 / 中 / 低
- **一句话理由**: <直接判断，不要温吞>

## 想法重述
<去掉修饰后，用一句话说清这个想法。>

## 决策上下文
- **当前要决定**: <做 / 验证 / 排序 / 重塑 / 砍掉>
- **目标对象**: <具体用户、买方、维护者、运营者、工作流或系统>
- **预期结果**: <这个想法希望改善什么>

## 评分表
| 维度 | 评级 | 理由 |
|------|------|------|
| 痛点 | 强 / 中 / 弱 / 未知 | <证据或问题> |
| 对象清晰度 | 强 / 中 / 弱 / 未知 | <谁受益> |
| 现状替代方案 | 痛苦 / 可忍 / 容易 / 未知 | <现在怎么解决> |
| 杠杆 | 高 / 中 / 低 / 未知 | <价值是否会复利> |
| 时机 | 合适 / 太早 / 太晚 / 被卡住 / 未知 | <时机判断> |
| 差异性 | 清楚 / 单薄 / 没有 / 未知 | <为什么不是普通想法> |
| 可行性 | 容易 / 可控 / 困难 / 被卡住 / 未知 | <执行现实> |
| 成本 | 低 / 中 / 高 / 未知 | <时间、注意力、维护、复杂度> |
| 风险 | 低 / 中 / 高 / 未知 | <可能出什么问题> |
| 证明路径 | 清楚 / 部分清楚 / 弱 / 没有 | <怎么验证> |

## 最强反对意见
<反对现在做这个想法的最强理由。>

## 更强版本
<如果当前想法不够好，给出更强的重塑版本。>

## 最小有效验证
- **测试**: <最低成本实验、原型、访谈、指标检查、文档草稿或技术 spike>
- **通过信号**: <什么结果会让想法变强>
- **失败信号**: <什么结果说明不值得继续>
- **时间盒**: <可选的时间或投入上限>

## 下一步
<具体下一步：写 goal、写 PRD、做验证、比较备选、延后或砍掉。>

Hai Idea 中文版

本文件是中文阅读版；执行规则以 SKILL.md 为准。

概览

每个想法只给一个明确结论，而不是罗列利弊。当用户一次抛来两个或更多想法时，按决策价值排序，而不是按新鲜度。

核心原则

大胆判断，小心求证。

要给明确结论，但结论必须绑定证据。不要躲在“有利有弊”里面。如果想法的用户不清、痛点不硬、成本过高、时机不对、没有验证路径，就直接说。

判断维度

只评价真正影响决策的维度：

• 痛点：解决什么真实问题？是否高频、紧急、昂贵，或情绪上尖锐？
• 对象：谁具体受益？用户、买方、评审、维护者还是运营者是否清楚？
• 现状替代方案：现在怎么解决？如果替代方案便宜又够用，这个想法就更弱。
• 杠杆：是否能复用、复利、降低未来成本、改善决策、跨工作流叠加？
• 时机：现在是否合适？是否被基础设施、需求、信任、数据、分发或注意力卡住？
• 差异性：为什么不是普通复制品、微小便利或局部偏好？
• 可行性：用现有工具、能力、时间、权限和依赖能否做成？
• 成本：消耗时间、注意力、架构复杂度、协调、维护、声誉还是金钱？
• 风险：可能如何失败、误导、回退、造成锁定，或让后续更难？
• 证明路径：什么证据会让想法明显变强或变弱？

工作流

1. 用一句话重述想法。去掉修饰和兴奋，点名目标用户或受影响的系统，说清预期结果。

2. 明确当前决策。当前要决定的是做、验证、排序、重塑还是砍掉？如果是比较多个想法，按决策价值排序而非新鲜度。

3. 评价决定性维度（用上面的判断维度）。对模糊用户、假紧急、高维护成本、缺证据、高机会成本扣分；对尖锐痛点、重复使用、廉价验证、高杠杆、清晰退出标准加分。

4. 给出结论。从下面的结论指南里挑唯一一个结论，直接说明理由，并标注置信度（高 / 中 / 低）。如果想法有潜力但还不可执行，说清需要先变成什么样。

5. 写出最强反对意见。即使结论是“做”，也要点名现在不该做的那个最强理由——一个你自己都驳不倒的判断，还没经过验证。

6. 给出更强版本。如果当前想法偏弱或只对了一半，给出最强的就近重塑版本。只有当想法已经是最佳形态时才跳过。

7. 定义最小有效验证。能改变决策、成本最低的测试是什么？什么信号能证明需求、可行性、质量或战略价值，什么结果说明不值得继续？必要时用时间盒框住它。

落稿前阅读 references/output-template.md——它是输出形态的唯一权威。

结论指南

结论是且仅是这五个之一：

• 做：对象清晰、痛点真实、时机合适、成本可控，且证据足以推进。
• 先验证：上行空间合理，但有一个关键假设尚未证实。
• 重塑：当前想法偏弱，但旁边存在一个更强的方向。
• 延后：可能不错，但现在时机、依赖或机会成本不对。
• 砍掉：痛点弱、对象不清、杠杆低、成本高，或没有可信的证明路径。

常见错误

• 把“有意思的想法”当成“好想法”。
• 把“我能做”和“值得做”混为一谈。
• 接受“所有人”“开发者”“团队”这类模糊对象，却没有具体场景。
• 还没决定想法是否值得，就先把完整方案设计出来。

何时改用其他 skill

• 是否要做已经定了，用户想要阶段、todo 或执行计划：用 hai-goal。
• 想法已经成立，现在需要产品需求：用 hai-prd。
• 用户想挑战范围或野心，不要 做/砍 的结论——打开格局、往大处想：用 geju。
• 问题纯粹是取名或改名：用 hai-naming。