deck

# PowerPoint decks ## Usage ```text /deck roadmap <area> [period] /deck prd <area> <feature> /deck qbr <area> [period] /deck pitch <area> <feature> /deck custom <title> ``` Use `python-pptx` and the neutral starter at `context/templates/deck_roadmap_template.py`. Read the complete source artifacts before outlining slides. ## Narrative - Give each slide one decision-relevant claim. - Start with the user problem, evidence, or result rather than a category definition. - Explain outcomes and trade-offs, not a list of features. - Cite or footnote claims that depend on external evidence. - Label proposed, directional, unverified, and shipped content accurately. - End with the decision, risk, or next action required from the audience. ## Common deck shapes ### Roadmap Problem and period outcome, themes, initiatives, measures, timeline or sequence, trade-offs, dependencies, and risks. ### PRD summary User problem, evidence, proposed outcome, key journeys, requirements, success measures, non-goals, and open decisions. ### QBR Outcomes versus targets, verified shipped work, work not completed and why, customer or user evidence, learnings, and next-period decisions. ### Pitch Problem, current workaround, evidence, proposed experience, alternatives, validation, risks, investment, and explicit ask. ## Visual system - Use 16:9 slides unless the user requests another format. - Keep body text readable in the final presentation; shorten content instead of shrinking it excessively. - Use a neutral theme by default and read brand values from user-provided assets or configuration. - Prefer simple diagrams, timelines, and tables when they clarify relationships. - Do not use decorative charts or fabricated data. - Add speaker notes when the user needs a delivery narrative. ## Generate and verify 1. Create an outline and map every claim to its source. 2. Generate a native `.pptx` in the relevant project or roadmap directory. 3. Render slides to images or PDF. 4. Inspect every slide for overflow, overlap, clipping, contrast, legibility, and unsupported claims. 5. Revise and render again until the deck passes visual and content checks. Installing dependencies or publishing the deck externally requires the normal user authorization. A successful script run is not proof of a usable deck; visual inspection is required.