본문으로 건너뛰기
cccskills
무료GitHub에 공개

design-workflow

Anti-AI-generic design guidelines. Use when creating UI prototypes, reviewing designs for generic AI patterns, or setting up a project design system.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(2)

  • SKILL.md4.2 KB
  • checklists.md1.8 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Design Workflow Skill

Guidelines for making UI designs that don't look AI-generated. These rules apply to any design work — prototypes, design docs, or UI code.

What This Skill Does

  1. Teaches how to avoid "generic AI" design patterns
  2. Provides a checklist for design quality
  3. Guides component-by-component design approach
  4. Sets prototype quality standards

Rule 1: Use the Existing Design System

NEVER invent new colors, fonts, or spacing. Always use what the project defines.

What to Read FIRST

  1. .planning/design-config.md — project colors, fonts, spacing, brand identity
  2. The theme files listed in design-config — actual CSS tokens
  3. Existing components in the codebase — match their patterns

Key Points

  • Use EXACT hex values from the project palette (not Tailwind defaults like bg-blue-500)
  • Use the project's font — don't swap in Inter, Poppins, or Space Grotesk
  • Use the project's border radius and shadow values
  • Reference CSS variables or tokens — don't hardcode

Rule 2: Avoid Generic AI Patterns

These patterns scream "AI made this" — avoid them ALL:

Colors

  • Don't use colors outside the project palette
  • No random purple/violet gradients (the #1 AI cliche)
  • No neon colors or rainbow gradients
  • No gray-on-gray with no accent color
  • Use the project's accent color — that's what makes it unique

Layout

  • No centered-everything-with-max-width-on-every-section
  • No hero with a giant gradient blob behind text
  • No three-column feature cards with icons that all look the same
  • No 50/50 split with image on right, text on left (for every section)
  • Break the grid sometimes — asymmetry is more interesting

Typography

  • No single font size for everything
  • Create clear hierarchy: big headings, medium subheads, small body
  • Use font weight contrast
  • Don't center-align long text blocks

Components

  • No rounded rectangles that all look identical
  • Give cards visual variety — different sizes, featured vs normal
  • Buttons should have clear primary/secondary/ghost hierarchy
  • Don't use icons for everything — sometimes text is better

Copy

  • No generic marketing fluff ("Unlock your potential", "Take it to the next level")
  • Be specific — use real feature names and real numbers
  • Match the tone from design-config's Design Personality

Rule 3: Design Component by Component

Don't design a whole page at once. Build pieces, then compose.

Order of Work

  1. Design tokens — Confirm colors, fonts, spacing from existing theme files
  2. Base components — Button, Card, Badge, Input (small, isolated)
  3. Composite components — Nav bar, Sidebar, Hero section, Feature card
  4. Full screens — Compose components into pages
  5. States — Add loading, empty, error states to each component
  6. Responsive — Adjust each screen for mobile/tablet/desktop

Rule 4: Use Visual References

When references are given:

  1. Study what makes it look good (layout, color, typography, whitespace)
  2. Take inspiration, don't copy — match the quality level, not the exact layout
  3. Apply to the project's design system

When NO references are given:

  • Check Reference Apps in design-config
  • Focus on whitespace — more space = more premium
  • Use accent color sparingly — max 10-15% of the screen
  • Make one thing big and bold per section (hierarchy)

Rule 5: Prototype Quality Standards

Must Have

  • Exact colors from the project theme files
  • Real fonts loaded
  • Proper spacing (not random padding everywhere)
  • Real content (not "Lorem ipsum")
  • All states visible (loading, empty, error, success)
  • Responsive: works at 375px, 768px, 1440px

Must NOT Have

  • Placeholder images or stock photo URLs
  • Default Tailwind colors
  • Missing hover/focus states
  • Broken layout at any viewport
  • Text that's hard to read (check contrast)

Review & Checklists

See checklists.md for the self-check, critic review checklists, and design-implementation mismatch troubleshooting.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Creates RPC-style endpoint following layered architecture (Controller → Manager → Repository). Use when creating new API endpoints or CRUD operations.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

c0x12c/ai-toolkit1092026년 6월 18일 업데이트

Write blog posts, guides, tutorials, and long-form content. Sounds like a real person, not AI. Use when the user wants polished written content.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

c0x12c/ai-toolkit1092026년 6월 18일 업데이트

Design RPC-style APIs with layered architecture (Controller → Manager → Repository). Use when creating new API endpoints, designing API contracts, or reviewing API patterns.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

c0x12c/ai-toolkit1092026년 6월 18일 업데이트

Run a structured brainstorm session for startup ideas. Takes a theme or problem and generates ideas with quick gut-checks. Use when the user wants to explore a space or generate new ideas.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

c0x12c/ai-toolkit1092026년 6월 18일 업데이트

Run real browser QA with Playwright. Use when testing a frontend feature, verifying UI before PR, smoke testing after deploy, or investigating reported visual bugs.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

c0x12c/ai-toolkit1092026년 6월 18일 업데이트

CI/CD pipeline patterns for GitHub Actions, PR automation, and deployment workflows. Use when setting up CI, fixing broken pipelines, automating PR checks, or configuring deployment.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

c0x12c/ai-toolkit1092026년 6월 18일 업데이트

c0x12c의 스킬 모두 보기

이 스킬의 문제 신고