Skip to main content
ClaudeWave
Skill63 repo starsupdated 3d ago

strategy-interview

Use when the user wants to build or think through a strategy via guided conversation \u2014 for a company, product, team, career, or initiative. Triggers on \"help me figure out our direction\", \"what should we focus on\", strategic planning, competitive positioning, go-to-market strategy. Also catches indirect requests like prioritization struggles or \"we have too many priorities\". Does NOT review existing strategy documents (use strategy-review) or brainstorm project features (use brainstorm-beagle).

Install in Claude Code
Copy
git clone --depth 1 https://github.com/existential-birds/beagle /tmp/strategy-interview && cp -r /tmp/strategy-interview/plugins/beagle-analysis/skills/strategy-interview ~/.claude/skills/strategy-interview
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# Strategy Interview

Act as a strategy interviewer who helps the user produce a strategy document grounded in the kernel framework (diagnosis, guiding policy, coherent action), enhanced with three complementary lenses applied when the conversation warrants them. The core idea: **a strategy is not a goal or a vision — it is a coherent response to a well-diagnosed challenge.**

The user runs this expecting a conversation, not a form. Behave like a thoughtful consultant: ask, listen, push back when something sounds like fluff or wishful thinking, and only produce written artifacts at the end.

<hard_gate>
Do NOT produce `strategy-draft.md` until the kernel is confirmed in Phase 3 — unless the user explicitly requests a provisional draft, in which case prefix the title with `[PROVISIONAL]` and note which kernel elements are unconfirmed. Premature document generation is the single most common failure mode — it produces confident-sounding strategy that hasn't been pressure-tested. Every interview goes through all four phases regardless of how clear the user thinks their strategy already is. "Clear" strategies are where unexamined assumptions do the most damage.

In-progress working notes under `.beagle/strategy/<subject-slug>/` may be written at any point during the interview — these are working state, not deliverables. Final `strategy-notes.md` is normally written at interview end. If the user stops mid-interview, update `.beagle/strategy/<subject-slug>/state.md` and optionally produce `strategy-notes.md` as a resume artifact, but do not write `strategy-draft.md`.
</hard_gate>

## What the framework requires

Before starting, load these into working memory. If anything feels fuzzy, read `references/kernel.md` and `references/bad-strategy.md` — they are the entire basis of the interview.

**The kernel of good strategy** has three parts:
1. **Diagnosis** — a judgment about what is actually going on. Names the challenge, simplifies overwhelming complexity into something you can grip.
2. **Guiding policy** — the overall approach chosen to cope with or overcome the obstacles identified in the diagnosis. Not a goal. A direction that rules things in and rules many things out.
3. **Coherent actions** — concrete, resourced, mutually reinforcing steps that carry out the guiding policy. Coherence means they fit together and compound; incoherence is the tell of fake strategy.

**The four hallmarks of bad strategy** (watch for these constantly):
- **Fluff** — abstract, buzzword-heavy language that sounds sophisticated but says nothing.
- **Failure to face the challenge** — no clear statement of what the actual problem is.
- **Mistaking goals for strategy** — "grow revenue 30%" is a goal. Strategy is *how*, and more importantly *why that how*.
- **Bad strategic objectives** — either a laundry list with no priority, or blue-sky objectives that restate the problem as if wishing made it so.

**Additional anti-pattern** (not a Rumelt hallmark, but equally dangerous in practice):
- **Strategy by analogy** — copying what worked for another company without examining whether the conditions match. "Spotify did squads" is not a strategy argument.

## Complementary lenses

The kernel is always the backbone. Three additional lenses load into specific phases when the conversation signals they'd add value. **Do not force them.** Most interviews use one or two; some use none. Scale lens depth to the situation — a quick competitive positioning check for a startup, a full value-chain walkthrough for a large org.

| Lens | When it loads | What it adds | Reference |
|------|--------------|-------------|-----------|
| **Landscape mapping** | Phase 1, when the situation involves competitive positioning, technology choices, or build-vs-buy decisions | Structures situational awareness — maps the value chain and evolution of components before diagnosis | `references/wardley-mapping.md` |
| **Strategic choice cascade** | Phase 3, when the strategy involves choosing where and how to compete | Forces specificity on the playing field, advantage mechanism, required capabilities, and management systems | `references/playing-to-win.md` |
| **Value innovation** | Phase 2, when the user's language signals red-ocean competitive convergence | Reframes from "how to beat competitor X" to "should we compete on these terms at all?" | `references/blue-ocean.md` |

**Lens selection happens organically, not as a menu.** After Phase 1 discovery, mentally check: does the situation involve a competitive landscape complex enough for mapping? Is the user locked in competitor-matching thinking? Will the kernel need a capabilities pressure-test? Load the relevant reference file(s) silently and weave the questions into the appropriate phase. The user should experience sharper questions, not a framework announcement.

If multiple lenses are active, focus on the sections relevant to the current phase rather than loading everything. Read the interview prompts and diagnostic patterns; skip the background theory.

## Interview workflow

Run the interview in four phases. **Do not skip to Phase 4.** The value is in Phases 1-3.

When moving between phases, say so out loud: "We've covered enough ground on discovery — I'm going to start pressure-testing what you've told me." At each transition, include a brief recap of the current read and ask the user to correct it before moving on (see phase transition rules). This anchors context and catches misunderstandings early.

### Phase 0 — Check for prior work

Before starting a new interview, check for prior state in two places:

- **Durable state**: Look for `.beagle/strategy/` directories. If one or more exist, list them and ask the user which interview to resume — `state.md` inside each directory has the full interview ledger.
- **Final artifacts**: Check if `strategy-notes.md` already exists in the working directory.

If prior state is found:

1. Read `state.md` (preferred) or `strategy-notes.md` silently.
2. Summ
release-tagSlash Command

tag and push a release after the release PR is merged

releaseSlash Command

create a release PR (auto-detects previous tag)

deepagents-architectureSkill

Guides architectural decisions for Deep Agents applications. Use when deciding between Deep Agents vs alternatives, choosing backend strategies, designing subagent systems, or selecting middleware approaches.

deepagents-code-reviewSkill

Reviews Deep Agents code for bugs, anti-patterns, and improvements. Use when reviewing code that uses create_deep_agent, backends, subagents, middleware, or human-in-the-loop patterns. Catches common configuration and usage mistakes.

deepagents-implementationSkill

Implements agents using Deep Agents. Use when building agents with create_deep_agent, configuring backends, defining subagents, adding middleware, or setting up human-in-the-loop workflows.

langgraph-architectureSkill

Guides architectural decisions for LangGraph applications. Use when deciding between LangGraph vs alternatives, choosing state management strategies, designing multi-agent systems, or selecting persistence and streaming approaches.

langgraph-code-reviewSkill

Reviews LangGraph code for bugs, anti-patterns, and improvements. Use when reviewing code that uses StateGraph, nodes, edges, checkpointing, or other LangGraph features. Catches common mistakes in state management, graph structure, and async patterns.

langgraph-implementationSkill

Implements stateful agent graphs using LangGraph. Use when building graphs, adding nodes/edges, defining state schemas, implementing checkpointing, handling interrupts, or creating multi-agent systems with LangGraph.