Frontend Judgment

Overview

Feel like a senior frontend engineer: decide with the user, then build. Do not dump a generic UI for blank-canvas work. This skill is a short gate before tokens / components / etc.

This pack-authored workflow uses independent design-axis analysis; no external exploration tool is bundled.

When to use (mandatory gate)

Run this before domain skills when any of these apply:

• New page, screen, flow, or blank-canvas layout
• Unspecified information architecture / navigation / density
• Marketing / landing page without a section recipe → load marketing after approaches (or with “langsung saja”)
• Multiple reasonable visual or interaction directions
• User ask is vague for a new screen (“bikin dashboard”, “UI modern”) — not mere “rapihin” on existing UI (that’s polish / quality-loop)

When to skip

• Clear bugfix with known expected behavior
• Tiny change (one component prop, one token color, copy tweak)
• User already chose a direction or said “langsung saja” / “just implement”
• Pure /design audit with no implementation request
• Follow-up turn continuing an already-approved plan
• User only wants micro polish on existing UI (“rapihin detail”, “feels off”) → use polish
• User wants iterate until audit-clean (“sampai bagus”) → use quality-loop, which may call judgment only on first blank-canvas pass

Workflow

0. Quick context (silent — no questions yet)

• If DESIGN_MEMORY.md exists in the project root, read it and honor captured tone/density/patterns
• Note whether the project already has tokens / a component library (feeds step 4 handoff)

1. Clarify only if blocked (max 1–2 questions)

Ask only what changes the design. Prefer multiple choice. Do not run a full design-lab interview.

Good single questions (pick at most two total):

• Skip questions you can infer from the repo or DESIGN_MEMORY.md.
• Coded side-by-side comparison is prototype, not this skill. Do not emit five full coded variants here.

2. Offer 2–3 approaches on distinct axes

Do not offer three near-identical skins. Each option should explore a different axis (from design-lab variant thinking):

Present 2–3 options (not 5 coded mocks). Label each with its axis.

For each option:

• Name + axis (short)
• What it looks/behaves like (1–2 sentences)
• Tradeoff (clarity, density, a11y, ship cost)
• Mark one recommendation and why (1 sentence)

3. Wait for a clear choice

• Affirmative on one option → proceed
• Hedged → pick recommended and state that, or one tight confirm
• “Langsung saja” → pick recommendation and build

4. Hand off

After direction is set:

1. Style inference (for tokens / build) — if a project system exists:
   • Read Tailwind theme / :root / theme file
   • Skim 2–3 existing buttons, cards, forms for padding, radius, shadow, type
   • Do not invent a parallel visual language
2. Token source — walk the decision tree in references/token-preset-scoring.md (custom → explicit → Plasma hard-gate → score). Judgment sets axes/signals; it does not pick a preset by vibe. Include Token score / hard-gate / project system in the handoff. Capture a one-sentence craft intent (task + dominant content form + 2–3 visible decisions), using references/design-axes.md → Turn a reference into decisions. Apply this even when the approach-choice gate was skipped for an already-approved direction; do not reopen approval.
3. Load: (+ prototype if they asked to see options or stress states) → tokens → (+ shell/data/forms) → components → responsive → motion (light) → anti-slop-design → polish → accessibility (+ testing / seo if in scope)

Optional short handoff note (when exploration was non-trivial):

## Build plan (brief)
- Axis chosen: …
- Files likely touched: …
- States: loading / empty / error / …
- Tokens: <project system | explicit | hard-gate | scored preset + n/24>
- Responsive: 320/768/1024/1440

Do not re-litigate the approach mid-build unless new constraints appear.

Hierarchy pass (ship gate — post-build)

Before DONE / Conventions check, verify the built surface against this checklist. Theory: references/ux-foundations.md, axes: references/design-axes.md.

Report in Conventions when auditing: Hierarchy: pass (or list fails). Missing hierarchy on blank-canvas / polish → treat as Needs Work on Visual Hierarchy.

Typography ladder (ship gate)

Pair with polish / anti-slop-design. Full anti-patterns: references/anti-patterns.md.

Quick decision check

When stuck between options, prefer the one that is: clear · fast · consistent · accessible · calm · specific · recoverable.

Expert voice (do / don't)

Do:

• Push back on AI-slop defaults with a better alternative
• Prefer content and hierarchy over decoration
• Name tradeoffs honestly
• Reference concrete inspiration (“Linear-like density”) when it helps

Don't:

• Block on slash commands
• Ask more than 2 questions up front
• Offer 5+ options or five full coded variants by default (coded comparison is prototype, cap 2–3)
• Start a temporary design-lab route unless the user explicitly asks to explore in-browser
• Start coding blank-canvas UI before a direction is set (unless skip rules apply)

Output template (before build)

## Approaches
**A — … (axis: hierarchy)** … Tradeoff: …
**B — … (axis: density)** … Tradeoff: …  ← recommended: …
**C — … (axis: interaction)** (optional) …

## Recommendation
…

## Need from you
Pick A/B/C (or say “go with recommended”).

Checklist

• Direction chosen (or skip rules applied) before domain skills
• Handoff includes tokens + Responsive breakpoints
• Hierarchy pass completed on built surface
• Typography ladder (one h1, no skipped levels, token roles)
• Build plan notes states (loading / empty / error) when non-trivial

Depth

Lifecycle A→Z: references/fe-lifecycle.md. Axes + memory convention: references/design-axes.md. Token preset scoring: references/token-preset-scoring.md. UX/UI theory + color for products: references/ux-foundations.md (wire hierarchy/type here into ship gates above). Anti-patterns: anti-slop-design + references/anti-patterns.md. Domain how-to stays in the other skills.