Biz Planner

Biz Planner — Idea → Decision-Locked Execution Plan

A proven ideation workflow, distilled from real-world planning sessions. Run it on ANY new business/project idea: <IDEA> = the idea text from $ARGUMENTS or conversation.

Stage 0 — Context Ingestion (if provided)

If the user pasted emails, links, rules, competitor material, or requirements:

1. Analyze each source separately first: what it is, hard requirements (table), signals between the lines.
2. Then cross-analyze all sources together: conflicts, changed assumptions, combined implications.
3. Surface the single most important signal before moving on.

Stage 0.5 — Existing Tools Auto-Discovery (always run)

Before asking decision questions, check what the user ALREADY has that this idea can reuse:

1. Look for a cached inventory at ~/.config/opencode/maker-kit/inventory.local.md (Windows: %USERPROFILE%\.config\opencode\maker-kit\inventory.local.md).
2. If missing/stale, scan ~/.config/opencode/agent(s)/, ~/.config/opencode/command(s)/, ~/.config/opencode/skills/**/SKILL.md, and ~/.claude/skills/.
3. List tools relevant to THIS idea (e.g., UI work → installed design/UI skill suites; project tracking → workflow frameworks; screenshots/desktop automation → utility skills).
4. Report in 3–6 lines: "You already own: X, Y — I've factored them into the plan below" and weave them into Architecture/Schedule sections instead of planning to build equivalents from scratch.
5. If a needed capability is missing entirely, note it as a build item OR suggest /maker <session-url> to codify one if a past session covered it.

Stage 1 — Concept Scoping (mindmap)

Decompose <IDEA> into a scoping map before proposing anything:

• Problem & target user (who suffers, who pays)
• Core value proposition in one sentence
• Demo/success surface: what would prove this works when seen for 5 minutes
• Scope boundaries: must-have vs cuttable features (mark each explicitly)
• Constraints: time budget, budget, solo vs team, existing subscriptions/tools

Stage 2 — Decision Questions (interactive, one batch at a time)

Ask 2–4 questions per round using structured options. Rules:

• ALWAYS label a recommended option: "(Recommended)".
• Each option gets a one-line description of its tradeoff.
• Cover, in order: concept direction (offer 3–4 named alternatives + one recommended), time budget, language/framework comfort, delivery channel (pick the cheapest real-world-effect option with least setup friction), and name.
• If the user delegates ("you decide"): decide, then state Decision N + Reasoning: explicitly.

Stage 3 — Tech Stack Selection (criteria-driven, never preference-driven)

Choose every stack element by scoring against explicit criteria, and SHOW the criteria table: | Option | Criterion A | Criterion B | ... | Verdict | Criteria to use (adapt to context): audience/judge/rubric fit, demo visibility (is the choice visible in the outcome?), solo feasibility (thin components, 1–2 responsibilities each), cost/quota impact, ecosystem maturity, setup speed. Also produce a model-selection table if AI models are involved: | Task | Model | Why | Pattern: strong model for agentic coding/risky logic; cheap/free model for boilerplate to conserve quota; cross-family second opinion for final QA.

Stage 3.5 — Design Direction (optional)

After tech stack is locked, ask: "Design phase now or later?" ("Later (Recommended)" for time-boxed builds; "Now" when UI IS the product). If now: run the designer workflow defined in ~/.config/opencode/skills/designer/SKILL.md (or .claude/skills/ equivalent) to produce a DESIGN.md before finalizing the plan, then reference it in Architecture and Schedule ("UI implementation follows DESIGN.md").

Stage 4 — Final Plan Document

Produce ONE plan with exactly these sections:

# <Name> — Final Plan (for approval)

**<one-line summary of locked decisions>**

## Decisions locked
<numbered list of every decision + chosen option>

## Architecture
<ASCII diagram + repo/layout sketch>

## Schedule
<table: phase | day/timebox | deliverable>

## Risks & Mitigations
<numbered list, each with mitigation; flag demo-day failure modes first>

## Day-0 split: what only YOU can do vs. what I do
**You:** <numbered checklist with time estimates>
**Me (once you approve):** <numbered list>

## One verification built into Day 1
<a single early checkpoint that proves the riskiest assumption works>

End with an explicit approval gate: "This is the plan. Approve it and I'll start executing immediately." Do NOT execute anything until the user approves.

Hard rules

• Never skip the approval gate.
• Never pick tech by trendiness — always show the criteria table that justified it.
• Keep recommendations labeled "(Recommended)" everywhere.
• If rules/requirements documents exist, verify claims against their actual text and flag anything unverified as an open item gating execution.