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 one explicit evidence-based result for each of the three dimensions; do not collapse them into generic deck-level praise or a list of unlabelled suggestions.

Content

• The deck answers the brief and ends with the intended decision, action, or learning outcome.
• Each slide has one dominant takeaway and all supporting copy serves it.
• Claims, values, dates, labels, units, and sources match the evidence boundary.
• Explicit user-supplied slide titles, labels, and page order match the current output verbatim. A missing, renamed, synonymized, or reordered contracted string is a BLOCKER, even when the substitute reads more editorially.
• Supplied content has not been expanded into invented source facts merely to fill a layout; missing copy remains a neutral placeholder or visibly labeled draft rather than being presented as user-provided material.
• Placeholders, template residue, accidentally duplicated or overlapping text, broken glyphs, and unsupported promises are absent. Repeated wording in intentional, distinct roles is not a defect by itself.
• Tables and simple data visuals preserve the supplied category/series mapping and status labels, remain legible, use one non-colliding value-label system, and include the relevant period label, unit, and source.

Design

• No primary content is clipped, overflowing, obscured, outside safe margins, or too small to present.
• Alignment, spacing, hierarchy, contrast, image crop, and text wrapping are intentional.
• The locked palette, typography roles, grid, and visual grammar remain consistent.
• When references exist, the result respects their declared role and reuse boundary; when they do not, the autonomous visual direction remains coherent and fully designed.
• Images are sufficiently clear and not stretched; raster content does not replace editable text or diagrams.
• Density matches the brief, and decoration does not compete with the message.

Coherence

• Slide order forms an understandable argument, not a set of independent pages.
• Titles, terminology, numbers, tense, voice, source style, and layout rhythm are consistent.
• Transitions between sections are clear, and repeated information is deliberate.
• Cover, opening, evidence, decision/close, and appendix roles match the outline.

Findings and repair

Classify each finding:

• BLOCKER: invalid OpenXML, missing/blank required slide, clipped or unreadable primary content, unresolved placeholder/template text, a material unsupported claim, or a deliverable that is not an editable PPTX when one was requested.
• WARNING: visible but non-blocking density, hierarchy, consistency, image-quality, source-placement, or target-viewer risk.
• PASS: supported by named structural or render evidence.

Repair blockers and straightforward warnings with the smallest edit. Before edit_office, use office_read to get the exact target path, then call edit_office with preview:false. Its automatic first-page preview must not run ahead of structural validation or substitute for current review evidence. Consolidate all known defects into one edit batch where possible before requesting new render evidence. After each repair batch, call office_review with action:"check_and_render", rerendering only affected slides at a new artifact_revision; never rerender an unchanged page/revision. Continue only while current evidence identifies a concrete blocker or a proportionate repair. Stop when only non-blocking warnings remain or another pass would not materially improve the user-facing deck, and disclose those warnings. If a blocker remains unresolved, do not publish the deck as complete; preserve and report the last structurally valid artifact when useful and label the remaining boundary. Existing-deck edit work may continue with another safe, evidence-based pass when it can resolve a remaining blocker without changing the authorized scope.

Do not repair by hiding content, shrinking all text globally, flattening the page, removing source labels, or changing the locked narrative without evidence that the plan itself was wrong.

Delivery gate

For a REVIEW route, the requested deliverable is the review report in the assistant message. Do not call create_pptx, edit_office, or publish_outputs, do not create a review copy, and leave the source byte-identical. Do not create or update a runtime execution plan for review-only work; deliver the evidence-based report directly after inspection so plan bookkeeping cannot suppress it. The PPTX publication rules below apply only to CREATE and EDIT routes.

Publish only when:

• OpenXML validation passes;
• every required render was reviewed or unavailable checks are explicitly disclosed;
• no blocker remains;
• the final whole-deck review records concrete observations and any remaining non-blocking warnings;
• the final path is the validated candidate, not an earlier draft or backup.

