instinct

instinct

54 strategy and decision frameworks as Claude Code slash commands.

Run SWOT, OKR, First Principles, Pre-Mortem, RICE, and 49 more — directly in your terminal. No tab switching. No blank-page paralysis. Type a command, describe your situation, get a structured analysis.

---

Who it's for

Engineers making architecture, build-vs-buy, or technical strategy decisions.

Product managers running prioritization, roadmap planning, or stakeholder alignment.

Founders choosing go-to-market strategy, evaluating pivots, or stress-testing plans before committing.

Consultants and strategists who need structured analysis fast without pulling up a slide deck.

Any role that reaches for a framework when thinking through a hard problem.

---

Install

/plugin marketplace add tupe12334/instinct

If this saves you time, star the repo — it helps others find it.

---

Demo

/swot — Analyze a strategic decision

              HELPFUL           HARMFUL
         ┌──────────────┬──────────────────┐
INTERNAL │  STRENGTHS   │   WEAKNESSES     │
         │  (leverage)  │   (address)      │
         ├──────────────┼──────────────────┤
EXTERNAL │ OPPORTUNITIES│    THREATS       │
         │  (exploit)   │   (mitigate)     │
         └──────────────┴──────────────────┘

"Should we rewrite our monolith into microservices?"

SWOT ANALYSIS: Monolith → Microservices migration

STRENGTHS
1. Engineering team has prior microservices experience — reduces ramp-up risk
2. Current monolith has clear domain boundaries — clean split points identified
3. Two services (auth, billing) already isolated — migration is incremental

WEAKNESSES
1. No internal platform team — each squad would own its own infra overhead
2. Integration test suite covers monolith end-to-end — will break on extraction
3. 3 senior engineers own 80% of the codebase knowledge — bus factor critical

OPPORTUNITIES
1. Competitor outages last quarter traced to shared DB — decoupling = reliability win
2. Two enterprise deals blocked on SOC2 data isolation — microservices unblocks them
3. Cloud provider offering migration credits until Q3

THREATS
1. Distributed systems complexity will slow feature velocity for 6–12 months
2. Network latency between services not yet benchmarked — SLA risk
3. Current on-call rotation too thin to handle N+1 services

STRATEGIC OPTIONS (TOWS)
SO: Use engineering experience + incremental approach to unblock enterprise deals by Q3
ST: Extract auth service first (low risk, high isolation value) before scaling migration
WO: Hire platform engineer before migrating beyond 3 services — remove bus factor risk
WT: Define 90-day pause criteria — if velocity drops >40%, stop and reassess

PRIORITY ACTIONS:
1. Extract auth service as proof-of-concept — validates approach, unblocks SOC2 conversation
2. Hire or designate platform engineer — prerequisite for any further extraction
3. Benchmark inter-service latency against SLA requirements before committing

---

/first-principles — Challenge an assumption

Conventional thinking:        First-principles thinking:
  "Others do X, so we do X"     Problem
         ↓                         ↓
    Analogy / copy            Ask: what is fundamentally true here?
         ↓                         ↓
   Incremental tweak          Strip assumptions → bedrock facts
                                   ↓
                              Rebuild solution from facts up
                                   ↓
                              Novel or superior solution

"We can't ship faster than bi-weekly — our release process takes two weeks."

FIRST-PRINCIPLES ANALYSIS

Problem: Release cycle is 2 weeks minimum, blocking faster iteration.

Current approach: Code freeze → manual QA → staging deploy → sign-off from 3 teams → prod deploy

Decomposition:
  Code freeze period (3 days)      → ASSUMPTION (protects QA, but QA could run on PRs)
  Manual QA (5 days)               → ASSUMPTION (manual because test coverage is low, not by necessity)
  Staging environment validation   → FACT (need to verify behavior before prod)
  3-team sign-off (4 days)         → ASSUMPTION (legal/security/product — policy, not physics)
  Deployment itself                → FACT (takes ~40 minutes, irreducible)