사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/owl-listener/designer-skills --skill concept-selection시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
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
