Business Plan

Business Plan

Critical

• NEVER write the report into the project being analyzed. The finished BUSINESS_PLAN.md lives under ~/.claude/business-plans/<project>-<timestamp>/, never in the project root. The analyzed repo must stay clean (git status unchanged after a run). See the Output section at the end of Phase 3 for the exact path.
• Professional document tone. Write in formal business prose. No conversational asides, no editorializing, no casual metaphors. Every sentence is precise and evidence-backed. The document should read like it was prepared by a strategy firm, not written in a chat window.
• Operational, not advisory. This is a business plan the founder can execute against or present to investors — not a consultant's recommendation deck. Prefer concrete specifics (channels, dollar amounts, timelines, deliverables) over abstract strategic arguments. Show the plan, don't argue for it.
• Answer first. Every section leads with its conclusion — never build to a reveal. The recommendation appears on page 1.
• Action titles only. Every section heading is a declarative sentence stating a conclusion, capped at 15 words. "Freemium subscriptions can reach $430K ARR by Year 3" — never "Revenue Projections" or a 25-word sentence.
• MECE or nothing. All argument groupings must be mutually exclusive and collectively exhaustive. If categories overlap, restructure until they don't.
• Three scenarios always. Financial projections must include base, upside, and downside cases. Never present a single-point forecast.
• Source everything. Every market claim, competitive data point, and financial assumption must cite its source inline as (Source Name, Year). Unsourced claims are not permitted. If data is estimated, label it "[Estimate]".
• SCR for the executive summary. The Executive Summary must follow strict Situation-Complication-Resolution structure. Other sections lead with their conclusion (the action title) and support with evidence — they do not need SCR framing.
• Take your time. Quality matters more than speed. A thin plan is worse than no plan.

Formatting Standards

The output must look like a professional document, not a conversation transcript.

• Clean section structure. Use ## Section N: Action Title for main sections. Use ### for subsections. No horizontal rules (---) between sections — use whitespace only.
• No conversational connectors. Never write "Let's look at...", "Now we turn to...", "This brings us to...", or similar transitions. Each section stands on its own.
• Tables over bullets for structured data. Use tables for comparisons, metrics, projections, and competitor data. Reserve bullets only for short lists of 3-5 items where a table would be overkill.
• Consistent number formatting. Currency: $X,XXX or $X.XM. Percentages: X.X%. Large numbers: use K/M/B suffixes. Always include units.
• Source citations inline. Format as (Source Name, Year) — e.g., (Grand View Research, 2025). Collect all sources in a References section at the end of the document.
• No code references. Never reference file names, function names, variable names, or code paths in the report. This is a business document, not a technical audit. Translate all technical findings into business language.

Instructions

This skill has three phases. Phases 1 and 2 dispatch parallel research agents. Phase 3 synthesizes everything into the final report.

Phase 1: Deep Codebase Analysis

Dispatch 3-4 parallel agents to analyze the project. Each agent should target a different dimension:

Agent 1 — Architecture & Tech Stack

• Read CLAUDE.md, ARCHITECTURE.md, README.md, and any docs/ directory
• Identify: languages, frameworks, infrastructure, deployment model
• Assess: technical maturity, scalability constraints, build vs. buy decisions
• Report: 200-word summary with specific findings

Agent 2 — Product & Features

• Read main app entry points, route definitions, screen/page files
• Identify: core features, user flows, what's built vs. placeholder
• Assess: feature completeness, UX sophistication, onboarding experience
• Catalog every distinct feature with its implementation status (built, in progress, planned)
• Report: 200-word summary with complete feature inventory

Agent 3 — Data & Privacy Model

• Read data models, API endpoints, storage layers, auth configuration
• Identify: data architecture, privacy posture, compliance considerations
• Assess: data monetization potential, privacy as differentiator, regulatory exposure
• Report: 200-word summary

Agent 4 — Code Quality & Velocity (optional, include for mature codebases)

• Run git log analysis: commit frequency, contributor count, recent velocity
• Read test files, CI config, linting config
• Assess: development maturity, test coverage, deployment confidence
• Report: 150-word summary

Collect all agent reports before proceeding.

Phase 2: Market & Competitive Research

Dispatch 2-3 parallel web research agents:

Agent A — Market Sizing (TAM/SAM/SOM)

• Research the product's target market using bottom-up methodology
• Find: industry reports, market size estimates, growth rates (CAGR)
• Build bottom-up: addressable users × average revenue per user
• Identify: market trends, tailwinds, headwinds
• Cite every data source

Agent B — Competitive Landscape

• Identify 5-8 direct and indirect competitors
• For each: pricing model, estimated revenue/funding, key differentiators, weaknesses
• Apply Porter's Five Forces to the competitive environment
• Identify white space — where competitors under-serve the market
• Cite every data source

Agent C — Monetization & Business Models (dispatch if the project's revenue model isn't obvious)

