Decision Analysis

Stress-test a design decision using premortem (simulated failure) and backcasting (simulated success), then produce a structured recommendation that feeds directly into ADR artifacts.

This skill is a reference skill — called by /discuss during design exploration, not invoked standalone.

Invocation Mode

Reference-only. This skill does analysis and produces structured output for /discuss and adr-writer. It must not create work items, execute lifecycle verbs, perform VCS operations, or write implementation code.

When to Use

Use this analysis when the decision meets any of:

• 2+ competing options with non-obvious trade-offs
• Irreversible or hard-to-reverse architectural change
• Cross-cutting impact (touches 3+ modules or affects external interfaces)
• Normative RFC finalization with significant design risk

Do not use for: single-option bug fixes, doc-only changes, trivial refactors, or decisions already locked by existing normative RFCs.

Workflow

Step 1: Normalize the Decision

Extract from the discussion context:

• Decision statement: One sentence describing what must be decided
• Options: List of alternatives (always include "do nothing / status quo" if relevant)
• Constraints: Existing RFCs, ADRs, phase requirements, technical limitations
• Success criteria: What "this worked" looks like in measurable terms
• Timeframe: Delivery window; infer a reasonable default if unstated

If any unresolved unknown would materially affect option ranking, reversibility, or constraints, ask clarifying questions before proceeding. If the remaining unknowns are minor, proceed with explicit assumptions. Ask at most 2 clarifying questions in one round.

Step 2: Define Scenario Anchors

Write two one-sentence anchors from the end of the timeframe:

• Failure anchor: What "this went badly" looks like (measurable: regressions, compliance failures, blocked phases)
• Success anchor: What "this worked well" looks like (measurable: tests green, phase advanced, no spec drift)

Note whether the decision is reversible or irreversible, and whether external dependence is low/medium/high.

Step 3: Premortem (Simulated Failure)

For the top 2-3 viable options, imagine each path fully failed. Generate:

• Up to 5 internal causes (controllable: implementation choices, spec gaps, testing blind spots)
• Up to 5 external causes (uncontrollable: dependency changes, upstream breakage, ecosystem shifts)

Make each cause specific and falsifiable. Include govctl-relevant failure modes:

• Silent deviation from normative RFC (Law 2 violation)
• Phase discipline breach (impl work during spec phase)
• Hidden coupling across RFC boundaries
• Migration or data integrity risks
• Operational burden or governance overhead

Step 4: Backcast (Simulated Success)

For the same options, imagine each path succeeded strongly. Generate:

• Up to 5 internal causes (controllable advantages)
• Up to 5 external causes (tailwinds, timing, ecosystem support)

Include govctl-relevant success drivers:

• Clean RFC-to-implementation traceability
• Phase gates caught issues early
• Strong clause coverage in tests
• ADR alternatives documented well enough to avoid revisiting

Step 5: Decision Exploration Table

For each cause from Steps 3-4, assign:

Calibration guide:

• 10-19%: Unlikely but possible
• 20-39%: Somewhat unlikely
• 40-59%: Moderate likelihood
• 60-79%: Likely
• 80-95%: Highly probable

Use numbers, not vague terms.

Step 6: Recommend

Compare the options using the evidence above, rank them, and produce:

• Verdict: Go, No-Go, or Conditional Go
• Top option with 1-sentence rationale
• Must-pass gates before commitment (e.g., govctl check clean, load test threshold, security review)
• Pivot triggers: conditions that would change the recommendation
• Smallest validating step: the smallest non-production validation that reduces uncertainty. Prefer design spike, interface sketch, decision matrix, or isolated experiment. Do not implement governed behavior before the RFC is normative and in impl phase.

For Conditional Go, specify exactly what conditions must be met.

Step 7: Mitigation Strategies

2-4 bullet points for each category:

• Precommitments: Decisions locked now to prevent drift (e.g., "RFC clause X forbids approach Y")
• Hedging: Feature flags, staged rollout, dual-write, rollback plan
• Slow-sabotage prevention: Rules that prevent gradual scope creep or silent deviation
• Setback response: What to do when things go wrong (not "try harder" — concrete next steps)

Step 8: Review Checkpoints

Align with govctl phase gates:

Output → ADR Mapping

When the analysis is complete, map outputs to ADR fields using the adr-writer skill:

Compact Mode

If the decision is moderate-risk (only 2 options, single-module scope, reversible), produce a compact analysis:

1. One-paragraph context with anchors
2. Abbreviated table (top 3 risks, top 3 levers only)
3. Verdict with rationale
4. Key mitigations (2-3 bullets)

Skip Steps 7-8 in compact mode.