Presentation skill needs maintenance/editing workflows, visual QA, and cross-deck consistency

Context

The presentation skill is creation-focused (wizard → Deck Spec → render) but has no support for the most common real-world workflow: iterating on and maintaining existing presentations. A session working on a 10-deck HTML presentation system exposed significant gaps.

Session Root Cause Analysis

1. No "edit existing deck" workflow

The skill assumes you're always creating from scratch. When working with existing decks, there's no structured entry point — no way to say "audit this deck system" or "fix layout issues across these decks." Everything was ad hoc.

Proposed: Add an audit entry point that accepts an existing deck path, inventories slide types, checks CSS health, screenshots representative slides, and produces an issue list.

2. Visual verification loop is theoretical

The fidelity system describes "CSS layout verified via computed style checks" for best mode, but there's no implementation. In practice, we wrote CSS → manually screenshotted → discovered problems → repeated. This is the exact loop LLMs should automate.

Proposed: Implement the verification loop from fidelity.md using Playwright/browser automation:

• Screenshot each slide at 1280x720
• Use Claude's vision to verify: text readable, elements not overlapping, alignment consistent, colors match palette
• Auto-flag slides that fail, with specific issues identified
• Re-render/fix and re-verify (up to the pass limit)

3. No CSS design system contract

The skill's templates define layout zones abstractly (title-hero, two-column, stat-callout) but don't enforce a concrete CSS contract. This led to:

• 3 different wrapper class names (.slide-content, .slide-inner, .slide-content-wrap) with inconsistent styling
• 12+ different class variants for title/section slides with no documented mapping
• A 3-layer CSS cascade (engine.css → components.css → stage0-components.css → dark-override.css) with undocumented specificity rules
• A single missing } in CSS silently killing 1,000+ rules

Proposed: Define a CSS contract in the skill:

• Canonical class names for each slide type (title, section, content, quote)
• Required layout properties per type (alignment, centering rules)
• CSS parse error detection as a pre-check
• A "slide type classifier" that maps any class name to one of the canonical types

4. No cross-deck consistency validation

Each deck was treated independently. With 10 decks sharing a CSS system, there was no tool to verify consistency (same backgrounds, same fonts, same alignment rules, same dark theme).

Proposed: Add a consistency-check that:

• Compares computed styles across representative slides from each deck
• Flags deviations (white vs dark backgrounds, different font sizes for same element types)
• Produces a diff report: "deck X differs from baseline on: background, h2 size, quote alignment"

5. No content lint for presentations

Vendor-specific references (Jira, Confluence), model-specific names (Gemini, Claude), and terminology inconsistencies ("QE Fabric" vs "Delivery Fabric") were all discovered manually.

Proposed: Add a content linter with configurable rules:

• Vendor name detection (flag specific product names, suggest generic alternatives)
• Terminology consistency (flag when the same concept uses different names across slides)
• Accessibility checks (contrast ratios, font size minimums, alt text)
• Speaker notes completeness

6. Parallel editing coordination

Multiple subagents editing the same CSS files simultaneously produced contradictory changes. The presentation skill should either serialize CSS edits or use a structured approach (one agent per file, or a CSS-specific agent that understands the cascade).

Proposed: When dispatching parallel work on presentations, never let multiple agents edit the same CSS file. Split work by: slide HTML (parallelizable) vs CSS (serialized).

Summary of Proposed Additions

| Feature | Entry point | Purpose |
|---------|-------------|---------|
| Deck audit | "audit this deck" / "check my presentation" | Inventory, screenshot, flag issues |
| Visual QA loop | Automatic in best fidelity | Screenshot → vision check → fix → re-verify |
| CSS contract | Built into templates | Canonical classes, required properties, parse checks |
| Cross-deck consistency | "check consistency across decks" | Compare computed styles, flag deviations |
| Content lint | "lint my deck content" | Vendor names, terminology, accessibility, notes |
| Edit coordination | Internal to skill | Serialize CSS edits, parallelize HTML edits |

None of these are specific to any one presentation — they apply to all presentations the skill works with.