strategy-writer
$
npx mdskill add rileyhilliard/claude-essentials/strategy-writerCrafts executive strategy documents with evidence-based narratives.
- Generates memos, market analyses, and business cases for leaders.
- Selects specialized personas like Strategist or Analyst for context.
- Prioritizes customer needs and data-backed claims over assumptions.
- Delivers cohesive reports structured for executive decision-making.
SKILL.md
.github/skills/strategy-writerView on GitHub ↗
--- name: strategy-writer description: Produces executive-quality strategic documents in The Economist/HBR style. Use when writing strategy memos, market analysis, business cases, customer research reports, or any document for Product, Design, and Business leaders. Customer-led, evidence-based, narrative-driven. --- # Strategy Writer Strategic writing for executive audiences that sounds like it came from The Economist or Harvard Business Review. Customer-led thinking, evidence-based arguments, cohesive narrative. ## Persona Selection | Writing... | Load | File | |------------|------|------| | Strategy recommendations, executive summaries, opportunity assessments | **The Strategist** | `references/strategist.md` | | Market research, competitive analysis, industry trends | **The Analyst** | `references/analyst.md` | | Investment cases, ROI justifications, go/no-go recommendations | **The Advocate** | `references/advocate.md` | | User research synthesis, customer insights, behavioral patterns | **The Researcher** | `references/researcher.md` | All personas share the same underlying approach: customer-led, evidence-based, narrative-driven. The difference is framing and structure, not rigor. --- ## Core Principles (All Personas) ### Start with the customer Frame every argument from the customer's perspective first. Technology and business model follow from customer need, not the reverse. ### Evidence over assertion Every significant claim needs backing. Data, research, examples, or logical reasoning. "We believe" is not evidence. ### Narrative cohesion Ideas should flow logically from one to the next. The reader should feel the argument building. Isolated points, no matter how valid, don't persuade. ### Logical progression Move from problem to insight to implication to recommendation. Don't jump around. Don't bury the lead, but do earn the conclusion. ### Transformative without salesy Ambitious framing is fine. Excitement about opportunity is fine. But ground it in reality. The reader should feel possibility, not skepticism. --- ## Forbidden Patterns (All Personas) ### Buzzword soup Avoid: leverage, synergy, best-in-class, cutting-edge, seamless, holistic, robust, scalable (unless literally discussing infrastructure). These words say nothing and signal AI or committee-written content. ### Technology-first framing Wrong: "AI enables us to..." Right: "Customers struggle with X. AI is one way to address this because..." Lead with the problem and the person experiencing it. ### Unsupported claims Wrong: "The market is ready for this." Right: "Three signals suggest market readiness: [evidence]" If you can't support it, qualify it or cut it. ### Excessive hedging Wrong: "This could potentially be somewhat beneficial in certain circumstances." Right: "This works well for X use case. It's weaker for Y." Take a position. Acknowledge limits. Don't weasel. ### Em dashes Avoid em dashes (—). They're an AI writing signature. Use commas, parentheses, colons, or split into two sentences instead. Wrong: "The market is growing — and fast." Right: "The market is growing, and fast." or "The market is growing. Fast." --- ## Completeness (Critical) Every point the user requests must appear in the final output. Do not summarize away, merge, or skip details from the prompt. ### Before writing Extract all discrete points, requirements, and topics from the user's request. Create a mental checklist. ### During writing As you write, track which points you've addressed. If a point doesn't fit the narrative flow, find a place for it anyway. Cohesion matters, but completeness matters more. ### After writing Review the output against the original request. Verify every requested element is present. If something is missing, add it before delivering. ### When points seem redundant The user included them for a reason. Don't collapse "market size" and "growth rate" into one sentence if they were requested separately. Give each point its due space. ### When the prompt is long Long prompts are not invitations to summarize. They're specifications. A 10-point request needs all 10 points addressed, each with appropriate depth. --- ## Research Workflow ### Before writing 1. **Define the question** - What decision does this document support? 2. **Identify stakeholders** - Who reads this? What do they care about? 3. **Gather sources** - Prioritize primary data, credible research, concrete examples 4. **Find the through-line** - What's the connecting thread across your evidence? ### Source quality hierarchy | Source Type | Use For | Credibility | |-------------|---------|-------------| | Primary data (interviews, surveys, analytics) | Core claims | Highest | | Peer-reviewed research, industry reports (Gartner, McKinsey) | Market context, trends | High | | Reputable journalism (Economist, FT, WSJ) | Current events, examples | Medium-high | | Company reports, press releases | Company-specific facts | Medium (biased) | | Blog posts, social media | Anecdotes, signals | Low (corroborate) | ### Citation practices **External documents** (board decks, investor materials, published reports): Cite sources explicitly. Include enough detail for readers to verify. **Internal strategy docs**: Lighter touch. Reference data sources but don't need formal citations. Focus on making the logic auditable. --- ## Document Templates | Document Type | Template | When to Use | |---------------|----------|-------------| | Strategy Memo | `references/strategy-memo-template.md` | Executive recommendations, strategic decisions | | Market Analysis | `references/market-analysis-template.md` | Competitive landscape, opportunity sizing | | Business Case | `references/business-case-template.md` | Investment justification, resource allocation | | Customer Insight Report | `references/customer-insight-template.md` | Research synthesis, user behavior patterns | --- ## Formatting (All Personas) - **Paragraphs over bullets** - Build connected arguments. Lists break narrative flow. - **Short paragraphs** - 3-4 sentences max. Let the page breathe. - **Clear headers** - Guide the reader through your logic - **Tables for comparisons** - Side-by-side evaluation, not sequential prose - **Pull quotes for emphasis** - Highlight the insight, not the data --- ## When to Load Each Persona **Load The Strategist when:** - Writing executive summaries or strategy recommendations - Framing opportunities or threats - Making go/no-go recommendations - Synthesizing across multiple inputs into a point of view **Load The Analyst when:** - Conducting market or competitive analysis - Sizing opportunities or segments - Evaluating trends and their implications - Building frameworks for decision-making **Load The Advocate when:** - Building investment cases or business justifications - Requesting resources or budget - Making ROI arguments - Persuading stakeholders toward a specific course of action **Load The Researcher when:** - Synthesizing user research or customer feedback - Identifying behavioral patterns - Translating qualitative data into strategic implications - Bringing the customer voice into decision-making
More from rileyhilliard/claude-essentials
- architecting-systemsGuides clean, scalable system architecture during the build phase. Use when designing modules, defining boundaries, structuring projects, managing dependencies, or preventing tight coupling and brittleness as systems grow.
- configuring-claudeBest practices for writing Claude Code skills, rules, and CLAUDE.md instructions. Use when creating SKILL.md files, authoring .claude/rules, writing CLAUDE.md project or user instructions, or configuring Claude behavior for a project or team.
- fixing-flaky-testsDiagnose and fix tests that pass in isolation but fail when run concurrently. Covers shared state isolation and resource conflicts. References condition-based-waiting for timing issues.
- handling-errorsPrevents silent failures and context loss in error handling. Use when writing try-catch blocks, designing error propagation, reviewing catch blocks, or implementing Result patterns.
- managing-databasesGuides database architecture decisions for PostgreSQL, DuckDB, Parquet, PGVector, and Neo4j. Use when designing schemas, choosing storage strategies, optimizing queries, tuning maintenance, configuring vector search, modeling graph data, or diagnosing performance issues across OLTP, OLAP, similarity search, and graph workloads.
- managing-pipelinesGuides CI/CD pipeline architecture, security hardening, and deployment strategies for GitHub Actions. Use when designing workflows, securing supply chains, optimizing build performance, configuring deployments, managing infrastructure as code pipelines, or setting up pipeline observability.
- migrating-codeSafe code migrations with backward compatibility and reversibility. Use when upgrading dependencies, changing database schemas, API versioning, or transitioning between technologies.
- optimizing-performanceMeasure-first performance optimization that balances gains against complexity. Use when addressing slow code, profiling issues, or evaluating optimization trade-offs.
- planning-productsDefines product features from a PM perspective before technical planning begins. Use when scoping new features, writing product specs, defining user problems, choosing what to build, researching existing patterns, or bridging the gap between strategy and implementation. Covers JTBD analysis, competitive research, UX/DX experience definition, and scope negotiation for consumer, B2B, and developer tool products.
- preflight-checksDetect and run project linters, formatters, and type checkers before committing or claiming completion. Auto-detects tools from project config files.