SuperAPI AI Directory

lov-bp

Office & productivity

View repository

Updated 10-16 00:01

About this skill

BP Skill Kit

Compose only the stages the user needs. The kit preserves the existing $lov-bp entrypoint while exposing three focused skills that can be used independently.

Triggers

Activate for requests containing or clearly implying:

  • Chinese: “Business Plan”, “BP Outline”, “Fundraising PPT”, “Roadshow Materials”, “Investor Presentation”, “BP Review”, “BP Polishing”, or “Create a complete BP from project materials”;
  • English: “business plan”, “BP outline”, “pitch deck”, “investor deck”, “fundraising deck”, “review my BP”, or “polish this deck”.

Do not activate for a generic company introduction, ordinary product presentation, annual report, marketing proposal, or document formatting request unless the user also needs an investor-facing business plan.

Runtime and portability

Use Python 3.8+ for workspace and audit scripts. Resolve presentation generation through the active Agent Skills environment; never assume an author's private path. Take user-specific output, brand, and asset paths from the request or current project.

Kit Map

Skill Input Output Use alone when…
lov-bp-outline Project files, links, metrics, interviews brief.md, evidence-ledger.md, outline.md The user needs to clarify the investment story first
lov-bp-deck Approved outline + evidence + brand assets PPTX, PDF, preview, deck manifest The outline already exists and the user wants slides
lov-bp-polish Outline, PPTX/PDF, or rendered slides Scored report + exact revisions + corrected assets The user already has a BP and wants it made credible/professional

Default full pipeline:

project evidence
      ↓
bp-outline ── evidence gate ──→ bp-deck ── visual gate ──→ bp-polish
      │                             │                         │
      └ brief / ledger / outline    └ PPTX / PDF / preview   └ report / fixes

Routing Rules

Select the smallest route that fulfills the request:

User intent Route
“Write the BP outline first”, “Organize the fundraising narrative” bp-outline
“The outline is ready, turn it into a PPT”, “Choose a PPT style” bp-deck
“This BP is unprofessional”, “Polish/review/modify charts/modify layout” bp-polish
“Create a complete BP”, “Go from project materials to PPT” bp-outline → bp-deck → bp-polish
“Rewrite the existing BP and regenerate the visuals” bp-polish → bp-deck → bp-polish

Do not run all modules merely because they exist. For example, a user asking for an outline should not wait for image generation.

For the state machine and handoff semantics, read references/composition.md.

Shared Workspace Contract

All modules read and write the same portable workspace:

business-plan/
├── brief.md
├── evidence-ledger.md
├── outline.md
├── assets/
├── deck-manifest.md
├── reports/bp-review.md
├── project-bp.pptx
├── project-bp.pdf
└── project-bp-preview.png

Rules:

  • Never recreate a file that already contains accepted user work.
  • Preserve evidence IDs across modules.
  • outline.md is the narrative source of truth.
  • deck-manifest.md records style, slide count, assets, filenames, and render status.
  • reports/bp-review.md records findings and fixes; it must not silently rewrite facts.
  • A later module may send work back to an earlier module when it finds a blocker.

Orchestration Workflow (MANDATORY)

Step 0: Resolve the kit

Resolve this SKILL.md directory as KIT_DIR. Module entrypoints are:

$KIT_DIR/skills/bp-outline/SKILL.md
$KIT_DIR/skills/bp-deck/SKILL.md
$KIT_DIR/skills/bp-polish/SKILL.md

Before executing a selected module, read that module's SKILL.md completely and follow its references. If a standalone installation is being used, resolve its own directory as SKILL_DIR.

Verify every selected module before execution:

  1. read kit.yaml and resolve the declared relative module path inside KIT_DIR;
  2. confirm the selected module's SKILL.md exists;
  3. if it is missing, stop before producing partial output and report: BP Skill Kit installation is incomplete: missing <relative path>;
  4. tell the user to reinstall the self-contained lov-bp package or install the requested standalone module. Do not silently redirect to a sibling directory or improvise a replacement workflow.

Step 1: Inspect context before asking

Inspect the current project, previous BP workspace, supplied deck, conversation, and links. Reuse known audience, financing stage, ask, language, brand, and output path.

