Claude Code Skill

Verify the
bearing
before you
step off.

AZIMUTH pressure-tests decisions before you commit to them. Run it before you greenlight the rewrite, the hire, the launch, or the bet.

$ npx skills add https://github.com/MrBinnacle/azimuth

Compatible with Claude Code and Claude.ai

The problem

Plans look fine until they don't.

The risks that sink projects are usually the ones nobody questioned — the assumption holding everything together, the dependency nobody secured, the failure mode that's common in decisions like this one but invisible from inside it.

AZIMUTH runs the structured pressure-test before you're committed.

Capabilities

What you get

01 / Verdict

A verdict with a rationale

Not just "risky" — a specific recommendation: proceed, pilot first, reduce scope, delay, or reject. With the structural reason why.

02 / Assumptions

Assumption audit

Every assumption classified as strong, partial, unsupported, or contradicted — plus a falsifier for each: the observable evidence that would prove it wrong.

03 / Failure paths

Failure path analysis

The most plausible ways this fails, traced trigger → cascade → business cost. Pair-interaction analysis where two risks together produce a worse outcome than either alone.

04 / Incentives

Incentive scan

Who proposed this, who benefits, who absorbs the downside, whether dissent was heard. Structured into the verdict — not an afterthought.

05 / Dependencies

Dependency fragility map

What's a single point of failure, what's secured vs. assumed, what the lead time is to replace what isn't.

06 / Mitigations

Structural mitigations only

Generic advice is rejected. "Communicate better" and "monitor closely" don't appear in the output.

Signals

How to know it's working

  • Assumptions you treated as given are being validated, not accepted
  • The verdict surprises you — or confirms what you suspected but couldn't articulate
  • The failure paths describe something that has actually happened to similar decisions
  • The incentive scan names a conflict you hadn't explicitly surfaced
  • You change the plan before committing, not after

Example output

Legacy billing rewrite

azimuth — analysis
→ /azimuth We're planning to rewrite our legacy billing service in Q3. 8 weeks, 2 engineers. ## Azimuth Verdict High-risk. Scope and timeline are inconsistent with known base rates for legacy rewrites. Do not proceed without scope reduction and a validated rollback strategy. ## Recommended Decision PILOT FIRST — Rewrite one isolated billing module with full rollback. Validate assumptions about coupling before committing full scope. ## Confidence Level High — base rate for legacy rewrites exceeding estimate is well-documented. No evidence present that shifts this. ## Critical Risks 1. Integration tax — Parallel-running old and new systems historically extends to 3–5× estimated cutover time. No hard deprecation date defined. 2. Knowledge concentration — Single-person domain knowledge on billing logic creates SPOF. No fallback owner named. 3. Scope creep under deadline — "While we're at it" rewrites reliably overload scope. No change control mechanism defined. ## Falsifiers — Knowledge concentration: A second engineer can document and reproduce billing edge case behavior independently within 2 weeks — or the SPOF is real. — Timeline estimate: Comparable module rewrite completed within 2 weeks in a spike — or the 8-week total is unsupportable. ## Likely Failure Path Billing edge cases surface → scope expands → 8 weeks becomes 20 → old system maintenance + new system debt → both teams overloaded → defects in prod

Works on launches · hires · service rewrites · build vs. buy decisions · org changes · strategic bets

5 / 6
Healthcare.gov · DEEP mode · 2013 AZIMUTH surfaced 5 of the 6 documented root causes with 0 false positives. Read the case study →

Quick start

Invoke on any decision

/azimuth We're planning to rewrite the legacy billing service in Q3
/azimuth Should we make this hire?
/azimuth We're launching next week — is the plan sound?
/azimuth Build vs. buy vs. partner for this capability?
/azimuth Pressure test our Q3 timeline

Verdict taxonomy

Nine possible verdicts

Verdict When it fires
PROCEED Evidence supports moving forward; risks are manageable
PROCEED WITH SAFEGUARDS Proceed only if specific structural changes are made first
PILOT FIRST Validate the highest-risk assumption before committing full scope
REDUCE SCOPE Current scope is not supportable; a smaller version may be
DELAY PENDING EVIDENCE Decision is premature; specific information is needed
REJECT Evidence or structure does not support proceeding
INSUFFICIENT SIGNAL Input too sparse or contradictory to ground analysis
WRONG TOOL Input is not a pre-commitment decision question
RESIDUAL-RISK-REGISTER Decision already made — produces a forward-looking residual risk register, not a go/no-go verdict