一键导入
decision-matrix
Weighted criteria scoring for multi-option decisions — makes trade-offs explicit and defensible with sensitivity analysis.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Weighted criteria scoring for multi-option decisions — makes trade-offs explicit and defensible with sensitivity analysis.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | decision-matrix |
| description | Weighted criteria scoring for multi-option decisions — makes trade-offs explicit and defensible with sensitivity analysis. |
| group | thinking |
| keywords | ["decision-matrix","weighted-scoring","criteria","trade-off","comparison","evaluation","vendor","tool-selection"] |
| task_strategies | ["spike","investigation"] |
| stream_affinity | ["roadmap","research"] |
| allowed-tools | ["Read","Glob","Grep","AskUserQuestion"] |
| status | experimental |
| source | Pugh Concept Selection (1981); Stuart Pugh — Total Design (1990); weighted scoring matrix method |
| acquired | 2026-06-15 |
Make trade-offs explicit. Score each option against weighted criteria.
A decision matrix forces you to separate "what matters" from "how each option performs" — avoiding the trap of choosing the option you want and then finding criteria that justify it.
/brana:swot-analysis for strategic decisions; /brana:six-thinking-hats for perspective sweep before scoringWhat are we choosing between?
AskUserQuestion: "What decision are we making? List the alternatives (2–6)."
What factors matter for this decision? Generate 4–8 criteria. Each criterion should be:
Common criteria clusters:
| Category | Example criteria |
|---|---|
| Cost | Upfront cost, ongoing cost, switching cost |
| Performance | Speed, throughput, reliability, scalability |
| Risk | Vendor lock-in, maturity, team familiarity, security |
| Fit | Integration effort, ecosystem compatibility, flexibility |
| Time | Time to implement, time to value, maintenance burden |
| Strategic | Alignment with long-term direction, community/support |
Distribute 100 points across criteria based on importance to this specific decision.
Criteria | Weight
------------------------|--------
[Criterion 1] | [X]
[Criterion 2] | [Y]
... | ...
Total | 100
Rule: if two criteria have the same weight, that's fine. If one criterion has >40% of weight, consider splitting it — a single criterion dominating is often a sign it contains multiple concerns.
Score each alternative against each criterion on a 1–5 scale:
Criteria | Wt | Option A | Option B | Option C
-------------------|----|----------|----------|----------
[Criterion 1] | 30 | 4 | 3 | 5
[Criterion 2] | 25 | 3 | 5 | 2
[Criterion 3] | 20 | 5 | 4 | 3
[Criterion 4] | 15 | 2 | 4 | 4
[Criterion 5] | 10 | 4 | 3 | 3
-------------------|----|----------|----------|----------
Weighted total | | [calc] | [calc] | [calc]
Weighted total = sum of (weight × score) for each criterion. Divide by 100 to normalize.
The winner is often fragile. Test it:
If the winner changes under any of these: the decision is sensitive to assumptions. State which assumptions are load-bearing.
Sensitivity:
- Winner holds if [assumption A] remains true
- Winner changes if [criterion X] weight drops below [Y]
- Risk: [what to monitor that could invalidate this choice]
**Decision matrix: [decision]**
Options evaluated: [list]
Criteria: [N] factors, highest weight: [criterion] ([W]%)
Results:
1. [Option A] — [score] (winner)
2. [Option B] — [score]
3. [Option C] — [score]
Gap between top 2: [X pts]
If gap < 10 pts: decision is close — review scores for calibration bias
Sensitivity: winner is [stable/fragile] — [key assumption]
Recommendation: [Option A]
Key trade-off accepted: [what we're giving up]
End a session — extract learnings, write handoff, store patterns, detect doc drift. Use when ending a work session or when the user says done/bye/closing.
Build anything — features, bug fixes, refactors, spikes, migrations. Auto-detects strategy, integrates with backlog, enforces TDD. The unified dev command.
Align a project to brana practices — assess gaps, plan, implement, verify. Auto-detects type. Use when setting up a new project or realigning an existing one.
Scan and diagnose a project, or scaffold a new client from scratch. Works for code and venture clients. Auto-detects project type.
Manage the backlog — plan, track, navigate phases and streams. Use when planning phases, viewing roadmaps, or restructuring work.
Structured bug fix — reproduce (failing test), diagnose, fix (minimal change), verify, commit. Enforces test-first. Use when a bug needs a methodical fix.