hai-idea

name

hai-idea

description

Evaluates whether an idea, feature, product, or project deserves attention and returns one verdict—Do, Validate first, Reframe, Defer, or Kill—plus the strongest objection and cheapest decision-changing test. Use when the user asks whether something is worth doing, is a fake need or distraction, should be built/killed/postponed, or which idea to prioritize（值不值得做、是不是伪需求、要不要砍）. Use hai-goal after the decision to proceed is made.

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?

Use qualitative ratings to expose uncertainty; do not average them into a pseudo-precise numeric score. One decisive blocker or proof can outweigh several mild positives.

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.