跳到正文
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(原文)

安装前可以查看交给 AI 代理的指令内容。

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 / 1000 字

此表单受 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 的全部技能

报告此技能的问题