idea-discovery

Original：🇨🇳 Chinese

Translated

Use when fundamentally new ideas or design principles are requested, rather than extensions of existing ones. For example, when someone asks for "an idea unlike anything I've seen before" or "a design based on entirely different premises," or when the direct answer would merely be a variation on an existing proposal. Instead of listing and ranking candidates, put one idea into actual use and move forward through the questions it raises and the concrete outcomes it produces. Do not use for ordinary design judgments or for comparing options whose answers are determined by facts.

2installs

Sourcerebuildup/project-init

Added on2026-10-30

NPX Install

npx skill4agent add rebuildup/project-init idea-discovery

SKILL.md Content (Chinese)

View Translation Comparison →

Idea Discovery

A Skill for avoiding common failure modes when seeking ideas that are difficult to reach by extending existing concepts. It does not guarantee discovery. The approach described here is a hypothesis that has survived an extended inquiry, and its effectiveness has not yet been verified.

When Not to Use

Do not use this Skill and respond normally in the following situations.

A design decision for which choosing from existing options is sufficient (
```
engineering-decisions
```
)
Work organizing requirements before implementation (
```
design-refinement
```
)
A request to broadly enumerate possible options
Questions whose answers are determined by facts or experiments

Failure Modes to Avoid

Extracting a method from successful examples. Turning commonalities among successful inventions—questioning assumptions, removing functionality, redefining the problem, and so on—into a procedure produces only an after-the-fact explanation. We do not see the cases in which the same procedure failed. Being able to explain success and being able to reproduce it are different things.
Producing many candidates and ranking them by current criteria. The more fundamentally new an idea is, the less its value is likely to be visible under current evaluation criteria. Narrowing the options too early risks discarding it.
Coming to believe an idea through prolonged thought. Repeatedly reflecting on a single candidate can make even an unsupported one appear important. Hindsight justification can closely resemble discovery.
Expecting the method itself to produce results. Branching the thinking process, trying independently multiple times, and similar operations do not inherently generate discoveries. They are merely one condition determining what context is carried forward and what is not.

Approach

Make one concrete idea viable. There is no need to find the most promising answer. Establish only one idea, with enough specificity to put it into use.
Use it without judging it. Instead of determining whether the idea is correct or useful, actually apply and try it. Raise one question that emerges only through using it.
Create one outcome from that question. Produce one concrete outcome that would not have emerged by directly answering the original question. This could be a design proposal, prototype, comparable experiment, new formulation of the problem, or something similar.
If nothing emerges, say so. If no outcome is produced, answer the original question as it stands and state that nothing emerged. Do not force a meaning into it.

By default, run the process only once. Repeat it by using the resulting outcome as the next "one idea" only when the user asks to continue.

To try without carrying forward previous deliberation, you may pass only the original question to a fresh context subagent and have it follow the same approach. Do not assume that this will produce a better result.

Checking Whether It Is Discovery or Hindsight

After producing an outcome, check the following before returning it to the user.

Is it concrete and verifiable? Can it be built, run, compared, or disproven? If it is only a rephrasing or an abstract suggestion, it is not an outcome.
Does it differ from the direct answer? Briefly state what the direct answer would be before comparing it with the outcome. If the outcome is merely a rephrasing of the direct answer, say so.
Are you evaluating it according to the method's intent? Do not judge its quality by whether it followed the procedure and produced a question and an outcome. Following the procedure and being a valuable discovery are separate things.

How to Communicate the Result

Present the outcome as a hypothesis. Do not state definitively that it is a discovery. Briefly add the following three points:

What was done and what emerged
How it differs from the direct answer
What should be checked to determine whether it is correct or incorrect