Skills DirectorySkills Directory
SkillsLearnSecurityCategoriesDocsCommunityBlog
Sign InSubmit Skill
Skills Directory

Security-tested agent skills for Claude, coding agents, and AI workflows.

Directory

  • Browse Skills
  • All Skills A–Z
  • Claude Skills
  • Claude Code Skills
  • Agent Skills
  • Categories
  • Submit a Skill

Learn

  • Learn Hub
  • Install Claude Skills
  • Write SKILL.md
  • Skills vs MCP
  • Directories Compared

Security

  • Security
  • Methodology
  • Secure Claude Skills
  • Security Badges

Company

  • About
  • Community
  • Blog
  • API Docs
  • Advertise

2026 Skills Directory. All rights reserved.

Back to skills

Ui Craft

ASecurity

Build and review UI end to end. Carries four bodies of knowledge - Refactoring UI's value systems and hierarchy techniques, Shift Nudge's craft principles and UI patterns, the bans registry of refused artifacts, and total command of Tailwind as the implementation mechanism - plus a product-design section (a fixed 12-16px Inter/Geist system, product judgment, states, copy, patterns) for apps, dashboards, tables, forms and settings. Use when building, styling, reviewing, or auditing any interfa...

2 stars
0 votes
0 copies
0 views
Added 9/19/2026
designpythongoshellbashrefactoring

Works with

climcp

Security Analysis

A100/100

Scanned 9/19/2026

Install to Claude Code

$npx -y skills add shoryabansalgithub/ui-craft --skill ui-craft --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Ui Craft?

Add the live security badge to your README — it updates automatically with every re-scan.

