# PPTX Deck Creation Builder

Create editable PowerPoint decks through a spec-first workflow. Treat the final inch-based JSON `layout_tree` as the source of truth. Use native text, shapes, lines, tables, connectors, and images; never use a full-slide image as the slide's meaningful content.

## Non-negotiable rules

- Keep reference decks read-only. Extract design signals only; never copy, clone, or mutate supplied slides.
- Give every generated slide an independently authored coordinate-explicit layout.
- Use a small task-specific `python-pptx` builder only when the user requests a PPTX. Do not add a bundled renderer or helper framework.
- Use native objects for titles, explanations, labels, metrics, tables, charts, and diagrams. Images are supporting visuals only.
- Do not invent missing brand, source, license, or accessibility facts. State the gap and request a decision.
- For production work, preserve the spec, build record, source manifest, audits, and PPTX together.

## Workflow

1. Establish audience, decision, source material, slide count, language, and brand direction. If no narrative framework is supplied, ask the user to choose one.
2. Prepare the narrative, source inventory, and design context.
3. If a reference deck is supplied, analyze it read-only. Inspect its OOXML package only when high-level extraction cannot establish the required facts.
4. Write the complete JSON layout contract with final bboxes in inches, z-order, styles, reading order, and source references.
5. Select only approved supporting visuals. Preserve aspect ratio, provenance, and alt text.
6. Build with a per-deck script if required, then audit the deck. Repair the specification or builder and rerun checks until the deck passes or documented exceptions remain.

## Delivery

Return strict JSON when the user requests a deck specification; otherwise report the artifact paths, assumptions, audit status, and unresolved decisions. Use direct, plain business English and avoid placeholder content.