AZIMUTH is a Claude skill that pressure-tests big decisions before you commit. You describe what you're about to do — pick infrastructure, migrate a stack, hire someone senior, sign a contract — and it returns a structured verdict: PROCEED, PILOT FIRST, REDUCE SCOPE, DELAY, or REJECT, with the reasoning. Built for operators making go/no-go calls, not engineers reviewing code.
I built it because the existing pre-mortem skills in Claude Code are code-focused (would this implementation break, what's the bug surface). I wanted something for "is this initiative going to fall apart, and where, and what would have to change for it to work."
(I've been getting borderline evangelical about the concept of "simple machines" lately — wouldn't be wasting the keystrokes if it wasn't adding enough real value to justify its existence. AZIMUTH is my coping mechanism of the week. Enjoy.)
Two examples, since the verdict varies by what's actually broken:
Example 1. I gave it: "We need to pick a job queue by Friday — Redis-backed vs SQS vs Temporal. Decision is mine."
It returned:
- Verdict: DELAY PENDING EVIDENCE. The Friday deadline is internal, not external. Spend two days building a throwaway proof-of-concept on each option against your top-3 use cases. Then decide.
- Risks, severity-ordered:
- False constraint. The Friday deadline is almost certainly self-imposed. The decision is durable for 2-5 years; reversal cost is high.
- Assumption audit failure. Described by vendor (Redis vs SQS vs Temporal), not by workload characteristics. Which jobs are idempotent? Which need exactly-once? Without that, you're choosing on aesthetics.
- Reversibility underestimation. Queue choice gets coupled to retry logic, observability stack, team knowledge. Not as reversible as it feels on Friday afternoon.
Example 2. I gave it: "We're considering migrating from REST to GraphQL across our main API. 4 engineers, ~6 weeks, in parallel with feature work."
It returned:
- Verdict: REDUCE SCOPE. Migrate one bounded subgraph first (one product area's read endpoints). Validate the actual perceived benefit on that slice before committing the full surface.
- Risks, severity-ordered:
- Dominant constraint underweighted. "In parallel with feature work" is the constraint that decides this — feature work always wins under pressure.
- Motivated reasoning. Who's championing this, and what's the user-facing problem GraphQL solves that REST cannot? Audit the assumption.
- Knowledge concentration. Federation layer (Apollo/Relay) becomes a second SPOF. Fallback owner not named.
- Failure path: subgraph 1 ships fine → org commits to full migration → feature work doesn't slow → 6 weeks becomes 5 months → ends up with hybrid REST+GraphQL surface that's worse than either alone.
The repo has the rest — base rates with proper citations, diagnostics for high-stakes decisions, domain templates for launches, rewrites, and hires.
Repo: https://github.com/MrBinnacle/azimuth (MIT)
npx skills add https://github.com/MrBinnacle/azimuth
"Everyone seems to be obsessed with anything that references McKinsey or Enterprise Consultant-level use cases but please do feel free to use it for legitimately important decision-making."
Keep an eye out for v1.1.1 and v1.1.2 (it's getting some teeth).
If you've got a decision you're chewing on, drop the situation in the comments and I'll show what the analysis looks like.