ppt-script-authoring

Deck authoring

You design the deck and you build it, by writing a python-pptx program that ppt_build runs. Every page is yours: the grid, the type scale, the palette, the page furniture, where a figure sits and how large. What refuses a deck and what only reports is in §12.

1. Define the communication job

Infer the audience, the deck's job, the outcome you want, the central takeaway and the evidence that supports it. Build a cumulative argument rather than an inventory of topics: each content page performs one narrative job and makes one primary claim.

Write audience-facing titles that state the point. Open with the context, question or stakes that make the deck worth sitting through. Close by resolving that opening — a decision, an implication, a next question — on the last content page. The template's closing page ends the deck after it, as its cover opens it: both are the house frame and carry no argument of their own.

Pack the evidence before allocating pages. A page carries one claim and the developed support that claim takes, and what makes the support developed is that it is more than one kind of thing: evidence from the source, a mechanism or a comparison, an implication or a constraint. Nothing counts the kinds, and how much copy a page ends up with is measured rather than allocated (§2). If the evidence cannot support a complete argument, merge the page rather than enlarging fragments.

The language, the audience and the length are the user's, and they are asked for rather than inferred. ppt_prepare reads what the request already states and hands back the rest as questions under ask_user. Put them to the user with the ask_user tool, all of them in one call, each with the option you would recommend marked. The answer comes back through the host: in a direct chat the user answers; in a delegated run the host answers what the delegating conversation already settled and puts the rest to the user. An answer that is empty, or that says the question was not sent, means nobody is attached to this run: then take the option you marked recommended -- the request's own scope, the materials' language, the length its kind of deck usually has -- and record it with ppt_brief as the assumption it is, so the deck says what it assumed. Ask once: a question nobody answered is not answered by asking it again, and a run that asks a question a turn spends a turn on each. The length and the language are then measured against the finished file and both refuse the deck (§12), so record what the user said rather than what you inferred. The audience is not measured; it is the room you judge the deck for when you look at the renders (§10).