| English | Chinese |
This document defines PPT Master’s long-term product position and the test for adding, retaining, or removing capabilities. It is a product policy, not a feature list or execution manual.
This English file is the canonical policy source. The Chinese version is a synchronized translation, not an independent policy; update both in the same change.
workflows/routing.md remains authoritative for current route selection. This document answers the more fundamental question: whether a proposed direction belongs in PPT Master at all.
PPT Master is an open-source, chat-driven workflow that lets AI reason the argument into shape first, then design and produce a real, editable PowerPoint — not slide images or a thin editable skin. Its defining axis is native depth: author or preserve more of PowerPoint’s own object model, behavior, and reusable structure, release after release.
The input may be a topic, source material, data, design references, brand assets, or an existing .pptx. The main pipeline creates a new deck; other explicit routes and profiles can distill reusable Brand / Style / Layout / Deck workspaces, fill an existing PowerPoint with new content, redesign it, or add native presentation behavior while preserving what their contracts promise to keep.
That native depth is a direction of travel, not a fixed checklist. PPT Master’s north star is to keep converging with PowerPoint itself, narrowing the gap between what an AI can generate and what a skilled user can build by hand. The PowerPoint ↔ SVG Mapping Guide records the current boundary honestly, feature by feature.
In form, PPT Master is a workflow — a “skill” — that runs inside any agent-capable AI tool. It is not a model, a hosted presentation SaaS, or a replacement for PowerPoint. The workflow supplies presentation-specific reasoning, contracts, and quality gates; deterministic tools handle conversion, validation, packaging, and repeatable file operations; the chosen model still sets the quality ceiling.
The primary deliverable is a high-quality PowerPoint draft that the user can present and continue refining, not a sealed final deck. Reusable template workspaces, project sources, design specifications, previews, and validation artifacts are first-class supporting products because they make that deck controllable, reproducible, and reusable.
A useful deck has two layers: the reasoning that makes the argument work, and the PowerPoint construction that makes the result usable. PPT Master owns both.
| Axis | Position | Product consequence |
|---|---|---|
| Logic first | Settle the core message, narrative mode, outline, hierarchy, and evidence before drawing slides | The deck’s structure is reasoned about, not blindly inherited from source order |
| Native depth | Editability is table stakes; the real question is how much of PowerPoint the result actually contains | Author or preserve genuine PowerPoint shapes, text, pictures, charts, tables, slide masters and layouts, notes, transitions, animation, and package behavior where the selected route supports them |
| Honest editability | The output is a draft the user keeps editing, not a flattened image and not a promise of one-shot perfection | Trade-offs between visual fidelity, data-backed objects, cross-app rendering, and preservation stay explicit |
| User control | The workflow, project state, and output belong to the user | Costs remain transparent, data stays local apart from chosen provider calls, and no editor, model, or platform becomes mandatory |
Direct OOXML is too verbose and fragile to serve as the AI’s general visual authoring language, while flat images throw away the native object model. PPT Master therefore combines model-friendly visual authoring with deterministic compilation and direct package operations, choosing the mutation contract that matches the user’s intent.
The project’s job is not merely to write a .pptx. It is to make a general-purpose AI agent competent and reliable at presentation work while preserving the user’s ability to inspect, edit, and own the result.
PPT Master is primarily for people who:
.pptx.PPT Master is not optimized for users who primarily need zero-setup browser generation, instant slides, real-time team co-editing, or a guaranteed final deck with no human judgment or revision.
| Promise | Meaning | Boundary |
|---|---|---|
| Native depth | Author or preserve genuine PowerPoint objects, reusable structure, and presentation behavior where the selected route supports them | Never use whole-slide screenshots as the canonical generated PPTX; unsupported semantics and lossy trade-offs must be explicit |
| Logic before layout | Reason about the message, narrative, page order, and information hierarchy before visual authoring | A route whose contract is to preserve wording or structure must keep that promise instead of silently reframing the deck |
| A high-quality editable draft | Remove most of the work between raw material and a coherent, designed deck that remains open to refinement | Do not promise a perfect one-shot final; the model and user judgment still determine the ceiling |
| Source and intent fidelity | Keep sourced facts, user decisions, design recommendations, and derived artifacts distinguishable | Do not invent evidence or silently reinterpret a preservation request as redesign |
| Transparent, predictable cost | Keep PPT Master free and open source; the user pays only for the AI and optional providers they choose | Do not add proprietary credits, per-seat fees, or a presentation-platform subscription layer |
| Data stays local | Convert, author, validate, and export on the user’s machine | AI model, search, image, and speech providers may still receive the inputs required for calls the user chooses |
| No platform lock-in | Let any agent-capable AI tool and compatible model drive the workflow, and keep outputs portable | Do not promise identical quality across models or identical rendering across presentation applications |
| Engineering reliability | Use explicit routes, preservation contracts, validation gates, read-back checks, and recoverable project state | Do not hide failures behind silent fallbacks or publish an artifact that violates a required gate |
| Quality over speed | Favor deck coherence, native editability, and delivery reliability over the fastest possible output | Improve efficiency where quality remains intact; do not make low-quality parallel generation the default |
The capability model is broader than one generation pipeline, but deliberately narrower than a general office agent.
| Capability domain | Responsibility |
|---|---|
| Presentation reasoning | Turn a topic or source bundle into an audience-aware message, narrative mode, outline, page plan, and explicit design direction |
| Native presentation authoring | Create new slide visuals and compile them into a real, natively editable PowerPoint deck |
| Reusable presentation design | Distill, create, combine, validate, and apply Brand, Style, Layout, and Deck workspaces |
| Existing-deck adaptation | Redesign an existing deck, fill native slide shells with new content, or add native behaviors under distinct preservation contracts |
| PowerPoint expression | Use images, diagrams, charts, tables, formulas, notes, narration, transitions, and animation when they serve the communication goal |
| Review and delivery | Preview, inspect, validate, repair, export, read back, and retain enough local project state for later refinement or re-export |
These are product responsibilities, not a mandate to expose every responsibility as a top-level route or a separate workflow file. Routes exist only when inputs, mutation rules, invariants, or output lifecycles genuinely differ.
PPT Master may integrate general-purpose capabilities without becoming a general-purpose platform for them.
| Area | PPT Master owns | PPT Master does not own |
|---|---|---|
| Research | Decide what evidence the deck needs, preserve provenance, and turn findings into presentation content | A general web-research engine for tasks unrelated to presentations |
| Images | Decide whether an image is needed and own its role, style, source, placement, provenance, and readiness | A universal image-generation or photo-management platform |
| Audio | Own speaker notes, voice choice in presentation context, per-slide narration, timing, and PowerPoint embedding | A general audio studio, podcast platform, or speech-provider marketplace |
| Data visualization | Choose the visual form, preserve values, validate geometry, and expose the editability / fidelity trade-off | A general business-intelligence or spreadsheet product |
| Templates and brands | Define reusable presentation identity, Master / Layout structure, slots, assets, and composition contracts | Recover historical design intent that is absent from the source file |
| PowerPoint editing | Own presentation-specific generation, filling, redesign, and scoped native enhancement | Replace the complete PowerPoint editing surface or support arbitrary OOXML mutation |
Provider diversity may be bundled to preserve openness and practical usability, but provider-specific behavior stays behind stable integration boundaries. The presentation workflow owns selection and output semantics; no individual provider should redefine the product boundary.
The technical architecture serves the positioning; it is not the positioning itself.
The implementation may evolve, but these invariants remain stable:
PPT Master is not intended to become:
These non-goals do not forbid presentation-specific use of research, images, audio, native objects, or existing decks. They prevent supporting infrastructure from becoming an independent product with a different user promise.
Evaluate every proposed capability in this order:
| Decision | Use when |
|---|---|
| Add or retain as core | The capability directly advances the presentation job or strengthens native depth, reasoning, user control, or reliability, and requires presentation-specific contracts or validation |
| Retain as an integrated extension | The capability is optional, but its planning and output semantics are specific to presentations |
| Place behind a stable integration boundary | The underlying service is general-purpose or provider-specific, while PPT Master owns the presentation-specific selection and output contract |
| Move to repository tooling | The capability maintains the repository, examples, installation, or contributor workflow rather than creating presentations |
| Retire | It duplicates another authority, has no active consumer, makes an unverifiable promise, or adds more maintenance than presentation value |
The number of files or workflows is not itself a reason to add or remove a capability. The deciding factor is whether ownership and product value are clear.
A successful PPT Master session should look like this:
The user gives an AI agent a topic, source material, design references, a reusable template, or an existing PowerPoint. The AI reasons the argument into shape before it designs, the user confirms the choices that matter, and the workflow returns a coherent, validated PowerPoint with deep native editability, plus enough local project state to present, refine, reuse, or re-export it.
Future work should improve this outcome in the following priority order:
| Document | Responsibility |
|---|---|
what-is-ppt.md |
Definition of the presentation medium, user jobs, lifecycle, native object model, templates, and quality layers; the upstream premise for this document |
| This document | Long-term product position, promises, capability boundary, and admission test |
why-ppt-master.md |
User-facing differentiation and reasons to choose the project |
technical-design.md |
Current architecture and implementation invariants |
workflows/routing.md |
Current executable route selection |
roadmap.md |
Shipped work, active priorities, and explicitly deferred directions |