Bp outline

BP Outline

Build the investment story before choosing a visual style. This skill stops at an approved, source-backed outline and does not generate PPTX/PDF.

Input

Any combination of:

• repository, product docs, PRD, website, prior applications, or existing BP;
• analytics exports, payment/usage data, GitHub evidence, and customer notes;
• product screenshots, founder profile, team history, brand assets;
• financing stage, amount, equity/instrument, and milestones.

Output Contract

business-plan/
├── brief.md
├── evidence-ledger.md
├── outline.md
└── assets/

The output is ready for lov-bp-deck only when the evidence gate passes.

Workflow (MANDATORY)

Step 0: Resolve the skill and workspace

Resolve this SKILL.md directory as SKILL_DIR. If the user already has a business-plan/ workspace, continue in it. Otherwise initialize one:

python3 "$SKILL_DIR/scripts/init_bp.py" \
  --name "Project Name" \
  --stage seed \
  --output ./business-plan

Read references/user-config.md for portable path and brand resolution.

Step 1: Inspect before asking

Search the user's supplied scope first. Prefer exact repo/files/URLs over broad discovery. Extract known audience, financing stage, ask, product, buyer, traction, business model, market, competition, growth, and team evidence.

Ask at most one compact round of questions for missing decisions that materially change the outline. If the user says “不要问”“按推荐方案”, assume seed investors, 12–15 slides, 8–10 minutes, and mark the financing ask as a visible gap if unknown.

Step 2: Build the evidence ledger

Record every material claim as:

• fact;
• inference;
• assumption;
• missing.

Include source, as-of date, slide destination, and next action. For changing claims, verify current authoritative sources. Never substitute a broad AI forecast for a buyer-linked market calculation. Read references/evidence-and-market.md.

Step 3: Define the investor-readable product

Before the vision, draft three one-line definitions:

1. literal category;
2. accurate comparator (“X for Y”);
3. category-creation language with a plain-language explanation.

Choose the line a non-technical investor can repeat after ten seconds. Separate:

early wedge → adjacent users → long-term market

Treat technical modes as implementation unless the buyer actually pays for the mechanism. Read references/investor-story.md.

Step 4: Write the 12–15 page argument

Use this 12-page base:

1. one sentence: who you are;
2. concrete user problem;
3. how the product solves it;
4. product demo or core experience;
5. why now;
6. real validation;
7. business model;
8. market size and wedge;
9. competition and differentiation;
10. growth plan;
11. why this team;
12. financing ask, use, and next proof.

Expand only when a product demo, moat, B2B deployment model, or financial model needs a dedicated page. Read references/deck-architecture.md.

Each slide entry must contain:

• conclusion headline;
• investor takeaway;
• evidence IDs and sources;
• exact visual/chart proof;
• speaker purpose;
• unresolved gap or “none”.

Step 5: Run the evidence gate

The outline is ready only when:

• all 12 investor questions are covered;
• the product definition is investor-readable;
• every core number traces to evidence or a labeled assumption;
• traction stages and denominators are not mixed;
• TAM/SAM/SOM has a buyer-price-reachability bridge;
• the financing ask connects to 18–24 month validation milestones;
• no placeholder is hidden as final copy.

Report the page map and at most five evidence gaps. Do not start slide generation unless the user asked for a complete BP or explicitly continues with bp-deck.

Recommended Next Step

$lov-bp-deck ./business-plan/outline.md

Runtime context (shared)

运行前读取本 Skill 包的 skill.yaml，由宿主提供 skill-runtime/v1 上下文。字段解析顺序为：当前请求、项目上下文、个人 Preferences、品牌 Profile、通用默认值。

• 只使用 Manifest 声明的字段；Profile 保存公开品牌事实，Preferences 保存个人工作偏好。
• required: true 字段缺失时，按 Manifest 的问题配置向用户提出一个聚焦问题；用户明确同意后再保存回答。
• 报错提供可复制的 context_id、字段路径与来源，诊断内容避开秘密、完整私人路径和原始配置。

通用反馈闭环

用户在 Skill 驱动任务中提出修改意见时，继续当前产物前必须执行：

1. 先判断意见是 task-specific（仅本次）还是 reusable（可跨任务复用）。
2. task-specific 只修改当前任务，不改 Skill。
3. reusable 先确定作用域：领域规则先更新对应 canonical Skill；适用于所有 Skill 的规则先更新共享规范。
4. 完成规则更新、版本、lint 与分发核验后，再把修改应用到当前任务。
5. reusable 修改会使此前的“确认”“继续”“发吧”失效；完成当前产物修改和回读后必须停下，等待用户下一步指示，不自动进入发布、提交或其他外部写入。