Ask at most one compact round of questions only when an answer changes the result. If the user says “Don't ask” “Just do it” “Use the recommended plan”, use these defaults:

  • seed-stage investors who may not understand the technology;
  • 12–15 slides / 8–10 minutes;
  • same language as the user;
  • clean editorial style with one brand color;
  • PPTX + PDF + preview + review report.

Step 2: Run the selected module(s)

For each module:

  1. announce the module and why it is needed;
  2. read its full SKILL.md;
  3. pass the existing workspace instead of starting over;
  4. verify its output contract;
  5. continue to the next module only if requested or implied by the chosen route.

Step 3: Respect the two useful gates

Evidence gate — after bp-outline:

  • product definition is investor-readable;
  • all 12 investor questions are covered;
  • core numbers have sources or are labeled assumptions;
  • no fabricated traction, market, quote, or revenue.

If the user only asked for an outline, stop here. In an interactive full workflow, show the concise page map and ask whether to produce PPT. Skip this pause when the user already requested a complete deck or autonomous execution.

Visual gate — after bp-deck:

  • PPTX/PDF/preview exist and page counts match;
  • every page has one conclusion and a legible proof;
  • logos, images, sources, and QR codes survive final rendering.

Then use bp-polish for the final adversarial review.

Step 4: Handle loop-backs

bp-polish may return one of three verdicts:

  • copy fix → patch the outline and regenerate only affected slides;
  • evidence blocker → return to bp-outline, update the ledger, then regenerate;
  • visual defect → return to bp-deck, regenerate affected slides, and recheck.

Limit automatic correction to three cycles. If a core source remains unavailable, leave an explicit gap rather than guessing.

Step 5: Deliver

Return clickable paths to all artifacts created by the selected route. For a full pipeline, report:

  • outline and evidence ledger;
  • editable PPTX and PDF;
  • full-deck preview;
  • deck manifest;
  • final review report;
  • at most five unresolved decisions or evidence gaps.

Composition Examples

$lov-bp-outline 根据当前仓库和用户访谈写融资大纲

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

$lov-bp-polish ./business-plan/project-bp.pdf --full

$lov-bp 从当前项目材料生成完整种子轮 BP,不要问,按推荐方案

Backward Compatibility

The original commands remain available:

python3 "$KIT_DIR/scripts/init_bp.py" --name "Project" --output ./business-plan
python3 "$KIT_DIR/scripts/audit_bp.py" --input ./business-plan/outline.md

They delegate to the same templates and rubric used by the child skills.

Non-Negotiables

  • Do not conflate “write an outline” with “produce a finished deck”.
  • Do not choose a visual style before the investment narrative is coherent.
  • Do not rewrite facts during visual polishing.
  • Do not force a user through all modules when one module solves the request.
  • Do not finish a full route without PPTX, PDF, preview, and review report.

Runtime context (shared)

Before running, read this Skill package's skill.yaml, provided by the host skill-runtime/v1 context. The field resolution order is: current request, project context, personal Preferences, brand Profile, general defaults.

  • Use only the fields declared in the Manifest; Profile stores public brand facts, Preferences stores personal work preferences.
  • required: true When a field is missing, ask the user one focused question according to the Manifest's question configuration; save the answer only after the user explicitly agrees.
  • Errors provide a copyable context_id, field path, and source; diagnostic content avoids secrets, full private paths, and raw configuration.

General Feedback Loop

When the user provides revision feedback during a Skill-driven task, before continuing with the current artifact you must:

  1. First determine whether the feedback is task-specific(this time only) or reusable(reusable across tasks).
  2. task-specific Only modify the current task, not the Skill.
  3. reusable First determine the scope: for domain rules, first update the corresponding canonical Skill; for rules that apply to all Skills, first update the shared specification.
  4. After completing the rule update, versioning, lint, and distribution verification, then apply the changes to the current task.
  5. reusable The modification invalidates previous “confirm” “continue” “send it” instructions; after completing the current artifact modification and reading it back, you must stop and wait for the user's next instruction, without automatically proceeding to publishing, submitting, or other external writes.