Design Core

The principles every design skill in this repo applies, in one place, so each skill doesn't restate them. Other skills load this one; this one doesn't do Figma calls, captures or code.

Order of authority

1. The user's explicit request.
2. The product's own system: its components, variables, text styles, term list and capitalization. A file that uses Title Case on buttons keeps Title Case.
3. Platform rules for where the design ships (Apple HIG, Material, WCAG).
4. This skill's defaults. They fill gaps; they never replace something that already exists.

When two rules here disagree with the product, report the gap. Don't silently restyle.

The rules in short

Composition (detail and checks: references/visual-principles.md)

• One focal point per screen. Hierarchy decides what is seen first, second, third.
• Every element sits on a grid line, a shared edge, or a baseline. Use auto layout, not nudging.
• Related things sit close; unrelated groups get more space between them than within them.
• Spacing, color, type and radius come from tokens. Repetition of the same values is what makes a screen feel designed.
• Contrast is for meaning: the primary action, the error, the current item. Not decoration.

Writing (detail and checks: references/writing.md)

• Most important information first. One idea per screen when you can.
• Buttons and links start with a verb and say what happens: "Send", "Save draft", not "OK", "Let's go", or "Click here".
• Errors sit next to the problem, don't blame, and say how to fix it.
• Empty states say what to do next and offer the button to do it.
• Keep one term per concept, one capitalization style per element type, no "we".

Interface baseline (detail and checks: references/interface-quality.md)

• Every screen has its default, empty, loading and error state, and long content doesn't break it.
• Every control is reachable and named: label, focus ring, contrast, target size.
• Motion only where it gives feedback, and it respects reduced motion.
• No AI tells: decorative gradients, a generic three-card row, rounded cards everywhere, filler adjectives.

How to use it

Follow the working order in references/workflow.md: understand → inventory → intent → build → review → hand off, with a check at the end of each stage. Its short form:

1. Write the screen's job in one sentence. Take behavior from the source, never guess it.
2. Inventory the product's components, tokens, text styles and words before drawing.
3. Show the plan as text (content order, focal point, states, copy) before building.
4. Build the default state first from instances and tokens, then the other states.
5. Screenshot, score, fix the top findings, at most three rounds. Report the scores.
6. Hand off states, behavior, tokens and gaps per screen.

When building, read the reference that matches the work before placing or writing anything: visual principles for layout, writing for any visible text, interface quality for states and controls. Then build with the product's own tokens and components.

When reviewing, score each dimension 0–10 and say what a 10 would look like for this screen:

Report findings as screen or file:location — issue → fix, most severe first. A finding needs a location and a concrete fix; "feels off" isn't one. Pass is 8 or higher on every row.

When the request is vague ("make it clean", "more professional"), pin down these before designing, and ask about the ones the product doesn't already answer: palette, accent, body type, display type, layout model, mood, density, and what to exclude.

Sources

• Apple Human Interface Guidelines, Writing
• Figma Resource Library, Graphic design principles
• nexu-io/open-design (Apache-2.0): web-design-guidelines (Vercel Web Interface Guidelines), impeccable-design-polish, plan-design-review, design-brief

The references paraphrase these sources. Re-check them when a rule seems out of date.