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).
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-interviewSKILL.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
tag and push a release after the release PR is merged
create a release PR (auto-detects previous tag)
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.
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.
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.
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.
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.
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.