dengskills

Specify or revise one UI component's contract: props, variants, slots, keyboard and focus behavior, and data ownership. Use when defining a component's API before building it, or when a component's props or variants have grown inconsistent.

Create or revise repository instructions using verified commands, paths, architecture constraints, and review expectations. Use when creating AGENTS.md or CLAUDE.md, when agents invent commands or paths, or when instructions drift stale.

Build, improve, or audit the visible interface as a whole: composition, visual hierarchy, typography, responsive detail, interaction states, and accessibility, verified on the rendered result. Use when UI looks generic or unpolished, a dense screen is hard to scan, visual hierarchy needs refining before review, or a flow needs a keyboard and state audit, on web, mobile, or desktop.

Map one task step by step from entry to outcome, including each write's pending, saved, rejected, and unknown outcomes and the branches for errors, cancellation, and interruptions. Use when laying out onboarding, checkout, creation, editing, approval, or account flows, or deciding what happens after each user action.

Plan or refine Git collaboration, reviewable changes, worktrees, and dependency-update ownership. Use when planning branches, slicing reviewable PRs, coordinating parallel agents, or assigning lockfile ownership.

Decide a page's content priority: rank its information and actions, write headings that carry meaning, and choose what stays visible or gets deferred on narrow screens. Use when a page has too much competing for attention, the main action gets missed, or when planning what a page says before layout or visual design.

Clarify what to build and for whom before design or code, or reassess a shipped feature against its original promise. Use when a rough idea, client request, or vibe-coding prompt needs its user, outcome, and smallest useful scope settled, or when a feature goes unused and needs keep, fix, or cut decisions.

Design or fix page structure: shells, regions, widths, responsive behavior, and which region scrolls, using real content. Use when planning landing, dashboard, auth, or docs shells, or when a layout breaks at some widths, regions jump between pages, or content overflows sideways.

Build or revise a runnable prototype for a client goal, using realistic content and explicit real/mock boundaries to learn through interaction. Use when matching fidelity to the validation question, trying a task flow, or judging layout, motion, or latency in code.

Assess whether a build is safe for its intended demo, pilot, or launch, with evidence and named blockers. Use when a preview looks done, a client asks to go live, real users or real data are coming, or someone asks whether it is ready.

Turn a brief or existing feature into testable requirements: behavior, acceptance criteria, quality constraints, and data and permission rules. Use when notes or a concept need FR/NFR requirements or acceptance criteria before design or build, or when checking which requirements a shipped feature meets.

Plan or improve a repository foundation: ownership, commands, configuration, tokens, and a runnable first slice. Use when starting a repository, when fresh checkout install or env setup fails, or when feature ownership is unclear.

Plan or revise which pages exist, how navigation is organized, what belongs in the URL, and which areas are public, signed-in, or admin. Use when creating IA for an app, site, dashboard, or prototype, renaming routes, or deciding whether view state belongs in the URL.

Implement one real workflow end to end in code, connecting interface, data, server permissions, persistence, and recovery, then verify it. Use when turning a mock or prototype path into a working feature, wiring a feature to a real API or database, or fixing writes that duplicate or fail to persist.

Choose or revisit a product stack using rendering, data, deployment, and maintenance constraints. Use when comparing frameworks, when SEO, auth, or deploy targets constrain the choice, or when revisiting an existing stack.

Audit an existing screen, component, or spec for the states people hit outside the happy path, and define what each shows and how users recover. Use when a screen shows blanks or endless spinners, loses input on failure, or needs loading, empty, error, permission, expired-session, offline, or retry coverage.

Audit an existing design system of tokens, components, and shared layouts for drift and duplicates, then plan fixes by user impact with evidence and a migration path. Use when components duplicate each other, values drift from the tokens, themes or focus rings break, or DESIGN.md needs updating before new UI.

Create or extend a small token system: semantic roles for surface, text, action, border, focus, and status, with contrast-checked theme pairs and type, spacing, and radius scales that components consume. Use when starting a UI foundation, turning brand colors into usable roles, when hardcoded colors or spacing multiply, or before building components or shells.