olzn

@olzn source repo

26 skills
0 followers
17 hours ago last updated

▌
Wrapup · olzn
Close out a feature worktree once its PR has merged — confirm the merge, verify the deploy where one applies, remove the worktree, and clean up branches; with --abandon, tear down a killed feature after showing exactly what is being discarded. Requires a merged PR or an explicit --abandon — a session ending while work is still in flight is your session-close workflow, and unfinished work someone must resume is the handoff skill. Triggers on "/wrapup", "the PR merged, tidy up", "clean up this worktree", "abandon this feature".

0
installs
▌
Handoff · olzn bundle
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.

0
installs
▌
Hig · olzn bundle
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.

0
installs
▌
Prototype · olzn
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. Marks a quiet pick but does NOT collapse to one winner, research, implement, verify, or open a PR; a chosen direction hands off to the build skill, whose review gates check the result. For editable Paper artboards rather than throwaway HTML, use paper-prototype instead; for whether a state model, business logic, or data shape feels right, use logic-prototype.

0
installs
▌
Polish Fix · olzn
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.

0
installs
▌
Decision Coach · olzn bundle
Coach a real decision to a better outcome, or stress-test reasoning you've already formed, using the Duke/Tetlock/Parrish decision-science corpus. Use when explicitly invoked — "use decision-coach", "help me decide X", "stress-test my thinking on Y", "coach me through this choice", "what mental model applies here". Does NOT auto-activate on every mention of a choice; engage it deliberately.

0
installs
▌
Harness Config · olzn
Keep agent configuration — instructions, skills, commands, agents, MCP registrations, hooks, permissions, and reusable prompts — aligned across more than one agent harness (e.g. Claude Code + Codex) from a single canonical config repo. Use when changing personal or repository agent configuration, migrating a workflow between harnesses, diagnosing configuration drift, or asking whether a capability will propagate from one harness to another.

0
installs
▌
Hig Design · olzn bundle
Design, prototype, adapt, or implement iOS and macOS interfaces that follow Apple's current Human Interface Guidelines. Use when designing or mocking an iPhone, iPad, or Mac app screen, building an HTML prototype of a native app, writing or fixing SwiftUI UI (glassEffect, GlassEffectContainer, Liquid Glass adoption, scroll edge effects, tab bar accessories), porting a design between iOS and macOS ("make a Mac version", "adapt for iPad"), choosing native components or navigation, or making something "feel native" or "feel like a real Mac app". Model priors on Apple's design system are stale (Liquid Glass era) — load constraint sheets before generating; never design Apple UI from memory. Works with HTML prototypes, Figma, and SwiftUI. Does NOT audit existing designs (use hig-review) and does NOT cover non-Apple web UI (use ui-craft or frontend-design).

0
installs
▌
Hig Review · olzn bundle
Audit designs, prototypes, or code against Apple's Human Interface Guidelines. Use for Apple-marked review asks — "is this HIG compliant", "review my iOS app", "review my Mac app", "does this feel native", "would Apple reject this", "check this against the HIG" — or when reviewing SwiftUI UI code, an HTML prototype that imitates native Apple UI, or Figma frames built on Apple's kits. Covers screens, flows, copy, accessibility, Liquid Glass usage, system surfaces (widgets, Live Activities, notifications), and App-Review-enforced rules. Model priors on Apple's design system are stale (Liquid Glass era) — never judge native correctness from memory. Does NOT fire on unmarked "review my prototype/UI" for web apps (use ui-craft or interface-craft); web mechanics of HTML prototypes stay with ui-craft — this skill owns native idiom and metric values.

0
installs
▌
Grill With Docs · olzn bundle
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 the user wants to stress-test a plan against their project's language and documented decisions.

