joshuadavidthomas/agent-skills

frontend-design-principles

Use when building or reviewing frontend UI — dashboards, admin panels, landing pages, marketing sites, web apps.

소스 보기

사용 방법

  1. 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
  2. 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
  3. 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/joshuadavidthomas/agent-skills --skill frontend-design-principles

시작 전 확인

  • 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
  • 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 Skill 문서

원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.

Frontend Design Principles

Build frontend interfaces with craft and intention.

Scope & Routing

After this file, load the context-specific guide:

  • `app.md` — dashboards, admin and settings panels, internal tools, SaaS products, data-heavy interfaces (tables, forms, lists), anything users work in repeatedly.
  • `marketing.md` — landing pages, marketing sites, announcements, creative artifacts, anything where first impression matters most.

If unclear, ask. Blended projects need both: a SaaS marketing site uses marketing.md; its product dashboard uses app.md.

Why This Process Exists

You default to generic output — training patterns for dashboards and landing pages are strong. The process below helps, but process alone isn't craft: you have to catch yourself.

Where Defaults Hide

Defaults disguise themselves as infrastructure — the parts that feel like they just need to work, not be designed. There are no structural decisions. Everything is design.

  • Typography isn't a container — it IS the design. A bakery tool and a trading terminal both want "clean, readable type," but warm-and-handmade is not cold-and-precise. Reaching for your usual font means you're not designing.
  • Navigation isn't around the product — it IS the product. Where you are, where you can go, what matters most. A page floating in space is a component demo, not software.
  • Data isn't presentation — it's meaning. A progress ring and a stacked label both show "3 of 10"; one tells a story, one fills space. Ask what the number means to the person looking at it.
  • Token names are design decisions, not implementation detail. Someone reading only your CSS variables should be able to guess the product:
css
/* ❌ generic — could be any project */
--gray-700: …;  --surface-2: …;
/* ✅ domain — evokes this product's world */
--ink: …;  --parchment: …;

Required: Before Generating

Do not write code until these are done.

1. Answer the intent questions

Answer with specifics or ask the user — do not guess, do not default:

  • [ ] Who is this human? Not "users." The actual person — where are they, what's on their mind, what did they do 5 minutes ago and 5 minutes after?
  • [ ] What must they accomplish? The verb: grade these submissions, find the broken deployment, approve the payment.
  • [ ] What should this feel like? Words that mean something. Not "clean and modern" (every AI says that) — warm like a notebook? cold like a terminal? dense like a trading floor?

2. Produce the four required outputs

  • [ ] Domain: concepts, metaphors, vocabulary from this product's world — territory, not features. Min 5.
  • [ ] Color world: colors that exist naturally in this domain. Go to the actual world, not "warm/cool." List 5+.
  • [ ] Signature: one element — visual, structural, or interaction — that could only exist for THIS product.
  • [ ] Defaults to reject: 3 obvious choices for this interface type, visual AND structural. You can't avoid patterns you haven't named.

3. Propose direction and confirm

Reference your domain concepts, colors, signature, and what replaces each rejected default.

