@delegance/claude-autopilot 5.5.2 → 6.2.2

package/dist/src/core/schema-alignment/extractor/prisma.js

@@ -1,18 +1,73 @@
-export function extractFromPrisma(content) {
-    const entities = [];
-    // Match model blocks: model Name { ... }
-    const modelRe = /^model\s+(\w+)\s*\{([^}]+)\}/gm;
-    for (const modelMatch of content.matchAll(modelRe)) {
+const MODEL_RE = /^model\s+(\w+)\s*\{([^}]+)\}/gm;
+const FIELD_RE = /^\s+(\w+)\s+\S/gm;
+function parseModels(content) {
+    const models = new Map();
+    for (const modelMatch of content.matchAll(MODEL_RE)) {
         const table = modelMatch[1];
-        entities.push({ table, operation: 'create_table' });
+        const fields = new Set();
         const body = modelMatch[2];
-        // Match field lines: fieldName TypeName ...
-        const fieldRe = /^\s+(\w+)\s+\S/gm;
-        for (const fieldMatch of body.matchAll(fieldRe)) {
+        for (const fieldMatch of body.matchAll(FIELD_RE)) {
             const column = fieldMatch[1];
             if (column.startsWith('@') || column === 'id')
                 continue;
-            entities.push({ table, column, operation: 'add_column' });
+            fields.add(column);
+        }
+        models.set(table, fields);
+    }
+    return models;
+}
+/**
+ * Extract schema entities from a Prisma schema file.
+ *
+ * When `previousContent` is provided, only the diff (added/removed fields,
+ * new/dropped tables) is emitted — this avoids over-reporting when a user
+ * touches schema.prisma for any reason (adding one field, editing a comment)
+ * and every long-existing field gets re-checked against type/API/UI layers.
+ *
+ * When `previousContent` is null/undefined, every model and field is emitted
+ * — the original "all entities are new" behavior used as a fallback when git
+ * history isn't available.
+ */
+export function extractFromPrisma(content, previousContent) {
+    const current = parseModels(content);
+    if (previousContent === undefined || previousContent === null) {
+        const entities = [];
+        for (const [table, fields] of current) {
+            entities.push({ table, operation: 'create_table' });
+            for (const column of fields)
+                entities.push({ table, column, operation: 'add_column' });
+        }
+        return entities;
+    }
+    const previous = parseModels(previousContent);
+    const entities = [];
+    for (const [table, currentFields] of current) {
+        const previousFields = previous.get(table);
+        if (!previousFields) {
+            // New table — emit create_table + add_column for every field
+            entities.push({ table, operation: 'create_table' });
+            for (const column of currentFields)
+                entities.push({ table, column, operation: 'add_column' });
+            continue;
+        }
+        for (const column of currentFields) {
+            if (!previousFields.has(column))
+                entities.push({ table, column, operation: 'add_column' });
+        }
+        for (const column of previousFields) {
+            if (!currentFields.has(column))
+                entities.push({ table, column, operation: 'drop_column' });
+        }
+    }
+    // Second pass — entirely dropped models. The first loop only iterates
+    // `current`, so a model present in `previous` but removed from `current`
+    // would never emit any entity, leaving stale references in type/API/UI
+    // layers undetected. Caught by Cursor Bugbot on PR #44 (MEDIUM).
+    for (const [table, previousFields] of previous) {
+        if (current.has(table))
+            continue;
+        for (const column of previousFields) {
+            entities.push({ table, column, operation: 'drop_column' });
         }
     }
     return entities;

package/dist/src/core/schema-alignment/git-history.d.ts

@@ -0,0 +1,19 @@
+/**
+ * Read the previous version of a file from git, comparing against `base`.
+ * Returns null if the file has no git history at that ref (untracked,
+ * brand-new, not in a repo, or the ref doesn't resolve) — callers should
+ * fall back to whole-file extraction in that case.
+ *
+ * When `base` is omitted, the default is CI-aware (see `resolveDefaultBase`):
+ * - GitHub Actions PR build → `origin/<GITHUB_BASE_REF>`
+ * - GitLab MR build → `origin/<CI_MERGE_REQUEST_TARGET_BRANCH_NAME>`
+ * - everything else → `HEAD~1`
+ *
+ * Reading from `HEAD` directly is wrong in CI (any post-commit context):
+ * `HEAD` IS the current commit, so the diff against the working-tree file
+ * is always empty and no schema entities are emitted. Caught by Cursor
+ * Bugbot on PR #44 (HIGH); the multi-commit-PR variant of the same bug
+ * caught as a MEDIUM follow-up on the rebased commit.
+ */
+export declare function getPreviousFileContent(filePath: string, cwd?: string, base?: string): string | null;
+//# sourceMappingURL=git-history.d.ts.map

package/dist/src/core/schema-alignment/git-history.js

@@ -0,0 +1,53 @@
+import { spawnSync } from 'node:child_process';
+import * as path from 'node:path';
+/**
+ * Resolve the default base ref for git diffs in a CI-aware way.
+ *
+ * Priority: `GITHUB_BASE_REF` (GitHub Actions PR builds), then
+ * `CI_MERGE_REQUEST_TARGET_BRANCH_NAME` (GitLab MR builds), then `HEAD~1`
+ * for local / single-commit contexts. Branch-name env vars are prefixed
+ * with `origin/` so `git show <ref>:<file>` resolves to the
+ * remote-tracking-branch tip (the actual merge base).
+ *
+ * Caught + extended by Cursor Bugbot follow-up on PR #44 (MEDIUM): a static
+ * default of `HEAD~1` is wrong for multi-commit PRs — it points at the
+ * previous commit on the branch, not the merge base.
+ */
+function resolveDefaultBase() {
+    const ghBase = process.env.GITHUB_BASE_REF;
+    if (ghBase && ghBase.length > 0)
+        return `origin/${ghBase}`;
+    const glBase = process.env.CI_MERGE_REQUEST_TARGET_BRANCH_NAME;
+    if (glBase && glBase.length > 0)
+        return `origin/${glBase}`;
+    return 'HEAD~1';
+}
+/**
+ * Read the previous version of a file from git, comparing against `base`.
+ * Returns null if the file has no git history at that ref (untracked,
+ * brand-new, not in a repo, or the ref doesn't resolve) — callers should
+ * fall back to whole-file extraction in that case.
+ *
+ * When `base` is omitted, the default is CI-aware (see `resolveDefaultBase`):
+ * - GitHub Actions PR build → `origin/<GITHUB_BASE_REF>`
+ * - GitLab MR build → `origin/<CI_MERGE_REQUEST_TARGET_BRANCH_NAME>`
+ * - everything else → `HEAD~1`
+ *
+ * Reading from `HEAD` directly is wrong in CI (any post-commit context):
+ * `HEAD` IS the current commit, so the diff against the working-tree file
+ * is always empty and no schema entities are emitted. Caught by Cursor
+ * Bugbot on PR #44 (HIGH); the multi-commit-PR variant of the same bug
+ * caught as a MEDIUM follow-up on the rebased commit.
+ */
+export function getPreviousFileContent(filePath, cwd = process.cwd(), base = resolveDefaultBase()) {
+    const relPath = path.isAbsolute(filePath) ? path.relative(cwd, filePath) : filePath;
+    const result = spawnSync('git', ['show', `${base}:${relPath}`], {
+        cwd,
+        encoding: 'utf8',
+        timeout: 5000,
+    });
+    if (result.status !== 0)
+        return null;
+    return result.stdout;
+}
+//# sourceMappingURL=git-history.js.map

package/dist/src/core/static-rules/rules/brand-tokens.js

@@ -36,8 +36,8 @@ function buildPalette(brandCfg, cwd) {
 export const brandTokensRule = {
     name: 'brand-tokens',
     severity: 'warning',
-    async check(touchedFiles, config = {}) {
-        const brandCfg = config.brand;
+    async check(touchedFiles, ctx = {}) {
+        const brandCfg = ctx.config?.brand;
         if (!brandCfg)
             return [];
         const cwd = process.cwd();

package/dist/src/core/static-rules/rules/schema-alignment.js

@@ -1,5 +1,6 @@
 import { detect } from "../../schema-alignment/detector.js";
 import { extract } from "../../schema-alignment/extractor/index.js";
+import { getPreviousFileContent } from "../../schema-alignment/git-history.js";
 import { scanLayers } from "../../schema-alignment/scanner.js";
 import { runLlmCheck } from "../../schema-alignment/llm-check.js";
 function isDestructive(entity) {
@@ -50,15 +51,24 @@ function structuralFinding(result, layer, defaultSev, sourceFile) {
 export const schemaAlignmentRule = {
     name: 'schema-alignment',
     severity: 'warning',
-    async check(touchedFiles, config = {}) {
-        const saConfig = config['schema-alignment'];
+    async check(touchedFiles, ctx = {}) {
+        const saConfig = ctx.config?.['schema-alignment'];
         if (saConfig?.enabled === false)
             return [];
         const cwd = process.cwd();
         const migrationFiles = detect(touchedFiles, saConfig);
         if (migrationFiles.length === 0)
             return [];
-        const allEntities = migrationFiles.flatMap(f => extract(f).map(entity => ({ entity, sourceFile: f })));
+        // For Prisma schema files, fetch the previous version from git so we only
+        // emit entities for what actually changed in this diff. SQL migrations
+        // are inherently a diff already; the SQL extractor ignores
+        // `previousContent`, so skipping the `git show` spawn there avoids pure
+        // waste (Bugbot LOW on PR #44).
+        const allEntities = migrationFiles.flatMap(f => {
+            const isPrisma = f.endsWith('.prisma');
+            const previousContent = isPrisma ? getPreviousFileContent(f, cwd) : null;
+            return extract(f, previousContent).map(entity => ({ entity, sourceFile: f }));
+        });
         if (allEntities.length === 0)
             return [];
         const scanResults = scanLayers(allEntities.map(e => e.entity), cwd, saConfig);
@@ -75,7 +85,7 @@ export const schemaAlignmentRule = {
             return [];
         const defaultSev = saConfig?.severity ?? 'warning';
         const llmEnabled = saConfig?.llmCheck !== false;
-        const engine = config['_engine'];
+        const engine = ctx.engine;
         // Structural mode — always compute these so we can fall back if LLM path yields nothing
         const structural = [];
         for (const { result: r, sourceFile } of gapResults) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@delegance/claude-autopilot",
-  "version": "5.5.2",
+  "version": "6.2.2",
   "type": "module",
   "description": "Autonomous development pipeline for Claude Code: brainstorm → spec → plan → implement → migrate → validate → PR → review → merge. Multi-model, local-first, every phase a skill you can intervene in.",
   "keywords": [
@@ -52,6 +52,7 @@
   ],
   "scripts": {
     "test": "node scripts/test-runner.mjs",
+    "test:adapters:live": "node --test --import=tsx tests/adapters/live/vercel.cert.ts tests/adapters/live/fly.cert.ts tests/adapters/live/render.cert.ts",
     "typecheck": "tsc --noEmit",
     "build": "tsc -p tsconfig.build.json && node scripts/post-build-rewrite-imports.mjs",
     "prepublishOnly": "npm run build && npm test",

package/scripts/autoregress.ts

@@ -259,7 +259,7 @@ async function cmdGenerate(args: string[]): Promise<number> {
     let snapContent: string;
     try {
       const response = await client.responses.create({
-        model: process.env.CODEX_MODEL ?? 'gpt-5.3-codex',
+        model: process.env.CODEX_MODEL ?? 'gpt-5.5',
         instructions: 'You write TypeScript snapshot tests. Output ONLY the file contents, no markdown fences.',
         input: prompt,
         max_output_tokens: 2000,

package/skills/claude-autopilot.md

@@ -47,7 +47,7 @@ Each phase writes its output to disk. Claude can stop, the user can edit the art
    - PR review finds criticals → fix on branch, push, re-review (max 2 rounds).
    - Bugbot finds real bugs → fix, push, re-triage (max 3 rounds).
    - Unrecoverable failure → stop, report what completed, show what remains.
-4. **Codex review is part of the loop, not optional.** The pipeline explicitly dispatches to `gpt-5.3-codex` for spec review, plan review, and PR review. This is the multi-model moat — don't skip it.
+4. **Codex review is part of the loop, not optional.** The pipeline explicitly dispatches to `gpt-5.5` for spec review, plan review, and PR review. This is the multi-model moat — don't skip it.
 5. **Skills are swappable.** `review-2pass` and `council` are alternative review phases — a user can configure which runs. The pipeline doesn't hardcode Claude or Codex.
 
 ## Phase outputs

package/skills/make-interfaces-feel-better/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: make-interfaces-feel-better
+description: Craft-and-feel polish for an interface that already works correctly and is already simple. Use when the user says "feels off", "feels clunky", "not quite right", "doesn't feel polished", "lacks soul", "feels cheap", "add some life to it", "make it feel expensive", "feels like AI slop", or wants motion/typography/microcopy/color work that isn't about fixing bugs or alignment. This is the vibes layer — assumes correctness and subtraction are already handled. If the screen is broken or cluttered, route to /ui-ux-pro-max or /simplify-ui first. Complements frontend-design:frontend-design (creative vision) but is scoped to tuning what exists.
+---
+
+# Make interfaces feel better — the craft layer
+
+This skill is for the pass where the interface already *works* and is already *simple*, but still feels mediocre. You are tuning emotion, not structure. If the user hasn't had the basics fixed yet, recommend `/ui-ux-pro-max` and `/simplify-ui` first; great feel on top of a broken layout is lipstick.
+
+## The diagnostic
+
+Before touching anything, ask yourself what specific feeling is off. Interfaces usually fail one of five feels:
+
+1. **Cheap** — cramped, low-contrast, unbranded, no texture, inconsistent.
+2. **Cold / clinical** — correct but soulless. Efficient but no character.
+3. **Heavy / laggy** — transitions stutter, state changes snap, nothing feels alive.
+4. **Disorganized** — elements fight for attention; no clear visual hierarchy.
+5. **Nervous / fussy** — too many animations, too many chips, too many accent colors.
+
+The fix for each is different. Name the feeling first, then apply the matching lever below.
+
+## Levers — in order of impact-per-minute
+
+### 1. Typography (highest leverage)
+
+- **Pair a display face with a body face.** One distinctive (Playfair, Fraunces, Söhne, Tiempos, Inter Display) + one refined (Inter, Figtree, Söhne, IBM Plex, Geist). Don't use Inter for everything.
+- **Use the display only at top levels** — page title, card titles ≥ 18px. Everything else body.
+- **Tighten line-height on display** (1.1–1.2) and loosen on body (1.5–1.65).
+- **Letter-spacing for uppercase** — eyebrows and section labels get `letter-spacing: 0.05em` or more.
+- **One tabular-nums for numeric data** — `font-variant-numeric: tabular-nums` on any column of amounts makes them snap into alignment.
+
+### 2. Color & contrast
+
+- **One dominant color, one accent, one destructive. No fourth.**
+- **Backgrounds are off-white or off-black, never pure.** `#F7F8F6`, `#0B0D0A` — feel warmer than `#FFFFFF` / `#000000`.
+- **Shadows with color** — `box-shadow: 0 2px 12px rgba(brand-color, 0.08)` feels branded; `rgba(0,0,0,0.08)` feels generic.
+- **Gradients only on one element at a time.** Usually the primary CTA or the hero. Gradients everywhere = AI-slop.
+
+### 3. Motion
+
+- **Page-load stagger is cheap delight.** 40–80ms stagger on cards/rows hitting the viewport; nothing fancier.
+- **Easing: `cubic-bezier(0.22, 1, 0.36, 1)` for enter/exit.** Not `ease-in-out`.
+- **200–280ms for small transitions, 400–600ms for modals/layouts.** Outside that range feels wrong.
+- **Never animate what the user didn't cause.** Auto-pulsing "new" badges are hostile.
+- **Respect `prefers-reduced-motion`** — drop transitions to 0.01s, keep only opacity/color changes.
+
+### 4. Microcopy
+
+- **Button verbs specific to the action.** Not "Submit" — "Send quote for review."
+- **Empty states with personality.** "No quotes yet. Start one — it takes about 3 minutes." Beats "No data."
+- **Error messages that acknowledge** — "That's not quite right — X needs to be Y" rather than "Invalid input."
+- **Success states that celebrate proportionally.** Saved draft = small checkmark. Bound a policy = confetti-adjacent.
+- **Loading copy that sets expectations.** "Matching you with carriers… usually 5 seconds" > spinner alone.
+
+### 5. Texture & depth
+
+Not every interface needs these, but they're how screens stop feeling generic:
+- **Noise overlay at 2–4% opacity** on dark backgrounds. Kills the plastic look.
+- **Subtle inner shadow on inputs** — `inset 0 1px 0 rgba(255,255,255,0.4)` on light themes suggests depth.
+- **Asymmetric card padding** — e.g., `24px 24px 20px 24px` sometimes feels better than all-24 because humans scan top-to-bottom.
+- **Left-align eyebrow decoration** — a 2px × 18px accent-color rule before a section label reads as editorial, not chrome.
+
+### 6. The small details
+
+- **Focus rings that feel on-brand** — `box-shadow: 0 0 0 3px rgba(brand, 0.2)` beats the default blue browser ring.
+- **Checkmark animation on save** — 300ms stroke-dash reveal, not a static green dot.
+- **Hover states that change border color**, not scale or shadow (which feel toy-like on dense forms).
+- **Caret-color matched to brand.** `caret-color: var(--brand)`.
+- **Chip alignment with inline icons** — baseline-align the icon to the text, don't center — centering looks off for small text.
+
+## What to avoid (AI-slop tells)
+
+- Purple-to-pink gradients on white.
+- "Gradient text" for things that aren't hero titles.
+- Emoji in UI chrome (buttons, headers).
+- `font-family: 'Inter', sans-serif` as the only typeface.
+- Drop-shadows the same size on cards, buttons, and modals (varied elevation is the whole point).
+- Buttons with `border-radius: 9999px` that are 32px tall (pill at small scale reads as "claimed to be premium, actually built in 20 min").
+- Glass-morphism backdrops without a real background image behind them.
+
+## Workflow
+
+1. **Name the feel.** In one sentence, write what's wrong. "Feels cheap because inputs have no shadow and everything is pure white on pure white." This grounds the rest.
+2. **Apply at most 3 levers from the list above.** Do not touch everything — diminishing returns.
+3. **Reload and look away and back.** Judge fresh, not against your memory of before.
+4. **Name one thing you resisted adding.** This keeps you honest — feel upgrades are often about resisting maximalism, not piling it on.
+5. **Show the user which levers you pulled** and invite them to push back on any that felt wrong.
+
+## Red flags during the pass
+
+If you catch yourself adding:
+- A new color variable that isn't in the design system
+- A third weight of the display font
+- An animation > 600ms
+- A shadow on a default-state button
+- An emoji inside a form label
+
+…stop. You're adding where you should be tuning.
+
+## Interactions
+
+- Runs best on a screen that already passed `/ui-ux-pro-max` and `/simplify-ui`.
+- Can safely coexist with `/ui` for a combined sweep.
+- If the user wants a redesign, escalate to `frontend-design:frontend-design`.

package/skills/simplify-ui/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: simplify-ui
+description: Ruthless subtraction pass on an existing UI — visual/UX reduction only. Use when the user says "cut it down", "too much going on", "too cluttered", "remove noise", "pare down", "less is more", "it's too busy", or wants the page trimmed without rebuilding it. This is the "remove before adding" lens — complementary to /ui (full polish pass), /ui-ux-pro-max (correctness audit), and /make-interfaces-feel-better (craft layer). For code-level deduplication, use the plugin /simplify instead.
+---
+
+# Simplify — remove before you add
+
+You are looking at a UI and cutting what doesn't earn its place. The default answer is **delete**. Every element has to justify why it survives. If you can't state its purpose in a short sentence, it goes.
+
+## The guiding question
+
+For every visible element on the screen, answer:
+
+> "What would break for the user if this weren't here?"
+
+If the answer is "nothing" or "aesthetics", delete it. If the answer names a concrete user failure, keep it — and then see if it can be smaller.
+
+## What to cut, in priority order
+
+### Tier 1 — cut without thinking
+
+1. **Section headers above single-item sections.** "LIABILITY COVERAGE" over a single field is structural vanity.
+2. **Helper text that restates the label.** "Enter your email address" under an "Email" field. Pick one.
+3. **Placeholders that duplicate labels.** Ditto.
+4. **Status pills identical to adjacent counts.** "5/5" badge next to a "5 of 5 complete" progress bar.
+5. **Default-zero values displayed as content.** `$0`, `0%`, `null` — render as empty.
+6. **Decorative icons** that don't carry meaning or affordance. Briefcase next to "Company" is ornament.
+7. **Explanatory captions** for patterns the user already knows ("Click Submit to submit").
+8. **"Powered by…" footers on internal tools.**
+9. **Animated spinners on < 200ms operations.** They flash and look broken.
+
+### Tier 2 — cut after a second look
+
+1. **Duplicate buttons.** "Save" at top and bottom of a form — keep one, usually the bottom if the form is long.
+2. **Multiple paths to the same action.** A "Create quote" primary button + a "+" FAB + a "New quote" menu item.
+3. **Breadcrumbs on 2-level-deep pages.** Overkill; use a back button.
+4. **Card shadows stacked on card borders.** Pick one.
+5. **Grid lines *and* alternating row backgrounds.** Pick one.
+6. **Count/progress indicators that update instantly.** If the user answered the field, they know.
+7. **Summary sentences above tables** that restate what the table shows. ("This table shows quotes. There are 3 quotes.")
+8. **Emoji or flag icons** next to text that already says the same thing.
+9. **Confirmation dialogs for non-destructive actions.** "Save draft?" — just save.
+
+### Tier 3 — cut with caution (verify with the user)
+
+1. **Tooltips on self-explanatory controls.** If the icon is standard (× for close), no tooltip needed — unless a11y is the reason.
+2. **Onboarding hints that persist after first use.**
+3. **Tutorial steps that could be inferred from labels.**
+4. **Analytics-only elements** that don't serve the user (tracking pixels belong in code, not chrome).
+
+## What not to cut (hold the line)
+
+- Labels, even when obvious — they are your a11y surface.
+- Error messages — always keep; tune the copy under `/make-interfaces-feel-better`.
+- Validation — never cut; maybe defer to blur instead of on-change.
+- Skip links and screen-reader-only text.
+- The single "Undo" or "Back" that lets users recover.
+
+## Density rules after simplification
+
+Once you've cut:
+- **3–6 fields per card.** Fewer = sleepy; more = oppressive.
+- **One accent color dominant per card.** Not one per chip.
+- **At most 2 type sizes per card** (label + input/value). Title of the card is the third.
+- **One CTA per screen region.** Multiple = the user has to choose, and they'd rather not.
+- **Zero horizontal scroll.** If the layout forces it on common widths, the layout is wrong.
+
+## Workflow
+
+1. **Screenshot or open the screen.** Read every visible string. Don't cut blind.
+2. **List every distinct element.** Cards, headers, chips, buttons, helper text, icons, images.
+3. **Mark each: keep / cut / reduce.** "Reduce" means the element stays but smaller/shorter/less prominent.
+4. **Cut Tier 1 items immediately.** No discussion.
+5. **Surface Tier 2/3 cuts as proposals** to the user before applying.
+6. **After the cut, measure.** Did vertical density improve? Did the primary action get more visible? If neither, you cut the wrong things.
+
+## Micro-patterns
+
+- **Collapse single-field sections into the parent card.** Don't delete the field, delete the section wrapper.
+- **Merge two adjacent chips with the same color into one.** "Required + Auto-filled" → "Auto-filled (required)".
+- **Replace "X of Y" with "Y - X remaining"** when remaining is what the user cares about.
+- **Fold secondary actions into an overflow menu (⋯).** Don't show 5 buttons when 1 primary + ⋯ works.
+- **Use whitespace as a divider** before reaching for a `<hr>` or border.
+
+## Red flags that you're over-cutting
+
+- Users can't tell which field is required.
+- A keyboard-only user can't move through the form.
+- A screen-reader user can't distinguish regions.
+- The page looks like a wireframe, not a product.
+- You removed something and then had to re-add it in the next session.
+
+## Interactions
+
+- Runs best after `/ui-ux-pro-max` (knows what's broken) and before `/make-interfaces-feel-better` (which adds back *quality*, not noise).
+- Combine with `/ui` for a full pass in one shot.
+- Do not run on a screen that's already minimalist — you'll cut into muscle.
+
+## One rule above all
+
+> Every element survives by earning its pixel count.
+
+If you wouldn't fight to keep it at the next design review, delete it now.

package/skills/ui/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: ui
+description: Opinionated full-pass UI polish on an existing screen — audit, simplify, align, polish in one shot. Use when the user wants to condense, level, align, clean up, tighten, or "make it feel better." Trigger phrases include "condense the UI", "level these out", "clean up and condense", "waste of space", "align better", "feels cluttered", "tighten this up", "polish", "not a great use of space", "make it look right", "fix the alignment". Self-contained — runs all four lenses internally. For subtraction-only, use /simplify-ui. For correctness-only audit, use /ui-ux-pro-max. For craft/feel-only, use /make-interfaces-feel-better. For greenfield design, escalate to frontend-design:frontend-design.
+---
+
+# UI polish pass
+
+You are doing a targeted polish of an **existing** UI, not a greenfield design. The user already has something on screen and wants it to feel better. Match their energy — if they send a screenshot with one complaint, fix that complaint first; don't redesign the whole thing.
+
+Run the four steps below **in order**. Skip steps that don't apply — but never skip step 1 (audit).
+
+## Scope contract — what this skill will and won't do
+
+**Will:** improve hierarchy, spacing, alignment, copy density, interaction states, typographic balance, and visual finish on the existing screen. Touch the components that produce what's on screen and the styles they inherit.
+
+**Won't:** redesign the entire flow, change the data model, restructure information architecture beyond the current screen, introduce a new visual identity, or add net-new features. Preserve the product's existing intent.
+
+If the request needs any of the "won't" items, stop and route:
+- New screen / no concept yet → `frontend-design:frontend-design`
+- Subtraction-only ("just cut, don't polish") → `/simplify-ui`
+- Correctness audit only ("what would a senior designer catch?") → `/ui-ux-pro-max`
+- Craft/feel only ("feels off, lacks soul") → `/make-interfaces-feel-better`
+
+## 1. Audit — look at it, don't guess
+
+Before touching code:
+- **Look at the actual screen.** If the user sent a screenshot, use Read on it. Don't edit blind.
+- **Measure the complaint.** Read the user's words precisely. "Condense" ≠ "redesign." "Level these out" = fix baseline alignment of specific fields, not every field on the page.
+- **Trace the render path.** Find the component(s) that produced what's on screen. Don't assume — grep for the visible strings (section titles, labels, button text) to locate the exact file/line.
+- **Capture the surrounding system.** Note what styles the component inherits: global input classes, grid wrappers, parent padding, font families. The bug is usually upstream of the visible element.
+
+Common blind spots to probe:
+- A "grid alignment issue" is almost always wrapper-margin mismatch, not the grid itself.
+- A "wasted space" complaint is usually `maxWidth` + grid columns + single-field groups compounding.
+- A "doesn't feel right" complaint usually points at typographic hierarchy, not color.
+
+## 2. Simplify — subtract first, add never (almost never)
+
+Before adding anything, ask: **what can I remove?**
+
+Remove these first, in priority order:
+1. **Redundant containers and wrappers.** One `<div>` can usually replace three.
+2. **Subcategory headers for 1-item groups.** "LIABILITY COVERAGE" above a single field burns a row for zero signal. Collapse into the parent.
+3. **Helper text that restates the label.** "Enter your email here" under an "Email" field is noise.
+4. **Default-zero values displayed as content.** `$0` and `0` with grey styling look like empty state — just leave empty.
+5. **Summary/status chips that say what the count already says.** "5 fields required" + a "5/5" badge = one of them goes.
+6. **Decorative icons that don't map to action or meaning.** A briefcase next to "Company Information" is decoration; a checkmark next to "Complete" is meaning. Keep meaning, cut decoration.
+7. **Multiple font sizes in the same row.** If a label and its chip are different sizes for no reason, they should match.
+
+If something genuinely has to be added, it must carry its weight. A new indicator justifies itself by preventing a user mistake or accelerating a decision; otherwise it's noise.
+
+## 3. Align — everything lives on a grid
+
+Misalignment is mostly caused by **inconsistent margins**, not inconsistent grids. Audit these in order:
+
+1. **Wrapper margins across sibling fields.** If `<DateInput>` returns a div with `mb-3` and `<CurrencyInput>` returns a div with `mb-1.5`, an `alignItems: 'end'` grid will put them at different baselines — by exactly the margin delta. Normalize wrappers before touching the grid.
+2. **Input heights across field types.** Date, select, currency, text, and yes/no all need the same `py` value, same `border-width`, same font-size. One `py-3` among a row of `py-2`s looks like a bug to the eye even if the user can't name it.
+3. **Label block heights.** Use `min-h-[20px]` on all labels so a 1-line label and a 1-line label-with-chip occupy the same vertical footprint. Labels that wrap to 2 lines *because they have to* are fine; labels that appear to wrap because the column is 20px too narrow are not.
+4. **Grid column strategies in the same card.** Don't mix `repeat(3, 1fr)` and `repeat(auto-fill, minmax(260px, 1fr))` in sibling rows — column widths will jump between rows for no reason the user understands.
+5. **`align-items`: prefer `end` for forms.** Anchoring inputs to the row's bottom means they line up regardless of how many lines the labels or helper texts above them take.
+
+When a "leveling" complaint comes in, the fix is almost always one of (1) or (2). Check those before rewriting the grid.
+
+## 4. Polish — small things that disproportionately matter
+
+These are low-effort, high-payoff tweaks. Apply them in this order:
+- **Sentence-case labels.** "Requested Effective Date" → "Requested effective date" unless the product strongly prefers title case.
+- **Tighten the padding scale.** `py-2 px-3` for inputs, `p-3` / `p-4` for cards, `gap-2` / `gap-3` for flex rows. Don't invent new values.
+- **Right-size interactive affordances.** Yes/No buttons should match adjacent input heights (same `py`). "Submit" buttons should be one step larger, not three.
+- **Consistent green/red semantics.** One accent color for success (`#40C288` / green-100 bg), one for destructive — don't introduce a third.
+- **Chip restraint.** If multiple chips can appear on one label ("Auto-filled", "Suggested", "Required"), reserve one color per meaning and hide conflicting combinations (e.g., a "Suggested" chip disappears the moment "Auto-filled" applies).
+- **Hover states that mean something.** Border color shift > shadow shift > scale transform. Don't use animation where color communicates the change.
+- **Motion only for state changes the user caused.** Page-load staggers are cheap delight; surprise-wiggle on data arrival is usually annoying.
+
+## Opinionated defaults
+
+When the user hasn't specified, default to these and move on:
+- **Content width:** 1200px max. Sidebar + main = 220 + 980 with 24–32px gutters. Wider reads as "enterprise app with too many fields"; narrower cramps.
+- **Card padding:** `px-4 py-3`. Cards tighter than this feel underbaked; looser feels sleepy.
+- **Grid gap between fields:** `12px` horizontally, `12px` vertically. Don't exceed 16px unless there's a strong reason.
+- **Typography scale:** label 11–12px semibold, input text 14px regular, body 13px regular, section title 14–15px semibold. Avoid introducing a 4th or 5th size.
+- **Borders:** `1px solid` at all times. `border-2` reads as "please notice me" — reserve it for selected/active states, not defaults.
+- **Corner radius:** `rounded-lg` (8px) for inputs and cards, `rounded-full` only for pills/avatars.
+
+## Anti-patterns — flag these on sight
+
+- A single-field "section" with its own uppercase header.
+- `maxWidth` > 1280 on a form-heavy page.
+- `gap: 4` next to `gap: 16` inside the same card.
+- `mb-3` on some wrappers and `mb-1.5` on others, in the same grid.
+- `border-2` on non-selected default states.
+- Helper text that is grammatically a sentence but visually the same size as the label.
+- "Auto-filled" and "Suggested" chips shown simultaneously on one field.
+- Yes/No buttons noticeably taller than neighboring selects.
+- Progress bar counts that include optional fields in the denominator. "X of Y required" is what users actually want.
+- Content that expands to fill whatever width it's given (currency inputs stretched to 600px for a 6-digit number).
+
+## Workflow the user sees
+
+1. **Restate the complaint in one sentence** so the user knows you understood. ("Fields don't line up in Coverage Details" — not "let me analyze the UI.")
+2. **Diagnose out loud.** Say what's causing it. ("Date wrapper has `mb-3`, currency wrapper has `mb-1.5` — that's the 6px offset.")
+3. **Make the minimum edit that fixes it.** Don't bundle unrelated cleanup.
+4. **Say what was left alone and why**, if there are obvious nearby things you chose not to touch.
+5. **Don't commit** unless the user asked.
+
+## When to escalate
+
+Hand off to a different skill when:
+- Request is "design a new X from scratch" → `frontend-design:frontend-design`
+- Request is "write a comprehensive spec for the redesign" → `superpowers:writing-plans`
+- Request is "this feels bad, but I don't know why" and you've already done a polish pass → ask targeted questions before another round.
+
+## Verification
+
+After edits, state which complaint was addressed and which were not. If the user sent one screenshot showing one row of fields misaligned, don't report "condensed the whole page" — they'll suspect you did more than asked.
+
+If you can run the dev server and re-check visually, do. If you can't (backend-only session, no browser access), say so explicitly: "I can't verify visually — please reload and confirm."