olzn

Compact the current conversation into a handoff document another session or agent can resume from. Use when wrapping up with unfinished work, when context is getting long, or when the user says "hand this off", "write a handoff", or "save state for the next session". Produces a single Markdown file at a durable, harness-agnostic path and reports it. Does NOT continue the work itself; it only captures state so a fresh session can.

Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.

Land one small UI papercut as a tiny, easy-to-approve PR, the low-ceremony path for fixes too small to warrant a full session. Use when the user spots a minor visual or interaction nit (spacing, alignment, colour, hover, copy, a slightly-off radius) and wants it fixed and shipped without ceremony, or says "quick fix", "polish this", "tiny PR for X". Makes the minimal change, captures a before/after, and opens a small PR. Does NOT do feature work, refactors, or anything that needs review discussion; escalate those to a normal session.

Generate N different HTML implementations of a UI feature, preview them, and iterate a few times, a fast "show me the options" loop for exploring what a feature could look like. Default N is 5. Use when the user wants to prototype a UI, explore or compare designs for a feature, says "prototype this", "try a few designs", "explore some options for X", "what could this look like", or hands over a feature with no spec. Surfaces a quiet recommendation inside the preview but does NOT collapse to one winner, do research, implement, verify, or open a PR; those are layered on at prompt time, or handed to /verify and /code-review.

Create Paper-first UI prototype directions, especially after grill-with-docs has settled product and domain decisions. Use to explore layout, hierarchy, density, flow, or visual framing as editable Paper artboards before committing to code, to compare 2 to 3 structurally distinct directions, or to turn settled product decisions into an interface. For throwaway HTML explorations rather than editable Paper frames, use the prototype skill instead. Do not use for business-logic or state-machine prototyping unless the user explicitly asks for Paper output.

Run a post-implementation review that checks a built change against the intent that was set. Run lint, typecheck, tests, and build; confirm the result matches the chosen design direction and covers its promised states (empty, loading, error, disabled, long content, and partially complete data); check accessibility and responsive behaviour; flag any risky surface; and assemble the handoff evidence a reviewer needs. Read-only: it reviews and reports, it never edits. Use after a build or a meaningful change, after ui-craft and before opening or finalising a PR, especially when the user asks to verify, review, sign off, or sanity-check a built change before handoff.

Run a pre-implementation plan review that attacks a settled product, UI, or technical plan for blockers, missing states, edge cases, accessibility gaps, mobile failures, awkward data assumptions, and implementation ambiguity. Use before coding after grill-with-docs, paper-prototype, a design decision, prototype, PRD, brief, or implementation plan, especially when the user asks to red-team, sanity-check, review, or decide go/no-go before build.

Apple Human Interface Guidelines (HIG) lookup and routing for iOS, iPadOS, and macOS design work. Use when any Apple-platform design spec, term, or behaviour is in question — minimum tap target or hit target size, type sizes, Dynamic Type, safe areas, bar heights, corner radii, sheet detents, menu structure, native component names — or when work touches Liquid Glass-era APIs (glassEffect, GlassEffectContainer, scrollEdgeEffect, tabViewBottomAccessory) even without HIG framing. Model priors on Apple's current design system are stale (the HIG was rewritten for Liquid Glass in 2025–26) — never answer Apple design-spec questions from memory. Routes design and prototyping work to hig-design and HIG audits to hig-review. Also use to check whether the local HIG snapshot is current. For web-platform values on non-Apple work, use ui-craft.

Build perceptually uniform, accessible colour systems using OKLCH. Use when creating colour palettes, defining colour tokens, setting up light/dark themes, checking or fixing contrast, generating colour scales, choosing brand colours, configuring semantic colour mapping, or debugging colour that looks "off" across hues. Also triggers for OKLCH, LCH, colour contrast, WCAG, APCA, colour blindness, gamut, perceptual uniformity, dark mode colours, or "these colours don't feel right". Covers why HSL fails, scale generation, chroma tapering, semantic colour mapping, light/dark themes, WCAG/APCA contrast, colour blindness, and P3. Does NOT cover human-readable colour naming or palette taxonomy (use system-naming), typography, animation, interaction design, platform quirks, or component APIs.

Write and review interface copy that guides, explains, reassures, or persuades. Use when drafting or improving error message bodies, empty states, helper text, onboarding text, tooltip prose, loading text, success or warning messages, confirmation body copy, and marketing-style CTA copy. Also triggers for UX writing, microcopy, tone, localisation notes, or "this copy feels unclear". Does NOT own product action labels, command names, menu items, feature names, product names, component names, token names, or UI terminology (use system-naming). Does NOT decide placement or flow structure (use system-patterns), component state coverage (use system-components), or accessibility mechanics (use surface-details).

