메뉴
Reduce decision time by managing choice count and choice structure with Hick's Law. Use when designing menus, navigation, plans, filters, onboarding paths, settings, or feature sets with too many options; avoid for complex-task load, staged disclosure, or CTA visibility issues.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | hicks-law |
| description | Reduce decision time by managing choice count and choice structure with Hick's Law. Use when designing menus, navigation, plans, filters, onboarding paths, settings, or feature sets with too many options; avoid for complex-task load, staged disclosure, or CTA visibility issues. |
More choices slow decisions. Reduce, group, default, or reveal later.
## Hick's Law Analysis
Interface or flow: [name]
## Decision Points
- [location]: [current options] -> [target options]
## Problems
- [choice overload or complexity]
## Reduction Plan
- [remove/group/default/filter/reveal]
## Expected Impact
- Decision speed: [estimate]
- Risk: [tradeoff]
Analyze a list of open questions and suggest up to three answers for each. Use when the user wants options, recommendations, or help resolving multiple unanswered questions.
Deliver a PRD through orchestrated task decomposition, implementation agents, and independent QA. Use when every acceptance criterion must be verified before completion.
Explain changes made yesterday as a simple list. Use when user asks what changed yesterday, what was implemented yesterday, or needs a non-technical change summary from recent git work.
Pressure-test, reduce, and rewrite prompts for GPT-5.5. Use when the user asks to grill, audit, critique, harden, improve, optimize, simplify, de-noise, or rewrite a prompt, system prompt, developer instruction, agent playbook, or tool-use workflow specifically for GPT-5.5; especially when it may contain no-op instructions, contradictions, vague rules, missing success criteria, missing output rules, missing validation, unsupported claims, or unclear stop rules.
Build shared understanding before action by interviewing the user about ambiguous implementation, product, planning, or design tasks. Use when goal, scope, constraints, risks, success criteria, done state, or next action are unclear; when user wants a thinking partner; or when user needs a handoff-ready task prompt. Do not write PRDs; use to-prd for product requirements.
Detect sloppy-code signals with repo-wide search metrics and sampled evidence. Use when asked to audit codebase quality, "vibe coding", `isRecord`, broad `Record<string, unknown>` guards, fallback usage, excessive null guards, non-null assertions, unsafe type assertions, `node:*` imports in browser/shared code, swallowed errors, TODO debt, or code smell hotspots before refactoring.