• Research how comparable products monetize
• Identify: pricing benchmarks, conversion rates, LTV/CAC ratios in the category
• Recommend 2-3 viable monetization strategies with pros/cons
• Cite every data source

Collect all agent reports before proceeding.

Phase 3: Synthesis & Report Generation

Write the report as a single markdown document. Follow the structure below exactly. Write the Executive Summary last but place it first.

Before writing, consult references/consulting-frameworks.md for the detailed framework rules that apply to MECE structuring, financial modeling, and phase-based roadmaps.

If the user provided a focus-area argument, weight the analysis toward that area while still covering all sections.

Report Structure

The report has 10 sections plus a References appendix. Write sections 2-10 first, then write section 1 last (but place it first). Every section heading must be an action title — a declarative sentence stating the section's key conclusion, capped at 15 words.

Section 1: Executive Summary (write last, place first)

• 300-500 words maximum
• Follow SCR structure strictly:
  • Situation: What exists today — product, stage, team. 1-3 sentences.
  • Complication: Why the status quo is insufficient — the opportunity being missed or the threat approaching. Must create urgency with specific numbers.
  • Resolution: The governing recommendation — one sentence stating the single most important strategic move, followed by 2-3 supporting points.
• End with a quantified outcome and a specific call to action with dates
• This section must stand alone — a reader who reads nothing else should understand the full plan

Section 2: Product Overview (1-2 pages) A reader should finish this section understanding exactly what the product does, how it works, and what state it's in. Synthesize findings from all Phase 1 agents.

• What it is: One-paragraph product description in plain, non-technical language
• How it works: Step-by-step user journey from first open through the core engagement loop. Describe what the user sees and does at each stage.
• Feature inventory: Table with columns: Feature | Status (Built / In Progress / Planned) | Description. Include every meaningful feature from Phase 1 findings.
• Technical foundation: Table with columns: Component | Technology | Purpose. Cover framework, infrastructure, key third-party services. No code-level detail.
• Current stage: Where the product sits (idea → prototype → alpha → beta → launched → growth → mature) with evidence for this classification
• Key technical constraints: 2-3 items that affect business planning (scalability limits, platform dependencies, infrastructure gaps)

Section 3: Market Opportunity (1-2 pages)

• TAM/SAM/SOM with bottom-up methodology, not top-down guesses
• Present as nested scope: total market → addressable segment → realistic capture
• For each tier: state the number, the calculation methodology, and the source
• Market growth rate (CAGR) with source
• Key tailwinds (3-4) and headwinds (2-3), each with one sentence of supporting data

Section 4: Competitive Landscape (1-2 pages)

• Competitor comparison table: 5-8 competitors with columns: Name | Category | Revenue Model | Est. Revenue/Funding | Users | Key Strength | Key Weakness
• Porter's Five Forces: one paragraph per force, rated High/Medium/Low with specific justification. End with a one-sentence competitive intensity summary.
• White space analysis: what gap in the market does this product fill that no competitor addresses?
• Competitive positioning statement: one paragraph on where to play and how to win

Section 5: Business Model & Revenue (1-2 pages)

• Revenue model: What the product charges for, how, and why this model fits. If the choice isn't obvious, compare 2-3 model options in a decision table with columns: Model | Description | Pros | Cons | Expected ARPU.
• Pricing strategy: Specific price points with justification from competitive benchmarks. Annual vs. monthly. Free tier scope and boundaries.
• Unit economics: CAC, LTV, LTV/CAC ratio, payback period. Use industry benchmarks where actuals don't exist, labeled "[Benchmark]".
• Cost structure: Table with columns: Category | Year 1 | Year 2 | Year 3. Include: infrastructure, platform fees, marketing, team, tools.
• Revenue bridge: Step-by-step from $0 to Year 1 revenue — installs → retention → conversion → ARPU → revenue. Each step cites its assumption source.

Section 6: Go-to-Market Strategy (1-2 pages) This section must be concrete and actionable — specific channels, tactics, and timelines. No abstract strategy.

• Launch plan: What happens in the first 90 days post-launch. Sequence of specific actions.
• Acquisition channels: Table with columns: Channel | Tactic | Expected Reach | Cost | Timeline. Include 4-6 channels ranked by expected ROI.
• Retention strategy: Specific product mechanics that drive daily/weekly return usage. What brings users back and why?
• Growth loops: How does one user lead to more users? Describe the viral or network-effect mechanics. If none exist yet, describe what needs to be built and when.
• Partnerships: 2-3 potential partners. For each: who they are, what each party gains, when to pursue.

Section 7: Financial Projections (1-2 pages)

• 3-year projection table with these exact rows:

• Three scenarios in a single comparison table. Bold the base case. For each scenario, state the 2-3 assumptions that differ from base.
• Key sensitivity: Which single assumption most changes the outcome? Quantify the impact: "A 5pp change in [X] produces a [Y]% change in Year 3 revenue."
• Funding needs (if applicable): How much capital is needed, when, and what it funds.

