strategy-interview
Use when the user wants to build or think through a strategy via guided conversation — 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 via CLI (Recommended)
clawhub install openclaw/skills/skills/anderskev/strategy-interviewStrategy Interview
Turn Claude into 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:
- Diagnosis — a judgment about what is actually going on. Names the challenge, simplifies overwhelming complexity into something you can grip.
- 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.
- 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.
Metadata
Not sure this is the right skill?
Describe what you want to build — we'll match you to the best skill from 16,000+ options.
Find the right skillPaste this into your clawhub.json to enable this plugin.
{
"plugins": {
"official-anderskev-strategy-interview": {
"enabled": true,
"auto_update": true
}
}
}Related Skills
explanation-docs
Explanation documentation patterns for understanding-oriented content - conceptual guides that explain why things work the way they do
tutorial-docs
Tutorial patterns for documentation - learning-oriented guides that teach through guided doing
pytest-code-review
Reviews pytest test code for async patterns, fixtures, parametrize, and mocking. Use when reviewing test_*.py files, checking async test functions, fixture usage, or mock patterns.
reference-docs
Reference documentation patterns for API and symbol documentation. Use when writing reference docs, API docs, parameter tables, or technical specifications. Triggers on reference docs, API reference, function reference, parameters table, symbol documentation.
serde-code-review
Reviews serde serialization code for derive patterns, enum representations, custom implementations, and common serialization bugs. Use when reviewing Rust code that uses serde, serde_json, toml, or any serde-based serialization format. Covers attribute macros, field renaming, and format-specific pitfalls.