principle-price-each-option
WHEN asking the user to choose, approve or rule between courses of action; NOT for comparing designs you will decide yourself or reporting a settled result; states each option with what it does and what it costs.
- License 许可
- MIT
- 所属仓库
- mintuz/skills
- 最近更新
- 2026-11-11
- Stars
- ★ 35
- Forks
- 7
01 前言 Front Matter
- name
- principle-price-each-option
- description
- WHEN asking the user to choose, approve or rule between courses of action; NOT for comparing designs you will decide yourself or reporting a settled result; states each option with what it does and what it costs.
03 SKILL.md 正文
Price each option
The user can choose well only when every option shows its effect and its price side by side.
- State the decision in one sentence, then the options. Put no background or findings summary before them.
- Give each option a reply label, such as
Aor1, and one plain sentence, not a table cell, saying what it does and what it costs: money, time, downtime, risk, lost data or scope, or what cannot be undone. State the cost as its consequence for the user, not the mechanism behind it: "existing users' saved links break", not "drops the redirect table". - Price every option the same way, including the one you prefer and any work you have already done. An approval request is a choice too: price the action you propose and the alternative it displaces.
- Omit figures and detail the choice does not need. Label a recommendation as a recommendation; it does not replace its cost.
Distinct from: principle-never-block-on-the-human (deciding what waits for the answer and asking for one fact), principle-exhaust-the-design-space (comparing alternatives before you choose yourself), principle-lead-with-the-answer (explaining or reporting a result).
Done: every option has its effect and its cost in one plain sentence.
04 同仓库更多 Skills
xstate
WHEN React state changes in response to an external answer — async submit, in-flight or loading flags, retries, cancellation, polling, optimistic updates, stale responses — or to an interaction with an interruptible middle, such as a drag or a gesture; or WHEN building, reviewing, testing, or visualising XState 5 actors and @xstate/react integrations; NOT for a value one event sets completely, such as a text draft, a focus flag, or a plain open and closed toggle; models typed lifecycles and renders legal Mermaid stateDiagram-v2 charts.
web-design
WHEN refining UI layout, typography, color, or polish; NOT code implementation; provides concise principles for intentional, legible design.
tailwind
WHEN building design systems or component libraries with Tailwind CSS; covers design tokens, CVA patterns and dark mode.
refactoring
WHEN you need a plan to refactor, restructure, or clean up working code and the test result is known, either green or a recorded failing set; NOT for new feature delivery or any behavior change; reversible-baseline safety with prioritized improvements.
react
WHEN building or changing React components, pages, hooks, effects, or apps, including edits to existing components; NOT for test code (react-testing) or styling (css, tailwind); enforces scalable architecture, state management, API layer, performance patterns.
react-testing
WHEN testing React components/hooks/context with React Testing Library; NOT e2e; covers renderHook, providers, forms, and anti-patterns.