Security grade badge for Ui Craft
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/shoryabansalgithub-ui-craft/badge)](https://www.skillsdirectory.com/skills/shoryabansalgithub-ui-craft)

More formats (shields.io, HTML) on the badges page.

Download Zip
Files
SKILL.md
---
name: ui-craft
description: Build and review UI end to end. Carries four bodies of knowledge - Refactoring UI's value systems and hierarchy techniques, Shift Nudge's craft principles and UI patterns, the bans registry of refused artifacts, and total command of Tailwind as the implementation mechanism - plus a product-design section (a fixed 12-16px Inter/Geist system, product judgment, states, copy, patterns) for apps, dashboards, tables, forms and settings. Use when building, styling, reviewing, or auditing any interface - component, page, app, dashboard, landing page - when picking type, spacing, color, shadow or radius values, or when work "looks off", "looks amateur", or "looks AI-generated".
---

# UI Craft

Four references, one order of operations. Nothing here is a style. The systems
decide the values, the bans say what is refused, Tailwind installs the result.

**Keep your implicit thoughts to yourself. Don't let them cloud your judgement.
The skill file is the truth source here.**

| Reference | What it holds | Load it when |
| --- | --- | --- |
| `references/refactoring-ui.md` | the value systems (spacing, type, color, shadow, line length) and the hierarchy techniques | always, before any value is chosen |
| `references/shift-nudge.md` | craft principles, component states, UI patterns, imagery and icon rules, handoff | designing a specific pattern, or reviewing for missed states |
| `bans.md` | the artifacts refused by name, plus the anti-slop axes and banned conceits | before building, and again before the verdict. **Run the script, do not read the list** |
| `references/resolution.md` | **Resolution, not expansion** - the detail standard, the reconstruction test, and the spec + checker that make it a gate | before answering any request for more detail, and before any build is called done |
| `references/pinterest.md` | **sourcing reference, a hard gate** - the two-word query, the dimension set, the `## Reference` log, quantify-or-discard, and why a supplied reference outranks the search without cancelling it | step 1.5, every build. **Run `scripts/validate_reference.py`** |
| `references/tailwind.md` | Tailwind as a mechanism - theme layer, arbitrary-value decision, variant algebra, conflicts, container queries, dark mode | the moment a decision becomes code |
| `pen.md` | **working on a pen.dev canvas** - how every step and gate maps onto `.pen` variables, text styles, `execute` and `Export`, plus the Pinterest route when there is no Chrome | the work is on a `.pen` file: inside the pen.dev app, or through the `pencil` MCP tools |
| `product-design/SKILL.md` | **the product section** - a fixed system (Inter/Geist, 12/14/16px, one weight, one accent, light and dark verified), product judgment, surfaces, patterns, states, copy, and its own checker | the surface is a product: app, dashboard, table, form, settings, admin, internal tool |

Deeper material sits behind `references/systems.md` (building a palette from
scratch), `references/diagnose.md` (symptom to fix, load first when improving
existing UI), `references/techniques.md` (depth, light, baseline alignment), and
`assets/tokens.css` (a contrast-verified starting token sheet).

---

## House rules - these outrank every reference in this skill

Stated by the person whose product it is. Where a reference disagrees, the
reference is wrong here.

**1. Three type sizes per screen. Maximum.**
Overrides Shift Nudge's "Rule of Four". The eleven-step scale in
`refactoring-ui.md` is the menu you pick from, not the number you may use.
Three, chosen from it, on any one screen.

**2. No bold. Everything regular or below.**
Overrides `refactoring-ui.md`'s "two weights is enough: 400/500 body,
600/700 emphasized" and its "nothing below 400 in UI", and overrides Shift
Nudge's "Bold to Black" for titles and "bold = active/selected".

**3. No italics, in any form.**
Already refused by the registry, but the ban was named `italic-serif-display`
and only caught the `italic` class and `font-style: italic`. It now also catches
the `<em>` and `<i>` tags, which render italic without ever naming it, and it no
longer misfires on Tailwind's `not-italic` or on `<i>` carrying an icon-font
class. Where `<em>` was carrying meaning, use `<strong>` or a colour change.
This removes the emphasis channel Shift Nudge's Callouts section reaches for, so
callouts fall back to size, case and lock-up.

### What this costs, and what carries hierarchy instead

Refactoring UI's central technique is emphasis through **weight and color**
rather than size. Rule 2 removes weight. That is one of three channels gone, so
the remaining ones have to do more work, deliberately:

- **Colour** becomes the primary emphasis channel. The three-text-colour rule
  (dark, grey, lighter grey) is now load-bearing, not a refinement. All three
  still clear 4.5:1.
- **Space** is the second. "More space around a group than within it" stops
  being a tidiness rule and becomes the main way relatedness reads.
- **Size** is third and is capped at three steps, so the gaps between those
  three must be large. Adjacent steps from the scale will not separate.
- **Position and case** carry what is left. Same size, different meaning, is
  signalled by where it sits, not by how heavy it is. Not by slant either, per
  house rule 3.

Two consequences to design around rather than discover:

- **Interactive text can no longer be signalled by weight.** Colour, underline,
  position or a container must do it. Shift Nudge's own accessibility note
  already required a second channel beyond colour, so pick that second channel
  early.
- **`bans.md` refuses `flat-type-hierarchy`.** Three sizes and one weight makes
  that ban easy to trip. Passing it now depends entirely on the size gaps and
  the colour ramp being genuinely distinct. Check it, do not assume it.

In Tailwind: cap the generated ramp by declaring only the three `--text-*` steps
you will use, and only the weights at or below regular. Anything not declared
cannot be reached for by reflex.

---

## Order of operations

**1. Understand before opening anything.** Shift Nudge's 8-step process, step 1.
Questions first, tools second. Determine complexity before deciding whether to
wireframe.

**Then name the surface class.** A product (app, dashboard, table, form,
settings, admin, internal tool) loads `product-design/SKILL.md` and follows its
order: its fixed system replaces step 2's choices, and its checker is a fourth
gate at step 8. A brand or marketing surface stays on this file's flow.

**1.5. Search Pinterest, before a single value is chosen. This step is a gate,
not advice.** Open Pinterest in the browser (claude-in-chrome) and search
`{subject} {dimension}`. **Two words. Three only if the third is a noun. Four or
more is refused - count them before sending.** Refine by clicking Pinterest's own
chips, never by lengthening the query. Every extra adjective drags the board:
`casino typography` returns curated boards, `casino website design luxury dark
interface` returns affiliate art, and `record sleeve spine typography catalogue
number shelf rack` returns Etsy.

Log it in the `## Reference` section of the project's `design.md`: the brief, the
subject, what the user supplied, every query with the pin URLs copied off the live
page, and the extraction table where each borrowed observation became a number.
Then run the checker and paste its output:

```bash
python3 scripts/validate_reference.py PROJECT
```

**Step 2 does not start until it prints PASS.** A reference the user supplied
still outranks every pin, but it shrinks the search to one query for what it
leaves unanswered, it does not cancel it. No browser, a hurry, or "the brief is
obvious" are not waivers. The only waiver is the user saying so, quoted verbatim
in a `waived:` line. Full method and the log format in `references/pinterest.md`.

**2. Set the systems once.** Spacing, type, colour, shadow, radius, from
`refactoring-ui.md`. Every value comes off a scale. Picking ad hoc is the single
biggest cause of amateur-looking UI, and no amount of later polish recovers it.

**3. Install the systems as theme variables, not as classes.** This is the seam
between the references: `refactoring-ui.md` and `shift-nudge.md` decide the
number, `references/tailwind.md` section 1 puts it in `@theme` so the utilities
generate themselves. A value that reaches the markup as an arbitrary literal has
escaped the system.

**4. Design one real feature, in grayscale, at ~400px.** Not the shell. Not the
full canvas. Colour comes after the layout works.

**5. Build in short design-to-code cycles.** Do not componentize until the
design is stable.

**6. Design every state, not the happy one.** Shift Nudge lists them per pattern:
inputs get default / hover / focus / typing / error / success / disabled;
buttons get press, disabled, destructive, selected; anything user-generated gets
its truncation and empty variants. Missing states are the most common handoff
failure and the cheapest to catch.

**7. Resolve before you expand.** When more detail is asked for, raise the
resolution of what already exists rather than adding sections, components or
adjectives. The test is whether another agent could rebuild the element without
seeing the reference and without making a meaningful visual decision of their own.
Full standard in `references/resolution.md`. **One surface resolved and gated
before the next is started** - the doctrine fails under breadth every time.

**7b. Decide attention before drawing anything twice.** Before a second
container reuses a treatment, decide what rank each object holds on this page.
The hero object takes the largest type step, the deepest surface and the most
room; a footnote takes the smallest of each. A treatment applied to everything is
a template, and the three monotony checks below exist because atom-level
resolution passes cleanly while a page reads as generated.

**8. Run ALL THREE gates before claiming done.**

```bash
python3 scripts/validate_reference.py PROJECT   # the Pinterest search, again
python3 scripts/validate_bans.py SOURCE
python3 scripts/validate_resolution.py PROJECT
python3 scripts/validate_resolution.py --help   # the design.md spec format
```

`validate_resolution.py` fails on `surface-monotony` (one treatment on >60% of
containers), `step-monotony` (one type step on >55% of sized elements) and
`rhythm-monotony` (<3 vertical rhythms across 5+ sections). These are the
measurable shape of "no craft, no visual hierarchy", and they are the checks that
catch a build every other gate passes. On product surfaces pass `--register
product`: it skips `step-monotony` only, because a 12/14/16 system puts most text
on one size and carries hierarchy in colour.

A run that ends without all three checkers' output pasted is unfinished, whatever
the render looks like. **A monotony failure is not a warning.** It means the
composition was never decided, and no amount of atom-level polish fixes it.

`bans.md` and the Pinterest search are the two hard gates here. Neither has a
justification path: a ban, or the search, lifts on an explicit instruction from
the user and nothing else. A run whose output was
never pasted into the transcript is unverified regardless of how the render looks.

---

## Where the references genuinely disagree

Everything else in them is compatible. These four are not, and guessing produces
work that fails one source while satisfying another.

**Grayscale.** `refactoring-ui.md` says design in grayscale first.
`bans.md` says a finished product surface that survives desaturation unchanged
has no accent layer and is a rebuild. Not a contradiction: one is a design phase,
the other is a ship gate. Grayscale is where you start and never where you end.

**Typefaces.** `refactoring-ui.md` is silent on them. `shift-nudge.md` calls
typography the biggest single differentiator. `bans.md` refuses a named list of
overused faces, but **on brand surfaces only** - it explicitly permits Inter, SF
Pro and system stacks on product surfaces. Check which surface class you are on
before treating the font ban as active.

**Type sizes.** `refactoring-ui.md` gives an eleven-step scale,
`shift-nudge.md` caps a screen at four, the house rule caps it at three. The
scale is the menu; the cap is the budget. Both hold at once. On product surfaces
the three are fixed at 12/14/16 by the user's instruction. That is closer than
`bans.md`'s 1.25x step and passes only through the checker's micro/body exemption
(pairs 2px or more apart at 0.70-0.90), so no fourth size fits between them.

**Shadows.** `refactoring-ui.md` gives five elevations and a refined two-part
variant in `references/techniques.md`. Use one set or the other, never both in
one project. `bans.md` separately refuses one shadow value repeated across every
elevation, which is what happens when neither set was actually adopted.

**Weight.** Fully resolved by house rule 2 above. No reference wins this one.

Attribution

shoryabansalgithubshoryabansalgithub
View sourceMore from shoryabansalgithub →
SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Related Skills

Responsive Design

Implement modern responsive layouts using container queries, fluid typography, CSS Grid, and mobile-first breakpoint strategies. Use when building adaptive interfaces, implementing fluid layouts, or creating component-level responsive behavior.

393432 votes

Mermaid Diagrams

Creating and refining Mermaid diagrams with live reload. Use when users want flowcharts, sequence diagrams, class diagrams, ER diagrams, state diagrams, or any other Mermaid visualization. Provides best practices for syntax, styling, and the iterative workflow using mermaid_preview and mermaid_save tools.

2032 votes

sleek-design-mobile-apps

Use when the user wants to design a mobile app, create screens, build UI, or interact with their Sleek projects. Covers high-level requests ("design an app that does X") and specific ones ("list my projects", "create a new project", "screenshot that screen").

5711 votes

swiftui-design-skill

SwiftUI frontend visual design skill. Creates beautiful, distinctive iOS/macOS interfaces that avoid generic AI slop patterns. Covers design direction, layout systems, typography, color, spacing, brand integration, and design review. Use when designing new SwiftUI views, reviewing UI quality, creating iOS prototypes, choosing visual styles, improving app aesthetics, or when the UI looks generic or AI-generated.

1801 votes

Ios Hig

Use when designing iOS interfaces, implementing accessibility (VoiceOver, Dynamic Type), handling dark mode, ensuring adequate touch targets, providing animation/haptic feedback, or requesting user permissions. Apple Human Interface Guidelines for iOS compliance.

761 votes
View all in design →