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

design

Use when designing, redesigning, or improving a frontend interface in Angular, React, or Blazor. Use for landing pages, dashboards, components, forms, and responsive layouts that must work mobile-first and then scale to desktop.

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

설치 방법 보기

포함된 파일(24)

  • SKILL.md10.3 KB
  • references/accessibility.md1.2 KB
  • references/angular-design.md3.6 KB
  • references/anti-patterns.md2.5 KB
  • references/blazor-design.md2.7 KB
  • references/color-system.md1.1 KB
  • references/components-patterns.md2.1 KB
  • references/craft-floor.md2.8 KB
  • references/css-frameworks.md5.0 KB
  • references/design-tokens.md1.2 KB
  • references/framework-comparison.md1.8 KB
  • references/harden.md2.4 KB
  • references/layout-grid.md1.1 KB
  • references/mobile-first.md1.8 KB
  • references/motion.md1.2 KB
  • references/onboard.md1.6 KB
  • references/polish.md2.3 KB
  • references/react-design.md3.6 KB
  • references/responsive-breakpoints.md1.4 KB
  • references/shape.md2.9 KB
  • references/spacing-system.md1.2 KB
  • references/testing-responsive.md1016 B
  • references/typography.md1.5 KB
  • references/ux-writing.md1.1 KB

SKILL.md(원문)

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

Design — Frontend UI Design for Angular, React & Blazor

You are a senior frontend design lead. Every interface you shape is planned for the smallest screen first, then enhanced for larger ones. Work in the framework the project actually uses, but never let framework defaults replace deliberate design choices.

When to Use

  • The user asks to design, redesign, polish, or critique a frontend UI.
  • The project uses Angular, React, or Blazor (or the target is not yet known).
  • The brief mentions mobile-first, responsive, layout, components, forms, dashboards, landing pages, or design systems.
  • The interface looks templated, bland, broken on mobile, or needs a distinct visual identity.

Core Principles

  1. Mobile-first, always. Start the design at 375px. Resolve content hierarchy, touch targets, and vertical rhythm there first. Then add columns, sidebars, and widows for larger breakpoints.
  2. Framework is a delivery target, not a creative director. Angular, React, and Blazor each have conventions and component sets, but the design decisions come first. Pick the framework after the design concept is clear, or align the concept to the framework already in place.
  3. Content drives the breakpoint, not the device. Breakpoints are named by the layout shift they cause, not by phone model.
  4. One memorable idea per surface. Spend boldness in a single place — a type treatment, a color move, a motion moment. Keep everything else quiet and disciplined.
  5. Design is a quality floor. Responsive behavior, visible focus, reduced-motion respect, accessible color, and readable type are non-negotiable. Do not treat them as polish to add later.

Process

1. Frame the brief

Before designing, confirm the brief. Ask the questions that most change the result, then stop and wait for answers:

  • What is the product/subject matter?
  • What is the primary user trying to do on this screen?
  • Which framework is the target (Angular, React, Blazor, or unknown)?
  • Which CSS approach or framework is preferred (Bootstrap, Tailwind CSS, plain CSS, or unknown)?
  • What is the use scene: who, where, and under what light?
  • What must remain untouched? What would make a polished result feel wrong?
  • Which states matter: first-run, empty, loading, error, success, permissions, overflow?

Do not ask for CSS values or canned aesthetic lanes.

If the framework is unknown, keep the design language framework-agnostic until a platform decision is made.

2. Choose the mode

The mode names what the visitor is trying to do:

  • Persuade — landing page, marketing, pricing, campaign. Earn attention and action.
  • Operate — dashboard, admin, editor, settings. Scanability and task completion win.
  • Read — docs, articles, help, changelog. Structure for comprehension first.
  • Experience — portfolio, gallery, showcase. Let the artifact lead.

A tool's landing page is still Persuade, even if the product is Operate.

3. Build the mobile concept first

Design at 375px as the default. For every screen, decide:

  • Stack order: what is the one thing the user sees first?
  • Touch targets: every interactive element is at least 44x44dp/px.
  • Primary action: one obvious CTA or path, not three equal-weight buttons.
  • Typography: body text is never smaller than 16px; line length under 75 characters.
  • Spacing: 8px grid, 16px base margin, clear section breaks.

4. Scale up with breakpoints

Use a default breakpoint set unless the project already defines one:

