---
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.