0
installs
▌
Logic Prototype · olzn bundle
Build a single-file HTML demo that answers whether a state model, business logic, or data shape feels right — a pure liftable module driven by free-play buttons and tabbed guided walkthroughs a non-developer can click through. Use when the user wants to sanity-check a state machine or reducer, probe an edge case ("what happens if X then Y"), feel out a data model or API shape before building it, or hand a domain expert something to poke at. For what a UI could look like use prototype; for editable Paper artboards use paper-prototype.

0
installs
▌
Paper Prototype · olzn bundle
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 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. For business-logic or state-machine prototyping use logic-prototype, unless the user explicitly asks for Paper output.

0
installs
▌
Pre Build Review · olzn
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. Invoked automatically by the build skill before implementation, and available manually 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.

0
installs
▌
Post Build Review · olzn
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 (loading, empty, error, disabled, permission, offline, long content, maximum volume, 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. Invoked automatically by the build skill after implementation, and available manually 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, sanity-check a built change before handoff, or asks whether a change is ready to ship.

0
installs
▌
UI Craft · olzn bundle
Coordinate the UI Craft skill suite. Use when a user asks for broad UI design, frontend quality, design-system work, interface review, visual polish, UX writing, or when it is unclear which domain skill should lead. Also use for quality, craft, papercut, entropy, and "why does this feel bad?" prompts. Routes work across naming, tokens, components, patterns, copy, motion, interaction, typography, colour, and detail. Use for "make this UI better", "review this interface", "improve this design system", "which skill applies", or multi-skill UI tasks. This is a coordinator, not a replacement for the focused domain skills.

0
installs
▌
Writing For Agents · olzn bundle
Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md. Where a repo ships its own doc-writing rules, apply those on top — this is the underlying theory.

0
installs
▌
Surface Copy · olzn bundle
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).

0
installs
▌
System Naming · olzn bundle
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.

0
installs
▌
System Tokens · olzn bundle
Set up and maintain design token architecture and foundation scales. Use when defining spacing, radius, edge, shadow, z-index, breakpoint, or motion scales, establishing the primitive/semantic/component token model, naming tokens, configuring theming, or auditing hardcoded values. Also triggers for "design tokens", "CSS custom properties", "token naming", "semantic layer", "spacing scale", "surface definition", "theming", or "hardcoded values". Provides scale definitions and structural rules that distribute colour, type, and motion values across a system. Does NOT cover broad naming taxonomies, UI terminology, user-facing labels, feature names, or product names (use system-naming). Does NOT cover component APIs (use system-components), composite patterns (use system-patterns), palettes (use surface-colour), or type scales (use surface-typography).

0
installs
▌
Surface Colour · olzn bundle
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.

0
installs
▌
Surface Motion · olzn bundle
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 animation vocabulary, pattern names, 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.

0
installs
▌
System Patterns · olzn bundle
Architect composite UI patterns that assemble components into coherent features. Use when building forms, validation, error handling, multi-step flows, navigation, breadcrumbs, active states, deep linking, tables, lists, cards, sorting, filtering, pagination, empty/loading/error states, feedback systems, confirmations, progress, optimistic updates, page layouts, sidebar+main structures, dashboard grids, responsive stacking, or content density. Also triggers for "how should this form validate", "where should errors show", "toast or inline", "how to structure this dashboard", "mobile navigation", workflow coherence, complexity cost, feature accretion, or how components work together. Does NOT cover button labels, command names, feature/product names, or UI terminology (use system-naming), component APIs (use system-components), token architecture (use system-tokens), animation values (use surface-motion), or platform quirks (use surface-details).

0
installs
▌
Surface Details · olzn bundle
Catch platform-specific implementation details and visual polish that make web interfaces feel professional. Use when building forms, inputs, textareas, 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, textarea nested scrolling, hydration flash, image outlines, optical alignment, surface definition, 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).

0
installs
▌
System Components · olzn bundle
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).

0
installs
▌
Surface Typography · olzn bundle
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.

0
installs
▌
Surface Interaction · olzn bundle
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.

0
installs

26 published skills