lov-bp-polish

BP Polish

Improve an existing BP without silently changing its business facts. This skill can be used before deck production, after rendering, or in a correction loop.

Modes

Mode	Input	Focus
content	Outline / Markdown	Product definition, story, copy, page rhythm
evidence	Outline + ledger/sources	Claims, metrics, TAM/SAM/SOM, assumptions
visual	PPTX/PDF/slide images	Hierarchy, charts, layout, branding, QR codes
full	Any complete BP workspace	All dimensions + correction loop

Infer the smallest useful mode from the request. Do not require a PDF when the user only wants the outline reviewed.

Output Contract

business-plan/
├── reports/bp-review.md
├── outline.md                 # patched only when authorized by the request
├── deck-manifest.md           # updated for visual fixes
└── revised slide/deck assets  # only affected artifacts

Workflow (MANDATORY)

Step 0: Resolve source and mode

Resolve this SKILL.md directory as SKILL_DIR. Inspect the supplied source and any existing BP workspace. Reuse audience, stage, style, and evidence definitions.

If multiple review modes are plausible, prefill from the user's wording. Ask one compact question only when the choice materially changes the work. "不专业" defaults to full; "The text is too technical" defaults to content; "The chart doesn't look good" defaults to visual.

Read references/review-rubric.md, references/charts-and-visuals.md, and references/user-config.md as relevant.

Step 1: Run deterministic outline audit

When an outline exists:

python3 "$SKILL_DIR/scripts/audit_bp.py" \
  --input ./business-plan/outline.md \
  --output ./business-plan/reports/bp-review.md

Use --strict before final delivery. The script checks structure and evidence hygiene; it does not replace investor judgment or visual inspection.

Step 2: Review as four adversaries

1. Non-technical investor — can the product be repeated after ten seconds?
2. Category expert — which product/competition claims are naive or imprecise?
3. Skeptical partner — which core claims lack proof or overstate traction?
4. Design director — where does layout reduce trust or distort meaning?

For every issue record slide, severity, why it matters, and exact revision.

Step 3: Protect facts during polishing

• Never make numbers “look better”.
• Never turn an assumption into a fact.
• Never invent a customer quote or testimonial.
• Never widen TAM without a buyer and price bridge.
• Never change a product boundary solely to improve the story.

If a revision needs new evidence, mark an evidence blocker and return it to lov-bp-outline.

Step 4: Inspect rendered slides

For visual/full mode, create or inspect a contact sheet and every page at normal presentation size. Check:

• one conclusion per page;
• body text at least 20 pt;
• optical alignment and whitespace;
• chart axes, units, legends, dates, and sources;
• genuine, legible product screenshots;
• unstretched images and logos;
• no clipped text or broken CJK;
• QR codes decoded from final rendered pages;
• clean cover and one-action final page;
• matching PPTX/PDF page counts and normalized filenames.

Step 5: Apply targeted fixes

Classify each fix:

• copy fix — patch outline and regenerate affected slides;
• evidence blocker — update ledger/source before rewriting;
• visual defect — change layout/style or regenerate affected slides only.

Do not regenerate the whole deck for a one-page issue. Repeat audit → fix → audit for at most three cycles.

Step 6: Deliver the report

Lead with verdict and score, then blockers, page-level findings, evidence gaps, visual QA, and delivery status. Use assets/templates/bp-review.md.

Target: 85+ with no blocker. A high numeric score never overrides fabricated data, missing financing ask, broken source, unreadable slide, or invalid QR code.

Runtime context (shared)

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

• Use only 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 per 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 raises revision feedback during a Skill-driven task, the following must be executed before continuing with the current artifact:

1. First determine whether the feedback is task-specific(this time only) or reusable(reusable across tasks).
2. task-specific Modify only the current task; do not change the Skill.
3. reusable First determine the scope: domain rules update the corresponding canonical Skill first; rules that apply to all Skills update the shared specification first.
4. After completing rule updates, versioning, lint, and distribution verification, then apply the changes to the current task.
5. reusable A modification invalidates previous "confirm," "continue," and "send it" approvals; after completing the current artifact modification and read-back, you must stop and wait for the user's next instruction, without automatically proceeding to publish, commit, or any other external write.