Decision Procedure

Input: $ARGUMENTS

Interpretations

Before executing, identify which interpretation matches the user’s input:

Interpretation 1 — Build a reusable decision process: You face a type of decision that recurs (for you or others) and want to create a mechanical, followable procedure so it doesn’t require expertise each time (e.g., “make this decision repeatable” or “build me a decision tree for hiring”). Interpretation 2 — Navigate a one-time decision: You have a specific decision to make right now and want structured help thinking through it — not building a reusable template, just getting to an answer (e.g., “how should I decide whether to take this job?”). Interpretation 3 — Audit an existing decision process: You already have a way decisions get made (formally or informally) and want to examine whether it’s sound, find its blind spots, or improve it (e.g., “our promotion process feels broken” or “why do we keep making bad hiring decisions?”).

If ambiguous, ask: “I can help with building a reusable decision procedure, working through a specific decision right now, or auditing an existing decision process — which fits?” If clear from context, proceed with the matching interpretation.

Purpose

Some decisions are made repeatedly by many people, and most people navigate them poorly because they lack expertise. This skill creates a mechanical procedure — a flowchart or decision tree that takes someone from “I have this decision to make” to “here is my answer” without requiring them to understand the underlying domain.

What this produces: A step-by-step procedure (like a medical diagnostic flowchart or troubleshooting guide) that anyone can follow to make a specific type of decision.

This is a compound skill — it chains 6 skills in sequence.

The Chain

Step 1: /dd       -- What dimensions matter for this decision?
Step 2: /se         -- What are all the options within each dimension?
Step 3: /aex     -- What assumptions does the standard approach make?
Step 4: /stg          -- Create the step-by-step procedure
Step 5: /fla      -- What goes wrong when following this procedure?
Step 6: /pv      -- Is every step executable without interpretation?

Execution Procedure

Step 1: Discover Decision Dimensions

-> INVOKE: /dd $ARGUMENTS

Map all the dimensions that matter for this decision:

What factors determine the right choice?
What information do you need before deciding?
What constraints narrow the options?
What are the axes of variation?

Target: 8-15 dimensions that collectively determine the right answer.

Output: Named dimensions with descriptions and why each matters.

Step 2: Enumerate Options per Dimension

-> INVOKE: /se [dimensions from Step 1]

For each dimension, enumerate the possible values:

What states can each dimension be in?
What are the common cases vs edge cases?
Are there dimensions that interact (if X=A, then Y must be B)?

Output: Complete option space organized by dimension.

Step 3: Surface Hidden Assumptions

-> INVOKE: /aex [standard approach to this decision]

What does the conventional wisdom about this decision assume?

What do experts know implicitly that novices miss?
What assumptions could lead someone to the wrong answer?
Where do people commonly go wrong?

Output: Assumptions that the procedure needs to address or protect against.

Step 4: Generate the Procedure

-> INVOKE: /stg [dimensions, options, assumptions from Steps 1-3]

Create the actual step-by-step procedure:

Format requirements:

Written for someone with NO domain expertise
Every step is a concrete action or observation (not “consider” or “think about”)
Decision points are binary or small multiple choice (“Is X true? If yes, go to Step N. If no, go to Step M.”)
No jargon without definition
Include “what you should see” at each step so the user knows they’re on track

Structure:

STEP 0: What type of [decision] is this?
  [Classification table pointing to sections]

SECTION A: [Type 1]
  Step A1: [concrete action]
  Step A2: [observation or check]
  Step A3: [decision point] -> if yes: A4, if no: A5
  ...

SECTION B: [Type 2]
  ...

QUICK REFERENCE: [Summary cards]

Output: The procedure document.

Step 5: Anticipate Failures

-> INVOKE: /fla [procedure from Step 4]

How can following this procedure go wrong?

Where might someone misidentify their situation?
Where might the procedure give the wrong answer?
What edge cases aren’t covered?
What are the most common mistakes?

For each failure mode:

How to recognize you’re in it
What to do instead

Output: Failure modes added to the procedure as warnings and overrides.

Step 6: Validate Executability

-> INVOKE: /pv [complete procedure from Steps 4-5]

Check every step:

Can someone with NO expertise execute this step?
Is there any ambiguity in what to do?
Are all decision points clear (not “use your judgment”)?
Does every path lead to a concrete output?
Are there dead ends or loops?

Fix any issues found.

-> COMPLETE

Output Standards

The procedure must be followable by someone who has ZERO understanding of the domain
Plain language only — define any technical terms inline
Every decision point must be binary or explicit multiple choice
Include worked examples showing the procedure applied to real cases
Include a “Common Mistakes” section
Include a “When to Override This Procedure” section (when to seek expert help)
Validation status: “This procedure has not been validated by domain experts”

Output Format

[DECISION TYPE] PROCEDURE
=========================

STEP 0: What type of [decision] is this?
[Classification table]

SECTION [A-Z]: [Each type]
[Numbered steps with decision points]

QUICK REFERENCE CARDS
[Summary of key formulas/rules/tables]

COMMON MISTAKES
[Numbered list of what goes wrong]

WHEN TO OVERRIDE
[When this procedure isn't enough]

WORKED EXAMPLES
[2-3 examples walking through the procedure]

Example Usage

/dcp choosing a software architecture
/dcp debugging any software bug
/dcp evaluating a job offer
/dcp choosing a college major
/dcp deciding whether to start a business

dcp - Decision Procedure