| name | frontend-ui |
| description | Frontend UI checklist — CSS specificity, dark/light themes, visual testing, mobile responsiveness, i18n parity. Apply when editing HTML/CSS. |
| model | inherit |
| current_aal | 1 |
| target_aal | 2 |
Frontend UI — Checklist for Web Interface Tasks
Use when task modifies HTML, CSS, templates, or visual components. Catches recurring UI bugs missed by HTTP/syntax checks.
1. CSS Dark/Light Mode Specificity
Rule: Light mode = default. .dark class = override. Never use :not(.dark) selectors.
Anti-Pattern (BREAKS dark mode)
.dark .component { background: #0f172a; }
:not(.dark) .component { background: #ffffff; }
:not(.dark) matches any ancestor without the class, including <body> / <section> / <div>. Since these are also ancestors of .component, the selector ALWAYS matches, overriding .dark rules due to cascade order. Result: light colors leak into dark mode.
Correct Pattern
.component { background: #ffffff; }
.dark .component { background: #0f172a; }
Checklist:
2. Visual Verification
HTTP 200 + valid HTML is insufficient for UI tasks. A page can render with broken visual state and still return 200.
Required checks before marking UI task complete:
If unable to capture screenshots, explicitly ask the user to verify visually before closing.
3. i18n UI Parity (if applicable)
For bilingual/multilingual sites:
4. Mobile Responsiveness
5. Accessibility Baseline
6. Performance Hygiene
7. SEO & Social Preview
When to Apply
- Any
/dr-do that modifies .html, .php templates, .css, .vue, .tsx files touching UI
- Any task with type "Website Development" or "Frontend"
- Before closing UI tasks with
/dr-compliance
8. Source of Truth for Component Counts
Before generating lists of framework components (agents, skills, commands, use cases) for content, documentation, or marketing:
- Query the filesystem — never rely on cached numbers from previous sessions:
ls $HOME/.claude/agents/*.md | wc -l
ls $HOME/.claude/commands/*.md | wc -l
ls $HOME/.claude/skills/*.md | wc -l
- Check source docs for use cases, features, capabilities:
documentation/tutorials/use-cases.md in the Datarim repo for the canonical use case list
- Agent/skill
.md files for accurate capability descriptions
- Never hardcode counts — they drift as the framework evolves (e.g., 15→16 agents, 18→22 skills during v1.5→v1.6)
Why: A prior incident showed stale counts on the site ("15 agents / 18 skills" while actuals were 16/22, and 6 use cases instead of 13). Both errors came from relying on stale session data instead of querying the source.
9. Browser-Based Verification at /dr-qa
When the task changes any file under § 1–4 above, /dr-qa runs an
automated Playwright pass against the local dev surface or a static
fixture. Contract: $HOME/.claude/skills/playwright-qa/SKILL.md (resolution
chain CLI → MCP → env-browser, three headed states, per-task flock,
datarim/qa/playwright-{ID}/run-<ts>/ artifact layout). Missing tooling
is a finding, not a block; --headed-strict without a display fails the
QA pass.
Two operator-facing knobs:
- CLI:
/dr-qa --headed (lenient) or /dr-qa --headed-strict (fail-fast)
- Init-task frontmatter:
qa_browser_mode: headed | headed-strict | skip
Inspect datarim/qa/playwright-{ID}/latest/summary.md for the most
recent pass. Visual review (does the screenshot match intent?) remains an
operator step — the automated pass captures evidence, it does not
adjudicate aesthetic correctness.
Integration
tester agent: include this checklist in Web UI testing mode
developer agent: consult before completing frontend tasks
reviewer agent: verify compliance during /dr-qa
playwright-qa.md: detailed contract for the automated browser pass
invoked at /dr-qa Step 4f
- Immutability contract:
skills/immutability/SKILL.md § Frontend-UI
Rules — defines the visual baseline immutability rule, deviation
recording, and operator-approval requirement. Frontend-UI tasks that
change visual output MUST NOT silently accept regressions; visual
deviations require operator diff review per the Frontend-UI Rules
fragment.