framework-router

name

framework-router

description

Diagnoses which strategy framework actually fits a business situation described in plain English, or runs a full opportunity through the six-bucket Opportunity Assessment, and hands off to the right deep-dive tool. Use this skill whenever the user describes a business situation and isn't sure how to approach it, says "what framework should I use", "how would you analyze this", "where do I start with this problem", "should we pursue this opportunity", or dumps a messy situation needing structure. Trigger it whenever someone needs to pick the right analytical approach rather than a specific named framework. It is the anti-cheat-sheet: it teaches which tool fits, and refuses to force one that doesn't.

Framework Router

The mark of a senior strategist is not knowing many frameworks. It is reaching for the right one before the other person has finished their sentence, and knowing when none of them fits. This skill does that: it takes a situation in plain English and routes it to the analysis that actually suits, then hands off to the tool that does the deep work.

The method

First, classify the situation and route it. Each route names the deep-dive skill to hand off to:

• Profit or margin problem → profitability tree and unit economics → profit-leak-diagnoser.
• "Should we enter this market?" → the four entry buckets, then Buy/Build/Partner → market-entry-analyzer.
• "How attractive is this industry?" → Five Forces → five-forces-pressure-test.
• "How should we grow?" → Ansoff / BCG / Blue Ocean → growth-move-selector.
• Targeting, messaging, differentiation → Jobs-to-Be-Done, STP, generic strategies → positioning-jtbd-builder.
• "Is this a real advantage?" → VRIO → advantage-auditor.
• "How big is this?" → TAM/SAM/SOM sizing → market-sizer.
• Quick situational read of a company before a decision → the 3Cs → 3c-snapshot.
• A vague symptom with no clear decision → frame the problem first → problem-framer, then return here.

Recommend one primary framework and justify why it fits this situation specifically. Point the user to the matching deep-dive skill for the actual analysis.

When a messy dump hits several routes at once (thin margins, plus a growth question, plus an entry idea), do not pick one at random. Route to the constraint that makes the others moot — usually profitability before growth, and right-to-win before entry mode — and name the sequence, so the user knows what comes second.

For a full "should we pursue this opportunity?" question, run the six-bucket Opportunity Assessment, in order, because failing an early bucket makes the later analysis moot:

1. Opportunity sizing — realistic SOM, not headline TAM (market-sizer does the deep version).
2. Market attractiveness — Five Forces on the industry (five-forces-pressure-test).
3. Strategic fit — does it align with our actual strategy, or is it a distraction with good marketing?
4. Company capability — VRIO on whether we genuinely have the assets to win (advantage-auditor).
5. Financial viability — unit economics, break-even, downside scenario.
6. Risks — strategic, execution, financial, each named with likelihood and severity.

If the opportunity is specifically a market entry, don't duplicate the work here: hand the whole question to market-entry-analyzer, which runs the entry version of these buckets end to end.

Output format

• The situation, restated in one line as the decision at stake.
• Recommended framework(s): the primary one, with why it fits, and the named deep-dive skill. Or the six-bucket sequence for a full opportunity.
• If nothing fits cleanly: say so, and explain what makes this situation resist a standard tool.

How to run it

Default to routing: name the framework, justify it, hand off. Switch to coaching when the user signals they want to build the instinct: ask them which framework they'd reach for and why, then confirm or redirect with reasoning; choosing the tool is the muscle worth training.

Where this breaks

Routing assumes the situation is described accurately, but the stated problem is often a symptom, and matching a framework to the wrong problem gives you a rigorous answer to the wrong question; when the framing is shaky, send the user to problem-framer before routing. And some situations genuinely need no framework, just judgment and facts. Forcing a framework onto a simple call is the exact habit this skill set exists to break, so be willing to say "you don't need a framework here."

Style

Plain language, define any framework you name on first use, no em dashes, short paragraphs. Recommend one primary tool, never a menu of five. No interview-prep framing.