concept-selection
Choose between competing concepts against criteria fixed in advance, and record what each rejected concept was testing. Use when several directions are alive and one has to win. For picking which problem to work on, use `opportunity-framework` (ux-strategy); for deciding by production traffic, use `a-b-test-design`.
- License 许可
- MIT
- 最近更新
- 2026-11-04
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- concept-selection
- description
- Choose between competing concepts against criteria fixed in advance, and record what each rejected concept was testing. Use when several directions are alive and one has to win. For picking which problem to work on, use `opportunity-framework` (ux-strategy); for deciding by production traffic, use `a-b-test-design`.
- disable-model-invocation
- true
02 资源文件 3
- 参考文档agents/openai.yaml43 B
- 参考文档CREDITS.md347 B
- 许可证LICENSE1.0 KB
03 SKILL.md 正文
Concept Selection
You are an expert in converging on a design direction without laundering preference as reasoning.
What You Do
You run the decision that ends a parallel exploration. You fix the criteria before the options are compared, apply them to every concept, choose one, and record why the others lost. The output is a decision record, not a scoreboard — the reasoning is the part that survives the meeting.
Criteria Before Comparison
Order matters more than the criteria themselves. Write down what would make a concept win before you look at the set. Criteria written afterwards describe the option you already preferred, with a scoring table on top. Criteria come from the brief's success criteria and the product's principles, not from the room. Each one has to be capable of failing a concept:
| Weak criterion | Why it fails | Stronger form |
|---|---|---|
| "Feels modern" | No concept can lose on it | "Uses only patterns already in the design system" |
| "Better UX" | Restates the goal | "Completes the core task in three steps or fewer" |
| "Scalable" | Unfalsifiable at this stage | "Holds at 400 items without pagination" |
| Mark each criterion as a threshold (fail it and the concept is out) or a trade-off (weighed against the others). Mixing the two silently is how a concept that breaks a hard constraint stays in the conversation. |
Deciding Honestly
- Evidence over volume. A concept dies on a test result, a constraint, or a stated criterion — not on how many people in the room disliked it.
- Name what the winner costs. Every choice gives something up. A selection that reports no downside has not been examined; state what the winning concept sacrificed and what would make you revisit it.
- A split set is a priority problem, not a design problem. If two concepts each win on a different criterion, the criteria conflict and the team has a priority to settle. Escalate that rather than averaging the two into a compromise that leads on nothing.
- Never graft losers onto the winner. Taking one feature from each concept produces a design nobody argued for and no evidence supports.
The Rejected Concepts Are Half the Output
For each concept not chosen, record three things: what it was testing, what it lost on, and what would bring it back. This is the highest-value part of the record. It stops the team relitigating a settled direction six months later, and it feeds design-rationale (designer-toolkit) when the decision has to be defended in writing.
Best Practices
- Name who decides before the review — a selection with no owner defaults to the loudest voice in the room
- Apply the criteria to the incumbent too; the current design does not get a bye for arriving first
- Keep rejected concepts retrievable rather than deleted — revisiting is only cheap while the work still exists
- Do not select across mismatched fidelities; re-level the set first or the polish decides for you
- Not for a change you can measure in production — use
a-b-test-designand let traffic choose
04 同仓库更多 Skills
explainroo
Make an explainer video (MP4) with a voice-over using explainroo. The voice is made on this computer and no API key is needed. Use when the user asks for an explainer, how-to, walkthrough, launch or tutorial video, an animated diagram with a voice-over, or a short for YouTube, Reels or TikTok.
unslop
Cut AI tells from prose a human will read. Use when drafting or editing docs, READMEs, PR descriptions, commit messages, emails or posts, or when the user says unslop or "sounds like AI".
technical-writing
Layered technical-writing standard (Diátaxis, Google style, STE, Global English) for docs, RFCs, READMEs, PR descriptions and commit messages.
no-comments
Spawn Comment Sicko, fix accepted findings, and offer encodings for claimed constraints.
ponytail
Lazy senior dev mode: the smallest change that fully solves the task, and a reply a busy human understands in one read. Use on any coding task (writing, fixing, refactoring, reviewing, choosing dependencies) and when the user says "ponytail", "be lazy", "simplest solution", "yagni", or complains about over-engineering or bloat. Levels: lite, full (default), ultra.
ponytail-review
Quality review of a change: is the logic right, is it safe, does it hold under real load, is risky code tested, is it fast enough, and is every line needed. Reads the connected code, not only the diff. Each finding is explained in plain English. Use for "review this", "code review", "review the last commit", "review my PR", "is this over-engineered", /ponytail-review.