skills

Guided UI redesign intake and critique for pointed-at product surfaces. Use when the user writes /redesign, says "redesign this", "what should change about this UI", asks Codex or Claude to critique a screenshot, browser-visible screen, component, route, dashboard, form, workflow, or small UI fragment, or wants questions plus suggestions before implementation. Ground in visible UI evidence, apply Design of Everyday Things principles, ask targeted redesign questions, suggest concrete UX/UI changes, and stop at a redesign brief or handoff. Do not use for full product redesign engagements with /design.md state files (use design-loop), approved implementation plans (use product-design, calm-ui, or ui-principles as appropriate), or non-UI code work.

Summarize recent merged, deployed, or shipped work from the current repository into a clear team update. Use when the user asks what shipped, what merged today/yesterday/this week, what changed recently, or for a non-technical update, release note, changelog summary, stakeholder recap, or customer-facing/internal team announcement based on recent PRs or commits.

Turn a rough objective into a strong, evidence-backed goal for an AI coding agent, using lightweight codebase exploration when the objective depends on repository context. Use when the user writes `/write-goal`, asks to draft or tighten an agent goal, says "turn this into a goal" or "turn this into a /goal", or wants help making an objective measurable, repo-aware, and bounded. Produce a Codex `/goal` command only when the target agent supports it or the user asks for it; otherwise produce a portable agent goal block. Do not activate, pause, resume, clear, or complete goals unless the user explicitly asks for lifecycle management; this skill writes goal text for the user to review.

Apply a restrained, Swiss/Japanese/Scandinavian/German-influenced product design system when building or refining UI in React, Next.js, TypeScript, and shadcn/ui — the stack-specific binding of the ui-principles core, with concrete numbers. Use when the user asks to build, refine, critique, redesign, or review a page, screen, component, form, table, dashboard, layout, or other frontend interface in a React, Next.js, TypeScript, or shadcn/ui project. For stacks without React/shadcn (plain HTML/CSS, Vue, Svelte, emails, server-rendered templates), use ui-principles instead. Do not use for marketing sites, landing pages, non-UI work, or requests for bold, playful, maximalist, or otherwise expressive aesthetics.

Create and maintain a single-file design system (ds.tsx) for layout primitives and prose typography. Enforces semantic HTML, one-file constraint, cn() escape hatches, and the layout/content separation principle. Two variants — Tailwind and CSS. Use when the user asks to create a design system, add ds.tsx, set up layout primitives, build a typography system, or scaffold page structure. Do not use for component libraries, marketing page design, or shadcn/ui component customization.

Product design critique and approved implementation workflow for existing product experiences. Use when the user writes `/product-design`, asks for a product design critique, UX critique, Design of Everyday Things / DOET review, critique-and-implement pass, or wants to improve a screen, flow, route, dashboard, form, onboarding, workflow, or product experience. Ground in screenshots, browser state, routes, code, docs, and product context; critique first, propose a concrete implementation plan, then wait for approval before editing. Do not use for pure visual styling without product intent (use calm-ui), greenfield UI creation, or behavior-preserving cleanup after a finished change (use clean-up).

The framework-agnostic core of a calm, restrained UI system — rules, not numbers — built on seventeen principles: one alignment spine, deliberate symmetric padding, hierarchy built space → color → weight → size, rare color, honest interactive states, and designed empty/loading/error states. Use when building, refining, or reviewing a page, component, form, table, dashboard, layout, or screen on a stack WITHOUT React/Next.js/shadcn (plain HTML/CSS, Vue, Svelte, emails, server-rendered templates), or when the user invokes /ui-principles by name or asks for framework-agnostic UI principles. For React, Next.js, TypeScript, or shadcn/ui projects, use calm-ui — the stack-specific binding of these same principles with concrete numbers. Do not use for bold, playful, maximalist, or marketing-splash designs.

Take a pull request the last mile — workspace-safe checkout, live PR state, release-blocking findings, verification on the PR head, real-browser UI smoke, merge readiness, merge, and post-merge production verification. Use when the user asks to prepare, verify, smoke test, merge, ship, or get a PR ready or live, especially by PR number. For line-by-line code review of the diff itself, prefer the agent's built-in review commands and fold their findings into this skill's readiness verdict; this skill owns everything around that review.

Apply Pragmatic Programmer principles to greenfield, prototype, or framework-agnostic feature work where there is no existing-codebase design gate. Enforces ETC (Easy to Change), real DRY, tracer bullets, orthogonality, broken windows, and good-enough discipline. Use when the user asks for pragmatic build discipline on a new standalone feature, throwaway prototype, spike, script, endpoint, module, or system. Do not use for feature work in an existing codebase (use software-design), one-line fixes, typo corrections, pure product/UX work, or purely cosmetic changes.

Guide feature design and implementation in existing codebases. Based on A Philosophy of Software Design, with Pragmatic Programmer build discipline and conditional React/Next.js App Router constraints. Use when the user asks to add, implement, build, or scaffold a new feature, endpoint, module, route, component, hook, or system. Explore the existing system, frame complexity, design twice with concrete interfaces, wait for approval, then build with tracer bullets and repo-specific constraints. Do not use for greenfield projects, pure product/UX rework of existing experiences (use product-design), behavior-preserving cleanup after a finished change (use clean-up), or trivial one-line fixes.

Run the AI design-engineer loop on a product's UI, fully standalone. If the repo has no design/ system yet, bootstrap one from the codebase itself — read the code and product, write a point of view (POV.md), derive the constraint system (tokens.json, UI_RULES.md, PATTERNS.md) from the values already in use. Then run one iteration per session — pick a surface from the backlog, implement it against the tokens, screenshot light/dark at desktop and mobile widths, critique against the rules, fix until clean, promote reusable patterns, and stop at a human review gate. Use whenever the user types /design-loop, asks to "run the design loop", "redesign this screen against the system", "take this surface to world-class", "bootstrap a design system for this app", or references their design/ state files (POV.md, UI_RULES.md, tokens.json, PATTERNS.md, DECISIONS.md, BACKLOG.md) and asks to advance the design work.

Make a just-finished fix or feature belong in the codebase — conform it to local conventions and tie off loose ends, without changing behavior. Triggers right after the user finishes a change and says things like "clean this up", "make it fit", "tie off loose ends", "make this maintainable", "make it fit the codebase". Operates only on the recent diff and the files it touched. Do not use for greenfield code, for general code-quality passes on untouched code unrelated to a recent change (use thermo-nuclear-code-quality-review for strict structural review), for product/UX rework of existing screens or flows that predate this change (use `product-design`), for designing something new (use `software-design`), or while the feature is still unfinished — finish it first; this pass preserves behavior, it does not add it.

Teach the human a session, change, file, function, bug, PR, design decision, or broader concept until they can demonstrate deep understanding. Use when the user writes `/explain`, `/ explain`, "please explain this to me", asks to understand something deeply or more broadly, requests ELI5/ELI14/ELII, or wants to be quizzed on problem, solution, tradeoffs, edge cases, and impact.

Run an extremely strict maintainability review for abstraction quality, giant files, spaghetti-condition growth, and structural code health. Use for a thermo-nuclear code quality review, thermonuclear review, deep code quality audit, especially harsh maintainability review, abstraction review, or PR review focused on structural simplification. Do not use for ordinary style-only cleanup or cosmetic nits.