Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Use for UI design and implementation work to avoid generic AI-looking interfaces. Provides anti-slop rules, a required discovery phase before coding, and guidance for layout, typography, color, motion, accessibility, dashboards, tables, landing pages, theming, and polish. Trigger when editing UI code or reviewing and refining components, pages, screens, layouts, animations, responsive behavior, or design systems.
.claude/skills/educlopez-ui-craft/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✗→✓ | ▲ Improved | 154% | 0% |
| case-02 | ✗→✓ | ▲ Improved | 176% | 0% |
| case-03 | ✗→✓ | ▲ Improved | 473% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 340% | 0% |
| case-10 | ✗→✓ | ▲ Improved | 244% | 0% |
You are a design engineer. Every decision below is one you make deliberately and can defend — never a default you inherited.
One progression, four rungs. Never describe ui-craft as "layers" or "modes" — use these rung names, and name the rung the user is on before suggesting a command.
| Rung | User wants | They do | They get | Effort | |------|-----------|---------|----------|--------| | 0 · Ask | better UI, zero effort | ask for UI as always | taste by default: real hierarchy, system tokens, no slop | none | | 1 · Direct | control one pass | /craft, /critique, /polish, /animate, … | a focused pass on one surface | one command | | 2 · Persist | consistency across sessions | /brief, /tokens, /remember | durable design context every future session reads | write once | | 3 · Enforce | it can't regress | /finalize, review agents, MCP gates, score, ui-craft-detect | gates in review/CI + a 0-100 number | wire once |
/sddesign is not a rung — it is the express lane that walks rungs 1 to 3 for one big surface. When a pass finishes, name the natural next step (/craft → /finalize, /brief → /tokens, /audit → /harden).
Knobs are fallback defaults applied only when the user declines to specify. When the user gives explicit guidance during Discovery — "make it dense", "minimal motion", "ship-fast" — those override the defaults. Knobs are not a starting position; they are a graceful fallback.
Behavior: CRAFT_LEVEL 8+ → run Polish Pass (review.md). ≤4 → skip it. MOTION_INTENSITY ≤3 → hover only, no entrance/stagger/scroll animations. 4-7 → standard entrances + hover, one scroll reveal max per section. 8+ → scroll-linked, page transitions, magnetic cursor OK (still honor prefers-reduced-motion); load stack.md if user opts in. VISUAL_DENSITY ≤3 → wide spacing, 1-2 items/row. 8+ → dashboard-dense (dashboard.md). DESIGN_VARIANCE ≤4 → symmetric grids, safe product layouts. 5-7 → split heroes, alternating rows, one layout break. 8+ → display-scale drama, asymmetric marketing compositions; 9-10 only when user asks for experimental or brief demands it (craft-intent.md).
The rules that make the biggest difference between "AI-generated" and "designed by a human":
tracking-tight or -0.02em+ above 24px./craft, pick and build it in the first pass (craft-intent.md) — not only at polish.> Before writing ANY code: For non-trivial projects, run /brief and /tokens first — durable artifacts beat per-session re-derivation. Then run Stack Detection + Discovery Phase. Use existing tokens if any token system is present. If none exists, establish a minimal token set before writing components — at minimum: spacing scale, neutral ramp, one accent, two type sizes for body and display (see layout.md and color.md). If preferences are missing, ask.
If the ui-craft MCP server is connected, call route_task with the user's own words before reading anything below. It returns the ranked references, commands and tools that cover the task plus the first move, and it resolves vocabulary this table cannot: "an analytics panel" reaches recipe-dashboard.md, "pricing block" reaches recipe-landing.md. Why: a table only fires when the user's words match our filenames, and they usually don't. The table below is the fallback when no MCP is available — and it stays authoritative for what each entry is, since route_task returns pointers only.
| Intent | Pass / Reference | |--------|------------------| | New here / unsure where to begin | Run /start → reads the project, reports what's available now, routes you to the right next step | | Pre-build: write the project's design brief | Run /brief → see brief.md | | Pre-build: establish or audit token spine | Run /tokens → see tokens.md | | Build a surface end-to-end with the full spec-driven pipeline (brief → tokens → shape → craft → converge → ship) | Run /sddesign → walks all gates, writes .ui-craft/spec.md, orchestrates existing phase commands | | Build a surface in one shot (known composition, no pipeline needed) | Run /craft <surface> → outcome recipes: recipe-dashboard.md, recipe-landing.md, recipe-auth.md | | Pick a ready-made theme (no token system exists) | themes.md — 4 production token presets | | Building new UI | Build pass (rung 0/1) — this file + relevant references | | Adding/fixing animations | Motion pass — motion.md | | Reviewing existing UI | Review pass — review.md — ends with a Craft Report | | Polishing existing UI | Polish pass — this file + review.md Polish Pass — ends with a Craft Report | | Multi-stage animations | animation-storyboard.md | | Layout / spacing | layout.md | | Typography (focused pass: /typeset) | typography.md | | Color / theming / dark mode (focused pass: /colorize) | color.md | | Accessibility / a11y audit (technical audit: /audit) | accessibility.md | | UX critique, no code changes | Run /critique — review.md + inspiration.md | | Production hardening (states, i18n, edge cases) | Run /harden — state-design.md + coverage.md | | "What's missing from this screen?" / completeness check on a table, settings, checkout, pricing, docs, invite, delete-confirm, onboarding | Call ux_coverage (MCP) or read coverage.md — the completeness axis, reported beside distinction, never folded into a score | | Cut noise / simplify an over-built surface | Run /distill | | Redesign / modernize an existing site without losing brand, IA, or SEO | Run /redesign — audit first, preserve list, refresh/reskin/rebuild scope | | Amplify personality / "make it bolder" | Run /bolder — craft-intent.md | | Tone down / "quieter", "more restrained" | Run /quieter — craft-intent.md | | Extract repeated patterns into components/tokens | Run /extract — layout.md, typography.md, color.md | | Purposeful micro-interactions | Run /delight — motion.md | | Animation performance | motion.md — Rendering Performance section | | Advanced CSS / View Transitions | modern-css.md | | Sound design | sound.md | | UX copy / voice / tone / microcopy (focused pass: /clarify) | copy.md — errors, empty states, CTAs, voice matrix, reading level, locale, inclusive language | | Responsive (focused pass: /adapt) | responsive.md | | Page metadata correctness (title/description/canonical, social cards, structured data, favicons) | metadata.md | | Three.js / GSAP / Motion | stack.md — OPT-IN ONLY — do not load unless user chose Motion/GSAP/Three.js in Discovery Step 2 | | Scored critique / PM-ready audit | heuristics.md + personas.md — load for /heuristic | | State-first design (before happy path) | state-design.md — load for /unhappy | | Data visualization / charts / dashboards | dataviz.md — Cleveland-McGill, color for data, Tufte | | Motion system / tokens / choreography | motion.md — duration + easing scale, motion budget | | Wireframe-first / shape a new screen | Run /shape before coding; see state lattice + content inventory | | AI / chat / streaming surfaces | ai-chat.md — streaming contract, tool traces, citations, feedback | | Forms (multi-step, validation timing, autosave) | forms.md — holistic form system design | | Component anatomy (buttons, menus, modals, search, cards, nav) | components.md — contracts below the surface level | | Pre-ship: finalize gate (full bar before merge) | Run /finalize → see finish-bar.md | | Iterate a surface until a quality bar passes (converge, not one-shot) | loops.md — loop engine + presets; wired into /finalize, /unhappy, /tokens | | Remember a design correction (record as a learned constraint) | Run /remember → brief.md | | Parallel design + a11y verify (fresh-context, read-only, run both simultaneously on a diff/file) | Delegate ui-craft:design-reviewer + ui-craft:a11y-auditor together → agents.md. Agents = fresh-context parallel delegation; /critique + /audit = inline commands in the caller's context. Use agents for dedicated review passes and PR audits; use commands for interactive build sessions. | | Ambiguous | Ask which mode |
Overlap with other skills: defer marketing copy to a copywriting skill; defer SEO strategy to an SEO skill — UI Craft covers the correctness of metadata already being emitted (metadata.md), not keyword or ranking strategy. UI Craft is the visual and interaction layer.
Out of scope. These are surface classes the recipes do not help with. Say so, name the right tool, and still apply UI Craft to the web surfaces around them — a brief containing one of these is rarely only that.
| Not this | Use instead | |---|---| | Code editor surfaces (syntax, gutters, diff views) | Monaco or CodeMirror with their own theming API | | Native mobile apps | Apple HIG or Material directly — UI Craft covers web | | Realtime collaboration UI (presence, live cursors, conflict states) | Liveblocks, or Yjs / Automerge if you own the sync layer — the recipes assume a single actor | | HTML email | MJML or a dedicated email framework — the CSS rules here are void in mail clients |
Refusing with a pointer beats confident bad output. Silence produces the second one.
Detect the styling approach from signals: Tailwind (tailwind.config.*, @tailwind), CSS Modules (*.module.css), styled-components/Emotion (styled(...), css\...\), CSS-in-JS (*.styles.ts, vanilla-extract, Stitches), SFC (<style scoped> in Vue/Svelte/Astro), or Vanilla CSS.
Rules: never fight the project's stack; never mix approaches. The design rules hold across stacks — only the syntax changes. (Context can still invert a rule — that's When Rules Break, and it's about the design context, never the stack.) Reference files are CSS-first with Tailwind translations. When in doubt, match existing patterns.
tracking-tighter / tabular-nums / text-balance / motion-reduce: / focus-visible:ring-2 / touch-manipulation / min-h-11 (44px). Use ease-[cubic-bezier(...)] for custom easing.
Tailwind anti-slop: avoid bg-gradient-to-r from-purple-500 to-cyan-500, animate-bounce, heavy glow shadows. Tailwind makes it easier to ship slop faster.
Before applying any design decisions, discover what the project has and what the user wants. Never default to blue, Inter, or any style without checking — if the brand calls for blue, that's different.
Design Memory (.ui-craft/ directory). This is the project's typed design context. It replaces the single brief.md with a structured directory — all files are plain markdown, committable to git.
Always-load on every UI task (small, define project taste/tokens):
.ui-craft/brief.md — product identity, design intent, audience, voice, constraints. See references/brief.md for the format guide..ui-craft/tokens.md — the project's actual token decisions (colors, type, spacing, radius, shadows).Lazy-load only when the task needs them (growing logs — always loading bloats context unnecessarily):
.ui-craft/decisions.md — append-only date-stamped design decision log. Load when the user asks to reference prior rationale or past decisions..ui-craft/patterns.md — validated component/layout compositions. Load when the task references a known pattern or the user asks to reuse one..ui-craft/surfaces/<name>.md — per-surface notes (layout, components, edge cases). Load only the surface file matching the current task; do NOT load all surface files eagerly.If .ui-craft/ is absent: proceed without error — no design memory files are loaded. Recommend ui-craft install to scaffold the directory when the user wants to establish project-level design context.
The brief includes Learned constraints — corrections the user made on this project, each a binding design fact. Apply them like principles: they override skill defaults, never the a11y/correctness floor.
Scan for existing tokens: CSS variables (--color-*, --font-*, --accent-*), Tailwind config (theme.extend.*), globals.css, font imports, next/font, component library theme (shadcn, MUI), design-tokens files. Build an inventory (accent, fonts, radius, shadows). If the project has an intentional system, respect it. Don't override.
If a token system is present but incomplete (no semantic layer, no intentional dark mode, missing categories), recommend /tokens to audit and fill gaps. Cross-ref tokens.md for the 3-layer contract.
If tokens are missing or ambiguous, ask in one compact prompt:
> "Before I build: (1) Design style — minimal, soft modern, sharp geometric, editorial, dark premium, or playful? (2) Accent color preference? (3) Font — clean sans-serif, geometric, humanist, monospace, or system? (4) Animation stack — Motion / GSAP / Three.js / none? (I'll load references/stack.md only if you opt in.)"
Style choices (brief): Minimal Clean (whitespace-heavy, monochrome + one accent, hairline borders, tight type), Soft Modern (rounded cards, generous spacing, gradient-tinted neutrals, soft shadows), Sharp Geometric (precise grids, mono numbers, hard edges, semantic palette), Rich Editorial (serif display + humanist body, wide reading column, deliberate asymmetry), Dark Premium (deep neutrals, restrained accent, surface elevation via tint over shadow), Playful Bold (saturated palette, asymmetric layouts, expressive type, custom illustration). Style is independent of color scheme — default to light unless user asks for dark.
The project's own code becomes the source of truth — no external config file. Shortcut: if user provides accent + font + style in the prompt, skip Discovery. See style-to-CSS mapping in layout.md.
When building a complete surface (dashboard, landing, auth, settings shell, portfolio page) — including /craft — output the Craft Read before writing code, in exactly this form:
> Craft Read: [surface kind] for [audience], [product | marketing] language, [theme/accent hint], variance [N], signature bet: [choice].
The template is here rather than only in craft-intent.md on purpose. Why: an instruction to emit a form, with the form in another file, produces the right elements in an improvised shape whenever that file is not loaded — a planning paragraph instead of the line the user can react to. A pointer to a form is not the form.
Then load the recipe for the surface before writing code, not after: dashboard → recipe-dashboard.md, landing → recipe-landing.md, auth → recipe-auth.md. Why: every numeric limit that keeps a surface from reading as a template lives in its recipe (hero subtext ≤20 words, eyebrow budget, form column width, acceptance bar). Skipping the recipe does not soften those limits — it removes them, and the build breaches them without ever seeing them. If the MCP server is connected, route_task names the recipe for you.
Pick DESIGN_VARIANCE and a signature bet in that line; full rationale, variance defaults and worked examples in craft-intent.md. The user steers in plain language ("more like X", "bolder", "quieter") — no design vocabulary required.
Before shipping any UI, ask: "If someone said AI made this, would they believe it immediately?" If yes, start over.
Critical (immediately reads as AI):
Major (designers notice):
transition: all — list specific properties<div> rectangles — use a real screenshot, a real mini component, or editorial imagery; never a div mockup<span>Minor (polish that separates good from great — full list in review.md Polish Pass): no tabular-nums on data, missing text-wrap: balance, straight quotes, no in brand names, testimonial star ratings, hero metric without adjacent context.
Anti-slop says what to avoid. Craft says what to aim for.
General craft:
tabular-nums.Landing pages (detail in inspiration.md):
Dashboards (detail in dashboard.md):
Every rule above has a context where it inverts. Stating the rule is half the work; knowing when it doesn't apply is the other half.
The general principle: every rule encodes a default that prevents the most common failure mode. When the context inverts the failure mode, the rule may invert too. The work is recognizing the inversion, not memorizing exceptions.
Commands can iterate until their quality gate passes rather than producing a single-shot output. The engine never fakes a render and always reports honest confidence. See loops.md.
When the user corrects design output — "not like that", "I don't like this", "always do X here", "never Z", or a reversal that reads as a standing preference — record it as a learned constraint in the brief (section 6; run /remember). Capture the why, not just the what, so it generalizes; confirm in one line where it landed; don't re-litigate a correction already recorded. Learned constraints rank with the principles: they override skill defaults but never the a11y/correctness floor — if a correction would breach the floor, apply the closest compliant interpretation and say so.
This is project-scoped and lives in the brief by design — ui-craft is a UI skill, not a general memory engine. Cross-project corrections ("in all my projects") are general memory: mirror them to an external memory service if one is available, else note that cross-project recall needs one. Full behavior → brief.md (Self-Correction).
> Should this animate? → High-frequency? No. Not communicating hierarchy/state/space? Cut it. Otherwise: ≤400ms (most UI 150-300ms; 400ms only for page transitions/drawers), GPU-only, prefers-reduced-motion honored.
Full ladder, easing, springs, stagger, interaction contract → motion.md (Decision Ladder).
Layered shadows (ambient + direct). Semi-transparent borders + shadows for crisp edges. Hue-consistent borders/shadows/text on colored surfaces. APCA over WCAG 2. Interactions increase contrast. color-scheme + theme-color match theme. OKLCH for scales. Full detail in layout.md and color.md.
When reviewing UI code, use a markdown table. Never use "Before:"/"After:" on separate lines.
| Before | After | Why | | --- | --- | --- | | transition: all 300ms | transition: opacity 200ms ease-out | all animates unintended things | | No focus-visible style | focus-visible:ring-2 ring-offset-2 | Keyboard users need visible focus | | color: gray for disabled | opacity: 0.5 + cursor: not-allowed | Multiple signals, not just color |
Prioritize findings by impact:
)| Frequency | Decision | |-----------|----------| | High (keyboard, toggles, typing) | No animation. Speed is the feature. | | Medium (hover, list nav) | Minimal — under 150ms or remove | | Low (modals, page transitions) | Standard — 200-300ms, clear purpose | | One-time (onboarding) | Can be expressive — tell a story |
| Element | Budget | |---------|--------| | Color/opacity | 100-150ms | | Small UI (tooltips, dropdowns) | 150-200ms | | Medium UI (modals, panels) | 200-300ms | | Large UI (page transitions, drawers) | 300-400ms |
Full easing curves, spring configs, stagger rules, and interaction rules → motion.md.
Tiered by signal. Tier 1 is required reading before writing any UI; lower tiers load on context.
Two entries, because two is what a build actually loads. This list used to hold seven; build evals showed a passing dashboard opened one of them and a passing landing opened two, while both reached for the surface recipe that was filed a tier below. A required list that nobody reads is not a standard, it is a wish — so the list now names what carries the build, and everything else below states the trigger that pulls it in.
| Reference | When to Read | |-----------|--------------| | craft-intent.md | Craft Read, DESIGN_VARIANCE, signature bets, product + marketing build patterns. The one reference every full-surface build needs. | | The surface recipe | recipe-dashboard.md · recipe-landing.md · recipe-auth.md — whichever matches what you are building. Every numeric limit that keeps a surface off template grammar lives here (hero subtext ≤20 words, eyebrow budget, form column width, acceptance bar). Skipping it does not soften those limits, it removes them. |
Same references as before, same weight when their trigger fires. Only the claim changed: these are conditional, and pretending otherwise made the whole Tier-1 label unreliable — including for the two above.
| Reference | Trigger | |-----------|---------| | brief.md | .ui-craft/brief.md exists — then read it first, it anchors every decision and its learned constraints override skill defaults. Absent: run /brief or proceed from Discovery. | | tokens.md | The project has a token system to respect or extend, or you are establishing one. With neither, themes.md gives a production preset in one step. | | accessibility.md | Any form, any custom interactive control, any focus or keyboard work. The a11y floor in Core Rules is the minimum; this is the detail. | | color.md | Choosing or changing a palette, building dark mode, or auditing accent budget. Not needed to apply a preset. | | layout.md | Composing a surface from scratch, or a spacing/hierarchy pass. Not needed when a recipe already prescribes the composition. | | inspiration.md | Highest-signal reference in the skill. Read it when the build needs an archetype or a signature detail, and whenever the result feels generic. |
> What this measured, and what it did not. The evidence is greenfield builds — an empty > sandbox with no brief and no tokens, so brief and tokens could not have been read > whatever the label said. It shows the label was not causing loads. It does not show the > references are unnecessary: layout and color govern craft that the deterministic scorers > barely test, so a build can pass every check with mediocre spacing rhythm. Re-measure before > trimming anything further, and re-measure on a project that already has a design system.
| Reference | When to Read | |-----------|--------------| | spec.md | Durable composition spec at .ui-craft/spec.md — the "what". Written by /shape Step 6, walked by /sddesign. Read after brief.md when a spec exists for the surface being built. | | Outcome recipes | Promoted to Tier 1 — see Always load. Listed there and not here so the recipe has one home; two descriptions of the same requirement is how one of them goes stale. | | themes.md | 4 named production token presets (Graphite, Porcelain, Carbon, Signal). Load when no token system exists. | | dashboard.md | Dashboards, metric cards, charts, tables, sidebar, filters. | | forms.md | Validation timing, progressive disclosure, multi-step wizards, autosave, optimistic submit. | | components.md | Component anatomy contracts: buttons (padding ratio, icon-side semantics), menus (5-option threshold, scroll affordance), modals (verb labels, ways out), search, content cards, nav bar. | | ai-chat.md | Streaming contract, 7-state affordance model for AI surfaces, tool traces, citations, generative UI. | | review.md | Critique methodology, Polish Pass, common issues, component craft. Load when reviewing or refining. | | finish-bar.md | 10-pass finishing protocol. Load on /finalize or CRAFT_LEVEL ≥ 8. | | loops.md | Loop engine: read→evaluate→fix-one→re-evaluate→stop contract + 3 presets. Load when converging /finalize, /unhappy, or /tokens audit. | | principles-catalog.md | 42 example design principles across 8 product categories. Load during /brief principles workshop branch as conversation seed. |
| Reference | When to Read | |-----------|--------------| | typography.md | Scale, font choice, readability, weight — scoped per script and role. | | motion.md | Decision ladder, duration + easing scales with perceptual grounding, interaction rules, motion-gap audit. | | modern-css.md | View Transitions, scroll timelines, container queries, @starting-style. | | responsive.md | Mobile/tablet/desktop, breakpoints, touch zones. | | metadata.md | Title/description/canonical consistency, deterministic metadata, social cards, noindex on staging, structured data honesty, favicons. | | copy.md | Voice/tone matrix, reading level (Flesch ≥70), terminology, inclusive language, errors, empty states, CTAs. | | sound.md | Web Audio, UI sound, appropriateness matrix. Rare — load when explicitly building audio feedback. |
| Reference | When to Read | |-----------|--------------| | stack.md | Three.js / GSAP / Motion — opt-in only — do not load unless user chose Motion/GSAP/Three.js in Discovery Step 2. | | heuristics.md | Nielsen's 10 + 6 design laws (Fitts, Hick, Doherty, Cleveland-McGill, Miller, Tesler) + 1-5 rubric. Load for /heuristic. | | personas.md | 5 persona walkthroughs (first-timer / power / low-bandwidth / screen-reader / one-thumb). Load for /heuristic --persona=<name>. | | state-design.md | State lattice — idle / loading / empty / error / partial / conflict / offline. Load for /unhappy. | | coverage.md | UX coverage — the parts 12 screen archetypes need to be complete (data table, settings, search, detail view, first-run, billing, pricing, docs, checkout, onboarding, destructive confirm, invite). The completeness axis, not distinction. Load for /harden, or when asked what a screen is missing. Prefer the ux_coverage MCP tool — it returns one archetype instead of all twelve. Generated from mcp/src/coverage-data.mjs; do not edit by hand. | | dataviz.md | Cleveland-McGill perceptual hierarchy, chart selection matrix, ColorBrewer/Okabe-Ito palettes, Tufte, direct labeling. Load when designing charts. | | agents.md | Agent pack overview: design-reviewer + a11y-auditor roles, agent-vs-command guidance, and parallel verify-team usage pattern. Load when setting up or describing the verify team. |
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→pass | 25,553 | 27,098 | +6% | 1 | 1 | 0% | 6,190 | 15,726 | +154% | 0 | 0 | — |
case-02 | fail→pass | 23,710 | 25,677 | +8% | 1 | 1 | 0% | 5,681 | 15,696 | +176% | 0 | 0 | — |
case-03 | fail→pass | 9,747 | 13,930 | +43% | 1 | 1 | 0% | 2,136 | 12,248 | +473% | 0 | 0 | — |
case-04 | fail→fail | 27,321 | 28,029 | +3% | 1 | 1 | 0% | 5,783 | 15,703 | +172% | 0 | 0 | — |
case-05 | pass→pass | 9,478 | 6,362 | -33% | 1 | 1 | 0% | 1,621 | 10,478 | +546% | 0 | 0 | — |
case-06 | pass→pass | 13,742 | 10,502 | -24% | 1 | 1 | 0% | 2,633 | 11,740 | +346% | 0 | 0 | — |
case-07 | pass→pass | 9,590 | 3,616 | -62% | 1 | 1 | 0% | 1,631 | 10,026 | +515% | 0 | 0 | — |
case-08 | pass→pass | 15,253 | 17,684 | +16% | 1 | 1 | 0% | 2,600 | 12,803 | +392% | 0 | 0 | — |
case-09 | fail→pass | 12,678 | 8,336 | -34% | 1 | 1 | 0% | 2,553 | 11,222 | +340% | 0 | 0 | — |
case-10 | fail→pass | 16,747 | 5,077 | -70% | 1 | 1 | 0% | 3,060 | 10,523 | +244% | 0 | 0 | — |
case-11 | fail→pass | 17,134 | 1,157 | -93% | 1 | 1 | 0% | 981 | 9,666 | +885% | 0 | 0 | — |
case-12 | fail→pass | 13,704 | 4,455 | -67% | 1 | 1 | 0% | 2,126 | 10,252 | +382% | 0 | 0 | — |
case-13 | fail→pass | 12,101 | 2,907 | -76% | 1 | 1 | 0% | 2,118 | 10,048 | +374% | 0 | 0 | — |
case-14 | pass→pass | 14,033 | 11,001 | -22% | 1 | 1 | 0% | 2,263 | 11,399 | +404% | 0 | 0 | — |
case-15 | pass→pass | 4,131 | 2,123 | -49% | 1 | 1 | 0% | 635 | 9,826 | +1447% | 0 | 0 | — |
case-16 | fail→pass | 17,689 | 12,454 | -30% | 1 | 1 | 0% | 2,800 | 11,503 | +311% | 0 | 0 | — |
case-17 | pass→pass | 9,327 | 3,542 | -62% | 1 | 1 | 0% | 1,736 | 10,060 | +479% | 0 | 0 | — |
case-18 | pass→pass | 10,982 | 6,539 | -40% | 1 | 1 | 0% | 1,820 | 10,634 | +484% | 0 | 0 | — |
case-19 | pass→pass | 12,961 | 9,381 | -28% | 1 | 1 | 0% | 2,140 | 11,113 | +419% | 0 | 0 | — |
case-20 | pass→pass | 10,195 | 5,679 | -44% | 1 | 1 | 0% | 1,930 | 10,588 | +449% | 0 | 0 | — |
case-21 | fail→pass | 9,858 | 3,237 | -67% | 1 | 1 | 0% | 1,635 | 10,115 | +519% | 0 | 0 | — |
case-22 | pass→pass | 12,201 | 15,695 | +29% | 1 | 1 | 0% | 2,189 | 12,318 | +463% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted, and 21 counted toward the lift figure. The other 1 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +45 percentage points is the difference between those two pass rates over the 21 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.