proposal-ppt

Proposal PPT

Core value: the winning thesis and proof logic — *why this proposal should win*. Premium design is the gate that gets the deck read, not the reason it wins. Optimize for the argument first; treat visual quality as a pass/fail gate, not the goal.

Use this skill to turn client briefs, tender files, research, brand materials, budgets, cases, and execution plans into a commercial proposal package. When the runtime has PPTX support, the package includes:

• •an editable .pptx
• •a same-name presenter script .md
• •a missing-information list when inputs are incomplete

The goal is not to decorate information. The goal is to help the client decide why this proposal should win: it understands the business problem, makes a clear judgment, proves execution ability, explains budget boundaries, and controls risk.

Required Output

When creating a proposal in a runtime with PPTX support, produce both deliverables unless the user explicitly asks for only one:

1. *.pptx with the full proposal deck.
2. *.md with presenter script. Include presentation logic, slide-by-slide talking points, transition notes, and exact speaker script. Do not put long oral explanation into slide bodies.

If PPTX support is unavailable, downgrade using references/runtime-compatibility.md and state the limitation clearly.

If information is missing, continue with a working draft and mark unknowns as 待补充, 待确认, 暂无公开数据, or 需客户确认. Do not invent data, results, awards, client cases, pricing, permissions, or platform rules.

Reference Loading

Load only the references needed for the current task:

• •For guided execution modes, stage gates, and user-option handling, read references/workflow.md.
• •For story structure and proposal type routing, read references/proposal-routes.md.
• •For page planning and proof objects, read references/page-types.md.
• •For slide rhythm, whitespace balance, layout density, and page-to-page pacing, read references/layout-rhythm.md.
• •For visual direction, palette, typography, and PPT template use, read references/visual-system.md.
• •For default high-taste palette presets when no client VI is provided, read references/palette-library.md.
• •For reusable public style-template families, style DNA contracts, and three-page sample gates, read references/style-template-strategy.md.
• •For the flow-based HTML template engine and per-family theme CSS used to build reliable slide demos, read templates/README.md and use templates/engine.css plus a family theme.
• •For style-rich proposal routes and component-level style transformations, read references/style-systems.md.
• •For AI-generated images, user assets, HTML/SVG-to-PPT hybrid backgrounds, and visual asset QA, read references/asset-pipeline.md.
• •For free/commercial-safe font pairing and fallbacks, read references/font-system.md.
• •For final file and script format, read references/output-contract.md.
• •For runtime compatibility, PPTX backend requirements, and fallback modes, read references/runtime-compatibility.md.
• •For delivery QA and failure modes, read references/quality-check.md.
• •For audited practices borrowed from the frontend-slides project (visual discovery, fixed 16:9 stage, density modes), read references/frontend-slides-audit.md.

Use assets/minimal-proposal-template.pptx only as a fallback visual asset when no client VI, reference deck, or stronger design direction is provided.

Operating Modes

Default to guided mode unless the user explicitly asks to generate everything directly.

• •guided: Use staged checkpoints. First return brief audit, winning thesis, chapter structure, page plan, proof objects, and visual direction for confirmation. After confirmation, build the PPTX and script.
• •auto: If the user says to proceed directly or is under time pressure, make reasonable assumptions, mark unknowns as 待确认, and produce the full .pptx plus .md when a PPTX backend is available. Otherwise use the best fallback mode and state the limitation.
• •edit: If the user provides an existing PPTX, audit and modify the deck instead of rebuilding from scratch unless the user asks for a rebuild.
• •audit: If the user asks for review only, do not generate a new deck. Return findings, page-level issues, and revision recommendations.

In guided mode, ask only high-impact routing questions. Do not block on details that can be marked 待确认.

Runtime Requirements

This skill is not itself a PowerPoint rendering engine. A finished editable .pptx requires a host runtime with a presentation backend, such as a native presentations skill/tool, python-pptx, pptxgenjs, an Office-compatible exporter, PowerPoint/Keynote/LibreOffice automation, or an equivalent runtime-specific tool.

At the start of a PPTX creation task, identify the available backend:

• •PPTX creation/editing backend
• •preview/render backend
• •image-generation backend, if needed
• •fallback mode if the backend is missing

If the runtime cannot create an editable .pptx, downgrade honestly to blueprint-only, copy-and-script, template-spec, or html-demo mode from references/runtime-compatibility.md. Do not claim a PowerPoint deck was delivered when only markdown, HTML, images, or a PDF exists.

Workflow

Follow references/workflow.md for the full stage-gate process. The high-level workflow is:

1. Start and route the work

- Identify mode, proposal route, page-depth range, visual source, and required deliverables. - If the user has not specified these, infer defaults and show them in the first checkpoint.

1. Collect and audit inputs

- Read the real brief, tender, deck, research, brand assets, budget, cases, and chat notes the user provides. - Separate confirmed facts from assumptions. - Extract client goal, audience, decision criteria, scope, timeline, budget, deliverables, KPI, exclusions, and approval risks.

1. Define the winning thesis

