decision-analysis

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:

Category	Control	Reason	Probability (%)	Confidence	Impact (1-5)	Early Signal	Countermeasure

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:

Checkpoint	Phase Gate	What to Measure	Kill Criteria	Scale Criteria
Early (before commitment)	Before finalize normative	Design evidence, assumptions, interface feasibility	Core assumptions falsified	Option remains viable
Mid (implementation)	Before advance test	govctl check clean, clause coverage	Spec drift detected	All clauses implemented
Late (release readiness)	Before advance stable	Full test suite, no regressions	Compliance failures	Ready for stable

Output → ADR Mapping

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

Analysis Output	ADR Field	How to Map
Decision statement + constraints	context	Problem statement and constraints section
Premortem + backcast summaries	consequences	Positive from backcast, Negative from premortem (with mitigations)
Options ranking	alternatives	Each option with pros/cons from the exploration table
Top option + rationale	decision	"We will X because..."
Must-pass gates	decision	Add under ### Implementation Notes
Related RFCs/ADRs discovered	refs	Link as references

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.