Section 8: Implementation Roadmap (1-2 pages) Phase-based with concrete deliverables — not just milestones, but what gets built and shipped.

• 3-4 phases, each with:
  • Name: Verb-noun format ("Validate Product", "Launch Publicly", "Scale Growth")
  • Time horizon: Month ranges
  • Key question: The strategic question this phase answers
  • Deliverables: 3-5 specific outputs (features shipped, launches completed, hires made, partnerships signed)
  • Success criteria: Quantitative gates that must be met before advancing to the next phase
  • Resources required: Team size, budget, key tools or services
  • Dependencies: What must be true from the previous phase before this one can begin
• Total deliverables across all phases: 10-15

Section 9: Key Metrics (0.5-1 page)

• 6-9 KPIs total in a single table with columns: Metric | Target | Leading/Lagging | Measurement Method | Review Cadence
• Mix of leading indicators (inputs you control) and lagging indicators (outcomes you measure)
• One paragraph connecting the metrics back to the financial projections in Section 7

Section 10: Risks & Mitigants (0.5-1 page)

• Top 5 risks in a table with columns: Risk | Likelihood (H/M/L) | Impact (H/M/L) | Severity | Mitigation
• Each risk must be specific — name the exact threat, not a category. "A funded competitor launches a similar NYC walking game" not "Competition."
• Each mitigation must be a concrete action with a trigger, not "monitor the situation"

References

• All sources cited in the document, formatted as: Author/Publisher. "Title." Date. URL if available.
• Grouped by section for easy verification

Output

NEVER write the report into the project being analyzed. Save it to a scratch directory under ~/.claude/business-plans/ so the project repo stays clean.

PROJECT_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
PROJECT_SLUG="$(basename "$PROJECT_ROOT" | tr '[:upper:] _' '[:lower:]--')"
PLAN_DIR="$HOME/.claude/business-plans/${PROJECT_SLUG}-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$PLAN_DIR"

Write the report to $PLAN_DIR/BUSINESS_PLAN.md. If ~/.claude/business-plans/ is not writable, fall back to $TMPDIR/business-plans/ and warn the user. NEVER fall back to writing inside the project.

Print the Executive Summary inline to the user and always print the absolute $PLAN_DIR path so they can open the full document.

After writing, re-read the full document and verify:

1. Every section heading is an action title (declarative sentence ≤15 words, not a topic label)
2. The executive summary follows SCR and stands alone
3. All financial projections have three scenarios
4. Every market claim has an inline citation
5. No conversational language, no code references, no editorializing
6. Section 2 gives a complete picture of the product (feature table, user journey, tech stack)
7. Section 6 has specific channels and tactics with timelines
8. Section 8 has concrete deliverables with dependencies, not just milestone names

Report completion to the user with a brief summary of the key recommendation.

Error Handling

1. Codebase has no documentation: Rely on code structure, file names, and git history. State explicitly in the report: "This assessment is based on code analysis; no project documentation was available."
2. Market data is sparse: Use proxy markets and analogous products. State assumptions clearly. Flag low-confidence estimates with "[Estimate]" tags.
3. Revenue model is unclear: Present 2-3 options as a decision table instead of forcing a single recommendation. Frame Section 5 as "Business Model Options."
4. Project is pre-code (idea stage): Skip Phase 1 codebase analysis. Ask the user for a product description. Weight the report toward market opportunity and go-to-market strategy.
5. Web research returns limited results: Use available data and be transparent about gaps. "Competitive data is limited; the following analysis covers the [N] identified competitors" is better than fabricated comprehensiveness.

Examples

Example 1: Mobile app with existing codebase

Input: /business-plan (run in a Flutter mobile app project)

Output: Full 10-section report with detailed product breakdown (feature inventory table, user journey, tech stack), 8 competitors analyzed, revenue model with unit economics, go-to-market plan with 5 acquisition channels and timelines, 3-year projections in three scenarios, phased roadmap with 12 deliverables and dependencies, and 8 KPIs. Professional formatting throughout — no casual language, no code references, formal prose.

Example 2: Focused analysis

Input: /business-plan monetization

Output: Same 10-section structure, but Sections 5 and 7 (Business Model and Financial Projections) get deeper treatment — multiple revenue model comparisons in decision tables, detailed pricing analysis with competitor benchmarks, sensitivity analysis on conversion rates and ARPU, monthly Year 1 projections.

Example 3: Early-stage project

Input: /business-plan (run in a repo with minimal code)

Output: Report acknowledges early stage. Section 2 is shorter (less to describe). Financial projections use wider scenario ranges. Roadmap Phase 1 focuses on MVP validation. Go-to-market section emphasizes validation channels (landing page, waitlist, user interviews) over scale channels.