Build Before/After Change Deck

Build a decision surface that lets the audience answer three questions quickly: what object changed, how it changed, and what the resulting structure or consequence is.

Load prerequisites

1. Load and follow the environment's presentation Skill before reading, editing, rendering, or validating presentation files.
2. Load the PDF Skill when source or output includes PDF.
3. Use context-first-design-execution when this deck continues an existing revision chain or the request refers to earlier versions.

Read change-ledger-and-transition-gate.md when the deck contains several change types, paired slides, bilingual mappings, or any requested transition. Use the ledger as the canonical record for object/action separation, source evidence, counts, and transition safety.

Keep project facts, private screenshots, node IDs, and internal filenames in the task workspace. Do not embed them in this reusable Skill.

Lock the source of truth

Create a change ledger before laying out slides:

Keep the business object and action separate:

• Use the main title to answer what is changing.
• Use a large, consistent action tag to answer how it changes.
• Use the comparison body to show Before → After.

Do not mix object names, action types, status labels, and evidence notes at the same hierarchy level.

Build the narrative from decisions

Prefer this sequence when the source supports it:

scope and conclusion
→ change-type totals
→ Before/After change groups
→ resulting complete structure
→ pending decisions or release states

For a short 5–10 page review deck, combine related evidence rather than deleting important change types. Keep the full-detail deck as an appendix or source artifact when needed.

Use two complementary views:

• Change view — groups by action such as added, renamed, hierarchy changed, or status changed.
• Structure view — shows the resulting first-level and second-level information architecture.

State the counting rule once. Keep totals internally consistent and expose unresolved names or data as pending instead of inventing them.

Raise information density

Treat density as decision-relevant information per visible area.

• Target about 75–85% meaningful page coverage while preserving one dominant read.
• Replace explanatory paragraphs with counts, matrices, compact rows, aligned comparisons, and short conclusions.
• Keep three to five information groups per slide.
• Place bilingual labels together on the same slide when the audience needs direct mapping.
• Use one repeated visual grammar for all change types.
• Crop screenshots to the evidence-bearing region and remove browser chrome or inactive margins.
• Use the footer for the conclusion, counting rule, or pending note.

Remove:

• repeated gray subtitle sentences below every title;
• process notes that belong in speaker notes;
• duplicated explanations already visible in the comparison;
• decorative cards, lines, or arrows that do not encode a relation;
• empty title slides that interrupt a short review flow;
• tiny action labels that cannot be read on a projector.

Make action tags visually secondary to the business object but large enough to scan. Use a consistent position and color mapping; as a study baseline, start around 16–20 pt and adjust to the real canvas and viewing distance.

Compose Before/After pages

Choose one pattern per change family:

1. Side-by-side comparison — use when both states fit legibly and direct row matching matters.
2. Paired slides — use when the structure is dense, when rows reorder, or when a transition should reveal the new state.
3. Summary plus detail — use one count overview followed by compact change groups.
4. Final structure — show the complete resulting hierarchy after the change explanation.

For paired slides:

• keep the title, margins, grid, and stable context in the same positions;
• highlight changed rows and dim unchanged rows only during presentation emphasis;
• preserve the complete page in editing view and thumbnails;
• show the Before page first and the After page second;
• avoid object matching when tables reorder, text changes length, or objects were rebuilt.

Choose a safe transition

Use this order of preference:

1. Native page Fade — default for reliable Before → After explanation. It does not depend on object identity and avoids row, arrow, or label drift.
2. Native Morph / Magic Move — use only when paired objects have stable names or IDs, compatible types, intentional bounding-box changes, and verified start/end renders.
3. Embedded media — use only when the user specifically needs a self-contained animation and editing-view limitations are acceptable.

Switch from Morph/Magic Move to Fade when any of these occur:

• menu rows are inserted, deleted, reordered, or regrouped;
• text boxes have different content length or wrapping;
• arrows, tags, and table cells match the wrong objects;
• the editor and slideshow use different object identity rules;
• one full render shows an unintended path or overlap.

Keep first and final frames complete. Do not use a blank first frame, invisible entrance state, or GIF poster frame as the editing view.

Apply deterministic Fade transitions

Use scripts/apply_safe_fade_transitions.py when an existing PPTX needs native Fade transitions on known After slides:

python scripts/apply_safe_fade_transitions.py \
  input.pptx \
  output.pptx \
  --slides 3,5,7,9 \
  --speed med \
  --clear-others

The script:

• writes to a distinct output file by default;
• rejects PPTX packages containing GIF media unless --allow-gif is explicit;
• inserts native <p:fade/> transitions without altering slide objects;
• can remove transitions from unselected slides with --clear-others;
• validates the selected slides after writing.

Remove unwanted GIF layers and relationships with the presentation tooling before running the script. Do not delete media package entries by filename alone.

Validate every output

Before delivery:

1. render every slide at full size;
2. inspect a montage for density, hierarchy, repeated silhouettes, and pacing;
3. verify all counts and Before/After mappings against the ledger;
4. check action-tag legibility and consistent position;
5. run overflow, clipping, font, missing-media, and package-integrity checks;
6. inspect each transition in slideshow order;
7. confirm editor thumbnails and first frames show complete content;
8. verify transition targets, absence of unintended Morph matches, and absence of GIF media when native transitions were requested;
9. keep pending translations, states, and decisions visibly pending.

Do not claim success because the PPTX contains transition XML or media. The rendered Before state, rendered After state, and actual transition path must all be correct.

Deliver

Return:

• editable PPTX and requested PDF or Keynote-compatible artifact;
• page count and change-type totals;
• short narrative summary;
• transition type and target slides;
• QA status for overflow, first frames, object drift, and unresolved content.