Do not call publish_outputs until the last current-render review and its quality record are complete. If any edit or render-based review happens after publication, treat the published result as stale and publish the validated candidate again only after all gates pass.

Call publish_outputs with only that final .pptx. The handoff names the path, slide count, edits or produced scope, plain-language content/design/flow result, checks actually run, repair passes, source limitations, unsupported PowerPoint features, and any target-viewer review still needed. Do not expose the internal route or depth codes in the handoff.

The final handoff must make the review evidence auditable instead of saying only “checked” or “looks good”. Include three short labeled lines—内容, 设计, and 连贯性 (or natural equivalents in the user's language)—plus the number of slides structurally checked and rendered. Under 设计, name the autonomous or reference-derived direction, the weakest observed page, material repairs, and remaining warnings. Do not include numeric aesthetic scores. Under 连贯性, describe whether repetition, variation, and density support the narrative without forcing a numeric family count or prescribed rhythm. Do not invent observations that were not recorded from current renders.

Use this compact handoff shape so the evidence is understandable and cannot be lost during a long tool run (replace every bracket with observed evidence):

内容：目标动作是 [企业购方在汇报后要做的决策]；[8] 页均使用结论式标题且每页一个主结论，例如 [P2 实际标题] / [P5 实际标题]；[页面覆盖与叙事路径]；[证据边界]；结构检查 [8/8] 页通过。
设计：[8/8] 页已逐页渲染；视觉来源为 [自主设计 / 文字方向 / 参考图 / 参考 PPT]；视觉系统为 [具体艺术方向、主要颜色、字体层级、画布/背景和图片处理]；最弱页面为 [P# 与实际观察]；[已完成的定向修复]；[原生可编辑文本、图形、图表/表格的实际覆盖]；[剩余非阻塞提示或无]。
连贯性：[重复和变化如何服务叙事]；[信息密度和章节节奏的实际观察]；[参考一致性或自主设计一致性]。

Do not replace concrete render observations with vague claims such as “整体良好”. Include the actual visual source, art direction, palette behavior, type hierarchy, background/canvas language, and image/chart treatment so the user can understand what visual system was delivered. Exact grid, margin, and palette values are useful when they materially explain the result, but their omission alone is not a publication blocker.

For a generated product deck, the Content line must include the action objective and at least two actual conclusion-title examples from the current file. If the current titles are bare topic labels, repair them before handoff only when the user did not explicitly fix that visible wording. Never rewrite a contracted title merely to make it more assertion-like. After the three evidence lines, include a compact slide map for every slide in the form P# — [actual takeaway] | [actual visual focus]. This map is required for a generated deck so the story sequence and editable visual choices can be reviewed independently; do not substitute a topic-only agenda or a count of layout families. Then include one compact audit row for every generated slide, derived from the current render: P# — Content PASS/WARNING/BLOCKER; Design PASS/WARNING/BLOCKER; Coherence PASS/WARNING/BLOCKER. Every non-pass result must add the observed evidence in the same row. The takeaway/visual-focus map does not replace these per-slide three-dimensional records, and a positive summary does not override a page-level finding. Build this audit block before publish_outputs, count its rows, and verify that the count equals the generated slide count and that every page number appears exactly once. Missing, duplicate, or deck-level-only audit evidence blocks publication. After publishing, copy the already-counted block into the final handoff instead of reconstructing it from memory. For a generated deck grounded in supplied files or data, also include a compact 来源事实 ledger. Name every source file, reproduce every numeric sequence with its period or region, unit, and actual/target status, and list material non-numeric constraints or risks that the deck carries forward. This ledger must come from the current sources and deck; it is handoff evidence, not a license to add or reinterpret facts. The Design line should name the actual construction choices that matter to the current deck. Prefer concrete colors, type anchors, alignment logic, and crop/background treatment when they were recorded, but do not turn a fixed token checklist into a release gate for a reference-led or intentionally custom composition.