presentation-critique

name	presentation-critique
description	Review a WebsitePresent delivery before declaring it ready. Use when an HTML presentation, redesign, or motion-heavy page is about to be called done and needs checklist validation plus a five-dimension critique.

Presentation Critique

Use this skill before claiming a presentation artifact is complete.

This skill exists to make “looks okay” insufficient. It turns review into a real gate grounded in checklist evidence and a short, explicit critique rubric.

Read first

Before reviewing, read:

• references/checklist.md
• references/five-dimensions.md
• references/anti-ai-slop.md

What this skill does

This skill checks whether a presentation output is:

• directionally faithful,
• structurally speakable,
• visually coherent,
• specific to the actual task,
• restrained enough to stay credible.

It does not replace implementation validation. It sits on top of implementation validation and raises the quality floor.

Workflow

1. Confirm the target being reviewed

Be clear about:

• which task
• which version
• which output surface
• what this round intended to improve

Without that, critique becomes vague and unfair.

2. Run the checklist gate

Use references/checklist.md.

Treat P0 as mandatory. If a P0 item fails, the work is not ready.

P1 items should normally be addressed before release unless the user explicitly accepts them. P2 items are improvement opportunities, not automatic blockers.

3. Run the five-dimension critique

Use references/five-dimensions.md.

Judge the output on:

• Fit
• Hierarchy
• Execution
• Specificity
• Restraint

If any one dimension is clearly weak, call it out directly and recommend where it should be repaired.

4. Run the anti-slop audit

Use references/anti-ai-slop.md.

The goal is not aesthetic purity. The goal is to catch lazy defaults, generic polish, fake specificity, and decorative excess before they ship.

5. Produce a release verdict

End with one of these:

• PASS
• REVISION_NEEDED
• BLOCKED

Do not soften the verdict just to avoid friction.

Output contract

Your review output should include:

• verdict
• blocking findings
• non-blocking risks
• strongest positive traits
• weakest dimension
• recommended return path

The return path should name the right owner when possible:

• SourceStrategist
• NarrativeArchitect
• ExperienceDirector
• MotionDirector
• FrontendProducer
• ReviewGuardian

Principles

• Evidence before vibes.
• P0 means mandatory, not aspirational.
• Specific critique beats broad praise.
• A pass still needs a reason.
• A block still needs a path forward.

What to avoid

• passing work because it is “mostly there”,
• only commenting on aesthetics,
• using generic praise instead of a real verdict,
• ignoring whether the page actually supports live explanation,
• treating anti-slop items as optional style preferences.