# Biz Planner

> Turn a raw business/project idea into a decision-locked execution plan. Use when the user starts a NEW idea, says 'plan this idea', 'biz plan', 'new project idea', 'hackathon project', or wants tech-stack selection, mindmapping, and a final approval-gated plan for any new venture.

- Skill: `tariq-himself/biz-planner` (Agent Skill)
- Install (CLI): `npx skillmds@latest add tariq-himself/biz-planner`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tariq-himself/biz-planner/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Tariq-himself (https://skillmd.com/u/tariq-himself)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tariq-himself/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.