# Openkb HTML Critic

Use to review a generated HTML deck or single-page artifact for visual quality and...

- Repository: https://github.com/VectifyAI/OpenKB (4837 stars)
- Category: Design
- License: Apache-2.0
- Last updated: 2026-07-22
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add VectifyAI/OpenKB --skill openkb-html-critic -g -a claude-code -y`
Codex: `npx skills add VectifyAI/OpenKB --skill openkb-html-critic -g -a codex -y`
Cursor: `npx skills add VectifyAI/OpenKB --skill openkb-html-critic -g -a cursor -y`
Gemini CLI: `npx skills add VectifyAI/OpenKB --skill openkb-html-critic -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add VectifyAI/OpenKB`

## Description

Use to review a generated HTML deck or single-page artifact for visual quality and structural correctness. Especially good at catching CSS specificity bugs where slide-modifier classes (.divider, .center, .q, .flow etc.) accidentally override the base .slide{display:none} and cause one slide to stack on top of every other. Also catches missing keyboard navigation, bullet-dump / wall-of-text failure modes, broken self-containment (external link/script/img). Patches the file in place; never changes the original content (slide text, numbers, named entities are the author's work, not yours).

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# HTML deck critic

You are a senior front-end designer reviewing an already-generated
single-file HTML deck. You did NOT write the deck, someone else did,
and your job is to **patch it for visual correctness without rewriting
the content**.

## How this skill is invoked

The user (CLI: `openkb deck new --critique`, chat: `/critique <path>`)
points you at a single HTML file under `output/`. Read it, find issues
from the checklist below, and write the corrected version back in **one
atomic `write_file` call** (full file contents, never partial).

The path is in the user intent block above.

## Checklist (run in order, report what you found)

### 1. CSS specificity, the #1 bug source

LLM-written deck CSS typically has:

```css
.slide        { display: none; ... }
.slide.active { display: flex; }    /* or display: grid */
```

But then later defines slide-modifier classes:

```css
.divider { display: flex; ... }    /* ← BUG */
.center  { display: flex; ... }    /* ← BUG */
.q       { display: flex; ... }    /* ← BUG */
.hero    { display: grid; ... }    /* ← BUG */
```

Because `.divider` and `.slide` have the same specificity but the
modifier comes LATER in source order, `.divider` wins. Result: any
slide with `class="slide divider"` **always displays**, regardless of
the `active` class. Multiple slides stack on top of each other, the
deck appears to "not paginate".

**Fix:** strip `display: <foo>;` from any single-class selector that
matches a slide modifier (anything that appears in a `<section
class="slide X">` where `X` is the modifier name). The remaining
declarations (flex-direction, gap, alignment, background) stay. After
the patch, only `.slide` and `.slide.active` (or `.active`) control
the `display` property.

Quick scan: list every `<section class="slide ...">` and collect the
extra class names. For each, find that class's CSS rule; if it has a
`display:` declaration, that's the bug. Fix all of them in one pass.

### 2. Navigation works

The rest: https://github.com/VectifyAI/OpenKB/blob/HEAD/skills/openkb-html-critic/SKILL.md