skills/decision-analysis/SKILL.md
MANDATORY trade-off evaluation. You MUST invoke this skill when the user faces a choice between alternatives — build-vs-buy, rewrite-vs-patch, technology selection, resource allocation, priority decisions. Do NOT default to the first reasonable option. Do NOT skip evaluating "do nothing" as a valid alternative. Invoke this to run weighted criteria analysis with second-order consequences before recommending.
npx skillsauth add xD4O/praxis decision-analysisInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
EXTREMELY_IMPORTANT: This is a MANDATORY protocol, not a suggestion. Follow every step. Do not skip steps. Do not combine steps. Do not summarize. Work through each gate in order.
You're choosing between alternatives. Do NOT default to the first reasonable option. Work through this protocol to find the best option — or discover the question is wrong.
State the decision in one sentence. Then check:
Type 2 → Spend 10 minutes on this protocol. Decide and iterate. Type 1 → Spend proportional effort. Get it right.
List ALL viable options, including:
For each option, state in one sentence what it optimizes for.
List 4-6 criteria that matter for this decision. Assign weights (1-5).
Common criteria: cost, speed to deliver, risk, maintainability, team capability, scalability, user impact, reversibility.
Ask the user which criteria matter most. Do NOT assume.
For each option, score each criterion (1-10). Multiply by weight. Sum.
Present as a table:
| Option | Criterion A (×W) | Criterion B (×W) | ... | Total | |---|---|---|---|---|
If two options are within 10% of each other, the decision matrix alone is insufficient. Proceed to Step 5 for tiebreaking.
For the top 1-2 options, apply:
Second-order thinking: What happens 6 months after we choose this? What's the 2nd-order consequence? The 3rd-order?
Pre-mortem: Assume we chose this option and it failed badly in 6 months. What went wrong? Is that failure preventable?
Steelman the loser: Make the best possible case for the option you're NOT recommending. If the steelmanned case is compelling, reconsider.
State your recommendation explicitly:
RECOMMENDATION: [Option X]
├── Why: [1-2 sentence justification tied to highest-weighted criteria]
├── Key risk: [the most likely way this goes wrong]
├── Mitigation: [how to address that risk]
├── Reversibility: [Type 1/2, what undo looks like]
└── Confidence: [HIGH / MEDIUM / LOW]
If confidence is LOW, state what additional information would increase it, and recommend gathering that information before committing.
<HARD-GATE> Do NOT recommend an option without: - At least 3 options evaluated (including "do nothing") - Explicit criteria with weights confirmed by the user - Second-order consequences considered for the recommendation - Confidence level statedThis skill prevents:
After recommendation is made and user accepts:
If Superpowers is installed and the decision leads to building something → invoke
Skill(superpowers:brainstorming) with the chosen option, criteria weights, and key
risks as context. Let Superpowers drive the design of the chosen approach.
If Superpowers is NOT installed → proceed to design or implementation based on the recommendation.
development
MANDATORY — HIGHEST PRIORITY SKILL. You MUST invoke this skill (praxis) BEFORE invoking superpowers:brainstorming or ANY other skill when the task is non-trivial. This skill classifies the problem, selects reasoning frameworks, and runs threat analysis BEFORE brainstorming begins. Do NOT invoke superpowers:brainstorming first. Do NOT respond directly. Do NOT ask clarifying questions on your own. Invoke praxis FIRST, complete its gates, THEN hand off to superpowers:brainstorming. Non-trivial means: system design, feature planning, architecture decisions, debugging, security-sensitive code, trade-off evaluation, code review, or refactoring. Trivial means: fix a typo, rename a variable, answer a factual question, run a command.
development
MANDATORY strategic analysis. You MUST invoke this skill for business decisions, product strategy, competitive analysis, roadmap prioritization, or any decision about WHAT to build rather than HOW to build it. Do NOT skip SWOT analysis. Do NOT present strategy without measurable OKRs. Invoke when the problem is about direction, positioning, or priorities rather than implementation.
development
MANDATORY threat analysis. You MUST invoke this skill before writing or approving ANY code involving authentication, authorization, cryptography, input handling, payment processing, PII, secrets management, API endpoints, or trust boundaries. Do NOT write security-sensitive code without running STRIDE analysis first. Do NOT say you will add security later. Auth is a design decision, not a feature to bolt on.
development
MANDATORY first step. You MUST invoke this skill before brainstorming, designing, or planning any non-trivial work. Do NOT start asking clarifying questions on your own — this skill's gates ARE the clarifying questions. Invoke when the user asks to build, design, plan, create, architect, or implement anything substantial. Do NOT skip this because the task seems straightforward. Straightforward-seeming tasks with wrong framing produce the most expensive failures.