NameRangeTypical change
small0–639pxSingle column, stacked, full-bleed or tight margins
medium640–1023px2 columns, wider margins, some side-by-side elements
large1024–1439px12-column grid, sidebar, expanded navigation
xlarge1440px+Max-width container, generous whitespace, enhanced imagery

Break the scale only when the content demands it. Do not copy device breakpoints blindly.

5. Apply framework-specific conventions

Load the relevant reference when the framework is known:

If the user has not chosen a CSS framework, ask or propose one. See references/css-frameworks.md for a Bootstrap vs Tailwind comparison, mobile-first examples, and a token mapping guide. Frameworks are delivery targets, not creative directors: set the design tokens first, then map them to the chosen tool.

  • Bootstrap: override variables and utilities, keep the 8px spacing grid, and test the default theme against the brand.
  • Tailwind: configure the token scale before writing components, avoid class-name soup, and use responsive prefixes to scale the mobile layout up.

6. Critique before shipping

Review the result against the brief and the quality floor:

  • Is the mobile view still the strongest story?
  • Does the design look like it belongs to this product, not to a template?
  • Are colors harmonious and accessible (WCAG AA minimum for text)?
  • Is motion purposeful, not decorative noise?
  • Are forms, errors, empty states, and loading states designed, not left to defaults?

Craft Floor

A result that does not pass these checks is not ready. Verify each one against rendered evidence. See references/craft-floor.md for the full list of checks and bans.

  • Mobile-first layout defined at 375px; the small screen is the strongest story.
  • Touch targets ≥ 44x44px and visually separated.
  • Body text ≥ 16px, measure 45–75ch.
  • Color contrast meets WCAG AA (4.5:1 body, 3:1 large text/controls).
  • Light or dark mode is chosen from the use scene, not the category.
  • Reduced-motion preference respected.
  • Keyboard focus visible and logical.
  • Hover, focus, active, disabled, loading, empty, and error states are designed.
  • Framework defaults are not passed off as brand design.
  • No banned patterns from references/craft-floor.md.

Commands

Use these as sub-requests when the user names a specific task. Each command hands off to polish when its own checks pass.

CommandPurposeReference
shapePlan UX/UI before writing codereferences/shape.md
layoutFix spacing, rhythm, and visual hierarchyreferences/layout-grid.md
typesetImprove typography hierarchy and font choicesreferences/typography.md
colorizeBuild or refine a color systemreferences/color-system.md
adaptAdapt the design across breakpointsreferences/responsive-breakpoints.md
auditCheck a11y, performance, and responsive behaviorreferences/accessibility.md
hardenCover edge cases, i18n, errors, and real-world inputsreferences/harden.md
onboardDesign first-run and empty-state experiencesreferences/onboard.md
polishFinal quality pass before shippingreferences/polish.md

Anti-Patterns to Avoid

  • Designing desktop first and shrinking to mobile.
  • Using the framework's default theme as the brand identity.
  • Adding breakpoints that do not serve a real layout shift.
  • Hiding critical content behind hamburgers on mobile without a fallback.
  • Tiny body text (14px or smaller) on any screen.
  • Purely decorative motion that repeats on every scroll.
  • All-caps labels, centered long paragraphs, and single-word accent colors in headlines.

References

리뷰

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

댓글

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

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

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

0 / 1,000자

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

같은 저장소의 스킬

Single owner of everything under docs/architecture/ — ADRs, architecture and design documents, and architecture diagrams. Routes each deliverable to the right engine: /mermaid-architecture for Markdown-native diagrams, /drawio-architecture for editable .drawio diagrams, and the optional archify skill for interactive standalone HTML diagrams (used only when already installed in the environment; never installed at runtime). Use whenever architecture documentation, ADRs, or architecture diagrams must be created or updated.

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

afonsoft/skills122026년 10월 16일 업데이트

Use when building a new MCP server in TypeScript, Python, or C# that exposes tools to LLMs.

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

afonsoft/skills122026년 10월 16일 업데이트

Use when reviewing code before it merges, whether written by an agent or a human.

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

afonsoft/skills122026년 10월 16일 업데이트

Use when the user asks to connect an AI agent to external apps via Composio, or when Composio CLI or MCP setup fails.

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

afonsoft/skills122026년 10월 16일 업데이트

Use when initializing or migrating an AI agent harness in a repository.

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

afonsoft/skills122026년 10월 16일 업데이트

Use when turning approved plans, specs, PRDs, or Epics into trackable GitHub Issues.

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

afonsoft/skills122026년 10월 16일 업데이트

afonsoft의 스킬 모두 보기

이 스킬의 문제 신고