- Write one sentence explaining why this proposal should be selected. - Define 3-5 client evaluation standards such as business fit, strategy judgment, execution certainty, proof, budget clarity, team response, and risk control.

1. Select a proposal route

- Pick the closest route from references/proposal-routes.md. - Use the route to decide chapter order, proof emphasis, visual style, and required page types. - Do not force every deck into the same structure.

1. Select a template family (visible checkpoint)

- When no client VI, reference deck, or approved strong-style direction exists, run the Template Selection Gate from references/workflow.md (Stage 2.5): show the four public families ranked by fit, recommend one tied to the winning thesis, and let the user confirm — or show the three-page sample of the recommended family before scaling. - This is an explicit, user-visible decision point. Do not skip silently into slide copy on an unconfirmed family in guided mode.

1. Create the page plan before authoring slides

- For every slide, specify: slide title, page purpose, key message, proof object, visual form, required source, and presenter-script intent. - Each slide must answer one commercial question. - Each slide title should be a conclusion sentence, not a vague noun.

1. Write slide copy

- Slides contain judgment, structure, proof, and key examples only. - Speaker notes / script contain oral reasoning and transitions. - Keep bullets short and action-oriented. - Remove internal wording such as 赢标逻辑, 客户透露, 内部判断, 释标会之后, unless the user explicitly wants an internal working draft.

1. Build or edit the PPTX

- If the user provides a template/reference deck, follow it as the visual source. - If the client has VI, use client brand colors and typography first. - If no visual source exists, use references/visual-system.md and the minimal template as fallback. - If a rich style is requested or no client VI exists, run the Style DNA Gate in references/style-template-strategy.md before building the deck. - Use references/style-systems.md for component-level style transformations after the route is chosen. - If a rich style has no approved reference deck, create or recommend the three-page style sample set before scaling: cover/big idea, proof/mechanism, and dense business page. - When creating a PowerPoint deck, use the active runtime's PPTX backend and follow references/runtime-compatibility.md, including render/overlap QA where available.

1. Write the presenter script

- The .md must be usable by a presenter, not just a slide outline. - For each slide, include slide objective, why it appears here, exact talk track, transition sentence, and notes about numbers or claims that need confirmation.

1. Run final QA

- Use references/quality-check.md. - Verify story continuity, slide-title quality, proof objects, source labels, visual alignment, text size, budget boundaries, KPI logic, and risk controls. - When a .pptx was produced, run scripts/audit_proposal_pptx.py <deck.pptx> --script <script.md> and resolve any errors before claiming delivery. - Do not claim the deck is ready until the PPTX and script are both present and checked.

Hard Rules

• •Do not fabricate data, awards, clients, case outcomes, screenshots, platform permissions, or third-party endorsements.
• •Do not use customer-sensitive examples in reusable templates or public skill assets.
• •Do not default to a service-list deck. Start from the client problem and decision criteria.
• •Do not let budget pages hide exclusions or uncertain costs in unreadable footnotes.
• •Do not make a PPT that requires the presenter to explain missing logic verbally. The visual argument must stand on its own.
• •Do not leave large empty placeholder frames or a visually dead lower third. If evidence is missing, mark the item compactly as 待确认 and rebalance the layout.
• •Do not make every slide dense. Insert deliberate breathing slides, section dividers, big-idea pages, or visual proof pages every 3-5 slides.
• •Do not treat a style as only a palette. If a rich style is chosen, adapt assets, typography, component language, proof objects, and page-type boundaries.
• •Do not approve a strong style that only works on the cover. It must also handle at least one proof/mechanism page and one dense business page, or be restricted to expressive pages.
• •Do not use crude primitive shapes, oversized circles, generic cards, or decorative dots as substitutes for real style grammar.
• •Do not publish or reuse a style-rich template/demo unless full-size slides have been visually reviewed, not only contact-sheet checked.
• •Do not scale a new visual style to a full deck before the cover/big-idea, strategy/mechanism, and proof-dense sample pages pass full-size review.
• •Do not present AI-generated visuals as real client proof. Mark them as conceptual when relevant.
• •Do not insert the skill author's company information into user decks unless the user explicitly asks to present under that company identity.
• •Do not hide runtime limitations. If the current agent cannot generate, render, or open PPTX files, say so and deliver the best fallback package instead.
• •Do not claim a deck passed QA when a .pptx exists without running scripts/audit_proposal_pptx.py. Resolve reported errors (invalid package, placeholder leakage, missing notes, slide/script mismatch) before declaring delivery.
• •Do not declare a visual page or style demo "done" by self-judgment alone. Agents cannot reliably verify rendered line-wrapping, optical overlap, or aesthetic balance. For any HTML style demo, run scripts/audit_html_demo.mjs to catch element overlap and boundary overflow; for any .pptx, run scripts/audit_proposal_pptx.py to catch text-box overflow and shape overlap. Then require a human visual review before treating the page as finished. An undetected ragged wrap or two overlapping text boxes read as a broken deck to a non-technical viewer and count as a delivery defect, not a cosmetic note.