ppt-review

# PPT Review

Read this skill only after current `office_review` structural output and relevant rendered images exist. Do not use source code, a tool success flag, or the first-slide preview as a substitute for deck evidence.

## Evidence set

- Run `office_review` with `action:"check_and_render"` after every create or edit. Invalid OpenXML is a blocker, not a warning.
- For a new deck, render every slide. For an existing deck, render every changed slide plus the cover, a representative unchanged content slide, and any slide whose theme, master, or shared element could be affected. Every render intended as current visual-defect evidence must set `analysis_mode:"quality_review"`; ordinary source understanding keeps the default `understand` mode.
- After a repair affects multiple pages, request them together in one `office_review` call with `action:"check_and_render"`, a `pages` array, and `analysis_mode:"quality_review"`. One collected image set lets managed visual preprocessing analyze the affected pages as a batch. If one render fails after a valid check, retry only that page with `action:"render"` rather than rerendering the successful set.
- Rendered image blocks are transient after the next assistant response. In the first response that sees each collected `quality_review` image set, write one concise plain-language evidence sentence before any follow-up tool calls: name the reviewed pages, concrete pass/defect observations, and the next action. This sentence is the durable visual-review state for later tool rounds and compaction. When exact edit paths are needed, request the targeted `office_read` calls together in that same response; do not rerender an unchanged `artifact_revision` merely to recover forgotten pixels.
- Use the returned `artifact_revision` to distinguish current from stale check/render evidence and `image_revision` to compare rerenders. If an edit claimed to repair a visible defect but the affected page keeps the same `image_revision`, do not claim a visual repair: verify that the edited artifact revision was rendered, then make a supported layout/content change or retain the finding as unresolved.
- If rendering is unavailable, mark visual checks `not_run`; do not infer a pass from structural validity.

## Two review layers

Review every required render at slide level, then review the contact-sheet-like sequence as a whole. A slide can be individually tidy while the deck still fails because every page repeats the same card grid or the visual language drifts.

### Per-slide review checklist

Mark each item `PASS`, `WARNING`, or `BLOCKER` and attach a concrete observation from the current render. Do not derive a result from intent, source code, or self-description.

- `intent_fit`: the visual form makes the slide's takeaway easier to understand;
- `hierarchy`: the first, second, and supporting reading order is unmistakable;
- `composition`: focal point, balance, alignment, whitespace, and safe margins work together;
- `typography`: type scale, line length, wrapping, density, and CJK rendering are presentation-legible;
- `color_contrast`: palette is coherent and primary audience-facing text is readable in the current render;
- `visual_usefulness`: chart, diagram, table, or image explains rather than decorates.

For every chart, also verify from the current render that each visible value label
maps to one data point, appears only once, and does not collide with another label,
axis, or series mark. Duplicated manual and native labels, label-to-point
misalignment, and collisions are concrete repair defects even when the underlying
series values are correct.

When a visual reference exists, also record `reference_fit`: the result follows the declared `keep` and `adapt` traits without copying `do_not_copy` material. Do not mark an intentional, authorized deviation as a defect merely because it differs from an autonomous default.

Checklist results are diagnostic evidence used to find the weakest pages and prioritize repairs. Use `BLOCKER` only for a concrete delivery failure such as clipped or unreadable primary content, an unsupported or materially false claim, invalid structure, or a requested reference/template requirement that was not met. Otherwise classify a supported defect as `WARNING` and improve it when a proportionate edit is available. Never invent a numeric aesthetic score or average.

### Whole-deck review

- layout rhythm supports the narrative; there is no numeric family minimum or repetition ceiling;
- repeated geometry is coherent when it supports a series, comparison, recurring case, or reference-template rhythm, and mechanical when it obscures different communication jobs;
- density changes are intentional when useful, without requiring a prescribed sparse/dense alternation;
- background modes may vary when they serve a section, slide role, or semantic
  emphasis. Unexplained mechanical dark/light alternation or an isolated theme
  switch is a `WARNING` to record and repair, not an automatic blocker;
- equal-card grids communicate genuine parallelism rather than appearing by default;
- cover, opening, evidence, decision, and close feel intentionally designed for their roles;
- charts, image treatments, sources, page numbers, and recurring elements stay consistent.

When the same weakness recurs across multiple slides or a shared component, repair the underlying token, component, or layout pattern rather than nudging each page independently. After repair, rerender every affected slide and repeat the whole-deck pass.

## Three-dimensional review

Use the checklist and whole-deck evidence to complete the broader quality review below.

For a review-only request, make the report independently actionable. Cover every
reviewed slide and label each finding `Content`, `Design`, or `Coherence` plus
`BLOCKER`, `WARNING`, or `PASS`. Each non-pass finding must name the current
evidence, user impact, and smallest supported repair. Across the report, include
at least