tribgames/mixdog/pptx

PPTX authoring (office tool: HTML or pptxgenjs)

Use office to create, redesign, and review PowerPoint decks. Read this guide before the first deck operation. A new deck is written as HTML slides by default (references/html.md); the pptxgenjs script and its kit remain the second route.

The model designs; the runtime converts and measures. Write HTML/CSS for the actual content, audience, and use, not to fill a predefined layout. Facts, safety, file integrity, legibility, and current rendered review remain mandatory. Palette, typography, spacing, motifs, density, repetition, and layout recipes in the references are optional examples, not requirements or acceptance criteria. Neither a named concept nor a style score proves quality. Existing accessible product assets and user materials precede generated imagery; the runtime has no photo library.

0. Route by task

Prerequisites: the Office capability (metadata.requires) — its portable backend needs no installed PowerPoint, and Office on Windows is used in the background when present; fonts that render reliably for the recipient; a signed-in media lane only for generated pictures; an explicit --provider and --model for the reviewer and page-QC scripts, which reuse the existing sign-in and never ask for credentials. Run bundled scripts with ${MIXDOG_SKILL_NODE} (on PATH in any shell), never plain node.

1. Load routing

2. Workflow

1. Read the HTML contract and writing guide; load other references only for the decisions they help. Identify supplied brand assets, product views, and reference material. For a product pitch, prefer the real artifact that demonstrates the benefit to an interchangeable diagram. When an illustration is needed and authorized but no supplied asset covers it, load the image skill and check its lanes; do not assume generation is available or add imagery merely because it is. Without it, choose a faithful text or drawn explanation and disclose any unmet image requirement. Done when selected assets and their sources are known.
2. Ground: with source material, read it and write the fact sheet (each figure with its page or cell) before any outline; then the outline as assertion titles that read as one argument in sequence (references/writing.md for the sentence and notation rules). Done when every figure the outline will show has a fact line with a locator (§3).

Hard rule — copy is rewritten, never reinvented: slide copy is condensed from the source in the deck's language with the source's own vocabulary; entity names, product names, figures, and abbreviations stay in their original form; a figure the source does not contain is not on the slide. → runtime number_without_fact for figures; wording → manual

1. Direct: choose the reading order, type, palette, density, and structure for this request. Supplied templates and brand requirements take precedence. A concept: line is optional free text, not a catalogue selection. Related deliverables share facts and any requested identity, not necessarily layouts. Compare representative rendered pages only when it resolves a real uncertainty; an existing approved direction needs no contest. Done when the design has a reason grounded in the content and reader.
2. Plan each slide's purpose, relationships, composition, and carriers in the brief (§3). Describe the layout in ordinary words, without selecting a recipe. Use as much space and repetition as the content needs: a comparison series may repeat a layout, a statement may be sparse, and an evidence page may be dense. Preserve the facts and qualifications; split content when it cannot remain readable rather than shrinking or deleting evidence. Done when every slide has a plan line describing what it actually carries.
3. Write the source. HTML route: the brief (§3) as a <!-- BRIEF --> comment, then one <section class="slide"> per page, written after the design pass of references/html.md §8. Script route: references/script.md — the brief as a comment block, then deck({ … style … }) with the brief's style id, then the slides, each measured down before it is drawn; the runtime runs the kit first, so the script never pastes a helper.
4. office action:'author' path:<deck.pptx> script:<html or pptxgenjs script> (a source that opens with < is read as HTML; overwrite:true when re-authoring the same path) writes the file, opens the session, and returns the rendered pages and contact sheet, the composition receipt, and the audit (references/audit.md reads all three).

Default — measure, then render the same session: author render:false returns the receipt and the audit without pixels; qa render:false adds the design read (theme, plan promises, facts). When both are clean, render on that session returns the page images (images[]), the contactSheet, the receipt, and reviewToken without rewriting the deck. Re-author only when the script changes; a repeated background author keeps the owned PowerPoint process and replaces its document. Hard rule — a failing audit is answered in the same turn: fix every target the audit lists by re-authoring the script (or batch on the reported shapes), then read the audit that call returns; only audit.status: 'pass' counts as done. The runtime counts the rounds: after two failing fix rounds the residue is reported with the deck, never hidden by a third pass. → runtime audit

1. Open every persisted page image at readable size and inspect it against §5 and its intended message; the contact sheet checks sequence, not local alignment. For long decks returned as sheets, request pages in batches of at most 12 for detail. A promised comparison or explanation must be visible, not merely mentioned in a paragraph. Read the receipt as a diagnostic, not an object quota. Fix defects in the script; one or two loops is normal.

Bounded refinement: fix factual and material visual defects before taste edits. Keep each pass focused on the highest-impact changes. After two unsuccessful corrections of the same defect, preserve the last valid artifact and report the limitation rather than cycling for a higher score. This limit is not permission to call an inadequate design complete. If an asset fails, repair or replace it; if it is removed, recompose the space it owned.

1. Page QC (new decks; skip for a one-page edit): after the measured audit, qa render:false, and the first render, check overflow, clipping, collision, canvas edge, contrast, and distortion; never redesign, reword, add, or delete. In Solo, Lead reviews directly. Only with workflow-approved delegation, use the runner below: each fresh fixer sees one page's image, inventory, and measured defects, uses only office, and edits a working copy. The runner adopts it only if defects did not grow and no other page changed. For this delegated route, close the session before running:

``text ${MIXDOG_SKILL_NODE} "${MIXDOG_SKILL_DIR}/scripts/qc-pages.mjs" <deck.pptx> --provider <provider> --model <model> --output qc-report.json [--pages 1-12] [--no-vision] ` Provider and model are explicit, as for the reviewer; read the report with references/audit.md §5. A page whose run never replied is not a page that passed: execution_failed counts into failed, turns ok false, and exits the command, so rerun those pages before delivery rather than reading the report as clean. Then open the deck again and render it: the QC edits invalidate the earlier reviewToken, and a reopened session no longer carries the brief, which is why the brief read (qa render:false`) comes before this step.