一键在 Manus 中运行任何 Skill

brainstorm-prototypes

星标212

分支17

更新时间2026年7月5日 05:51

Generate several genuinely different throwaway variations (designs, approaches, drafts) for the user to react to. Use when the user can only recognize what they want by seeing it — visual design, UX flows, naming, tone — or asks to brainstorm or prototype before building.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

Neeeophytee

Neeeophytee/finding-unknowns-skills

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Brainstorm and prototypes

The user has unknown knowns: criteria they can't verbalize but will recognize on sight. Finding those during prototyping is cheap; finding them mid-implementation is expensive, because small spec changes can mean drastically different code. Give them things to react to.

Steps

Establish scope first: what is being decided (layout? approach? data model? tone?) and what is explicitly out of scope. One decision per round.
Produce 3-5 variations that are wildly different, not shades of the same idea. If two variations would get the same reaction, replace one.
Make them cheap and disposable:
- Visual/UX → a single self-contained HTML file with fake data, no backend, no state.
- Approaches → a one-screen sketch of each: the idea, what it optimizes for, its sharpest tradeoff.
- Ranked lists → order from cheapest to most ambitious so the user can draw their line.
Label each variation with the belief it bets on ("this one assumes density beats whitespace"), so the user's reaction reveals the underlying criterion, not just a preference.
Collect reactions, then verbalize what was learned: "you consistently rejected X, which suggests the real requirement is Y." That sentence is the deliverable — it becomes part of the spec.

Guardrails

Nothing produced here is production code. Say so, and don't wire prototypes into the real app.
Do not converge early to the variation you'd pick. The point is spanning the space.
If the user reacts to none of them, that's signal too: the decision space was framed wrong. Reframe and rerun rather than generating more of the same.

同仓库更多 Skills

同仓库

change-quiz

Neeeophytee/finding-unknowns-skills

After a working session, produce a report on what changed plus a quiz the user must pass before merging. Use when the user asks "what did we actually do," wants to review a large change, or invokes a quiz before merge.

2026-07-05212

implementation-plan

Neeeophytee/finding-unknowns-skills

Write an implementation plan that leads with the decisions the user is most likely to change, and buries the mechanical work at the bottom. Use when planning is requested before a build, especially after brainstorming or an interview.

2026-07-05212

blindspot-pass

Neeeophytee/finding-unknowns-skills

Surface the user's unknown unknowns before work starts. Use when the user is entering an unfamiliar codebase area, an unfamiliar domain (design, video, infra), or explicitly asks for a "blindspot pass" or to find their "unknown unknowns."

2026-07-05212

implementation-notes

Neeeophytee/finding-unknowns-skills

Keep a running implementation-notes.md during a build, logging every deviation from the plan and every discovered edge case. Use whenever implementing against an agreed plan or spec, especially in long autonomous sessions.

2026-07-05212

interview-me

Neeeophytee/finding-unknowns-skills

Interview the user one question at a time to resolve remaining ambiguity before implementation. Use when planning or brainstorming is done but unknowns remain, or when the user asks to be interviewed about a task or spec.

2026-07-05212

pitch-packager

Neeeophytee/finding-unknowns-skills

Package a finished piece of work (spec, prototype, implementation notes) into a single document that gets reviewers to understanding and approval fast. Use when the user needs buy-in, a review, or a shareable summary of what was built and why.

2026-07-05212

name	brainstorm-prototypes
description	Generate several genuinely different throwaway variations (designs, approaches, drafts) for the user to react to. Use when the user can only recognize what they want by seeing it — visual design, UX flows, naming, tone — or asks to brainstorm or prototype before building.

Brainstorm and prototypes

Steps

Establish scope first: what is being decided (layout? approach? data model? tone?) and what is explicitly out of scope. One decision per round.
Produce 3-5 variations that are wildly different, not shades of the same idea. If two variations would get the same reaction, replace one.
Make them cheap and disposable:
- Visual/UX → a single self-contained HTML file with fake data, no backend, no state.
- Approaches → a one-screen sketch of each: the idea, what it optimizes for, its sharpest tradeoff.
- Ranked lists → order from cheapest to most ambitious so the user can draw their line.
Label each variation with the belief it bets on ("this one assumes density beats whitespace"), so the user's reaction reveals the underlying criterion, not just a preference.
Collect reactions, then verbalize what was learned: "you consistently rejected X, which suggests the real requirement is Y." That sentence is the deliverable — it becomes part of the spec.

Guardrails

Nothing produced here is production code. Say so, and don't wire prototypes into the real app.
Do not converge early to the variation you'd pick. The point is spanning the space.
If the user reacts to none of them, that's signal too: the decision space was framed wrong. Reframe and rerun rather than generating more of the same.