Domain: [5+ concepts from the product's world]
Color world: [5+ colors that exist in this domain]
Signature: [one element unique to this product]
Rejecting: [default] → [alternative] ×3

Direction: [approach connecting the above]

Does that direction feel right?

Test: remove the product name from your proposal — could someone still identify what it's for? If not, explore deeper. Wait for confirmation before generating code.

Required: Before Showing

Your first output is probably generic; the work is catching it before the user has to. Look at what you made and ask "if they said this lacks craft, what would they mean?" — fix that first. Run these; iterate if any fails:

  • [ ] Swap test: swap your typeface/layout for the usual one — would anyone notice? Where swapping wouldn't matter is where you defaulted.
  • [ ] Squint test: blur your eyes. Is hierarchy still readable? Anything jumping out harshly? Craft whispers.
  • [ ] Signature test: point to specific components where your signature appears. "The overall feel" doesn't count.
  • [ ] Token test: read your CSS variables aloud. Do they belong to this product's world, or any project?

Principles

  • Every choice must be a choice. For every decision — layout, color temperature, typeface, spacing scale, hierarchy — you can state WHY. "It's common / clean / it works" is a default, not a choice.
  • Sameness is failure. If another AI given a similar prompt would produce substantially the same output, you failed. Design from intent and sameness is impossible — no two intents are identical. Linear's cards don't look like Notion's; Vercel's metrics don't look like Stripe's.
  • Intent must be systemic. "Warm" then cold colors is not following through. If warm: surfaces, text, borders, accents, semantic colors, type — all warm. Check every token against the stated intent.
  • Infinite expression. A metric can be a hero number, sparkline, gauge, delta, trend badge, or something new. Never ship the same sidebar width + card grid + icon-left-number-big every time — it reads as AI-generated instantly.

Craft Foundations

The quality floor, regardless of direction:

  • Subtle layering. Surfaces barely different but distinguishable — whisper-quiet elevation shifts, not dramatic jumps (study Vercel, Supabase, Linear). Borders light enough to disappear until you look for structure; if they're the first thing you notice, they're too strong.
  • Color lives somewhere. Spend time in the product's physical world before reaching for a palette — materials, light, objects. It should feel like it came FROM somewhere, not applied TO something. Gray builds structure; color carries meaning. One intentional accent beats five thoughtless ones.

Universal Anti-Patterns

Always wrong, regardless of context:

  • Dramatic drop shadows — box-shadow: 0 25px 50px … looks cheap
  • Arbitrary asymmetric padding — every value should be intentional
  • Thick decorative borders — 2px+ for visual weight
  • Multiple accent colors — one accent, used consistently
  • Mixing depth strategies — borders OR shadows, not both randomly
  • Inconsistent spacing — the clearest sign of no system

Communication

Be invisible. Don't announce modes or narrate process ("Let me explore the domain…", "Running the checks…"). Jump into the work; state suggestions with reasoning.

Deep Dives

  • references/principles.md — spacing, depth, typography, color implementation, dark mode (concrete values and CSS)
  • app.md — dashboards, admin panels, SaaS products
  • marketing.md — landing pages, marketing sites, creative artifacts

관련 작업

같은 저장소의 Skills

더 많은 Skills

모든 Skills
joshuadavidthomas
커뮤니티

english-please

Dude, come on. You write at the density of your own thinking and leave the reader to unpack it. Apply whenever explaining anything to a human — not just end-of-run summaries, every message.

설치 수
1
GitHub Stars
56
업데이트
7월 20일
joshuadavidthomas
커뮤니티

grug-brained-dev

Use when reviewing PRs, simplifying over-engineered code, judging architecture, or renaming unclear concepts — inline fake helpers, delete meatless ceremony, rename lying names, merge over-split files, reject premature abstraction, say no to speculative config/modes/layers, then end with the smallest safe next change. Triggers when code is too fancy, too abstract, too clever, too many files/helpers/layers, or too well-factored but painful to change. Embody Grug brain: complexity very bad, small

설치 수
1
GitHub Stars
56
업데이트
7월 20일
joshuadavidthomas
커뮤니티

improve

Survey a codebase as a senior advisor and turn the highest-value findings into implementation plans for other agents to execute — strictly read-only on source code, never implements anything itself. Use when asked to audit a codebase, find improvement opportunities (bugs, security, performance, test coverage, tech debt, architecture, migrations, DX), suggest features or roadmap direction, or generate handoff plans for another agent to implement.

설치 수
1
GitHub Stars
56
업데이트
7월 20일
joshuadavidthomas
커뮤니티

jj

Jujutsu (jj) — the Git-compatible version control system. Activate ONLY when a .jj/ directory is present in the project or when jj/jujutsu is explicitly mentioned. Do NOT activate for plain git repos without .jj/. Use for any VCS operations in jj-managed projects: commit, push, pull, branch, bookmark, rebase, squash, merge, diff, log, status, working copy, change ID, revset, fileset, template, configuration, workspaces.

설치 수
1
GitHub Stars
56
업데이트
7월 20일