Catch platform-specific implementation details and visual polish that make web interfaces feel professional. Use when building forms, inputs, toggles, buttons, dropdowns, scroll behaviour, touch interfaces, focus handling, or production polish. Also triggers for bugs like iOS input zoom, sticky hover on mobile, dead zones, tooltip delay, menu prediction cones, unsafe hit areas, hydration flash, image outlines, optical alignment, shadow depth, nested radius, quality-of-life papercuts, stable scroll position, cursor safety, and performance micro-issues. Does NOT cover animation values or easing (use surface-motion), gesture decisions (use surface-interaction), type systems (use surface-typography), colour or contrast (use surface-colour), component APIs (use system-components), or token architecture (use system-tokens).

Make interaction design decisions about gestures, spatial logic, timing intent, and physical behaviour. Use when building swipe-to-dismiss, drag-and-drop, swipe-to-reveal, pinch-to-zoom, pull-to-refresh, navigation transitions, scroll-linked interactions, command menus, or deciding whether something should animate. Covers gesture intent, spatial consistency, kinetic physics, interruptibility, frequency calibration, metaphor reuse, snap points, progressive reveal, and elastic resistance. Does NOT provide easing curves, duration values, or animation code (use surface-motion). Does NOT cover platform quirks, CSS details, or accessibility specifics (use surface-details). Does NOT cover colour, typography, or component APIs.

Implement animation and transitions with precise easing, timing, and transform rules. Use this skill whenever writing CSS transitions, keyframe animations, spring animations, Motion (Framer Motion) configs, or any code that moves elements on screen. Also triggers for easing curves, duration tuning, transform-origin placement, scale ranges, exit/entrance patterns, staggered entrances, icon swap animations, AnimatePresence, scroll-triggered reveals, CSS transition vs keyframe selection, animation libraries, spring physics, reduced motion, and "feels janky" or "too slow/fast" complaints. Provides the exact values, code patterns, and implementation recipes for web animation. Does NOT decide whether something should animate or what spatial logic to follow (use surface-interaction for those decisions). Does NOT cover gesture design, frequency/novelty calibration, or interaction intent. Does NOT cover colour, typography, layout, or component APIs.

Build rigorous typography systems for web interfaces. Use this skill whenever setting up a type scale, choosing or pairing fonts, configuring fluid typography with clamp(), implementing vertical rhythm, tuning OpenType features, loading web fonts performantly, working with variable fonts, or diagnosing type rendering issues. Also triggers for any mention of font-size, line-height, letter-spacing, font pairing, type hierarchy, vertical rhythm, baseline grid, or "text looks off". Covers type scales (modular and custom), vertical rhythm and baseline alignment, fluid vs fixed typography, font loading strategy, subsetting, OpenType feature configuration, variable font axes, display/body pairing, and text rendering. Does NOT cover colour, animation, interaction design, platform quirks, or component APIs. Use surface-colour, surface-motion, surface-interaction, surface-details, or system-tokens and system-components for those concerns.

Build reusable, consistent UI components with well-defined APIs and complete state coverage. Use when creating or reviewing components, props, variants, configuration vs composition, compound components, controlled/uncontrolled patterns, component states, CVA, asChild/render delegation, ref forwarding, icon system conventions, or "this component API feels wrong". Uses Radix, Base UI, and shadcn/ui as examples where that stack is already appropriate; do not add those dependencies automatically. Does NOT cover broad component terminology, icon names, button labels, feature names, or product names (use system-naming). Does NOT cover token architecture or theming (use system-tokens), composite patterns such as forms/navigation/tables (use system-patterns), or visual design, animation, and platform quirks (use the relevant surface skill).

Name interface, code, design-system, and product concepts clearly and consistently. Use this skill when choosing, reviewing, auditing, or refactoring names for button labels, commands, menu items, fields, variables, classes, CSS custom properties, design tokens, Figma variables, Figma layers, UI components, icons, colour names, feature names, product names, navigation labels, UX terminology, or any "what should this be called?" question. Covers naming taxonomies, user-facing labels, semantic versus implementation names, controlled vocabulary, alias handling, and consistency checks. Does NOT choose visual values, token scale values, component architecture, layouts, animation, accessibility mechanics, or brand strategy; use the relevant domain skill for those decisions.