mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-05-18 14:53:05 +08:00
ec9ace9c54
Translate everything-claude-code repository to Japanese including: - 17 root documentation files - 60 agent documentation files - 80 command documentation files - 99 rule files across 18 language directories (common, angular, arkts, cpp, csharp, dart, fsharp, golang, java, kotlin, perl, php, python, ruby, rust, swift, typescript, web) - 199 skill documentation files Total: 455 files translated to Japanese with: - Consistent terminology glossary applied throughout - YAML field names preserved in English (name, description, etc.) - Code blocks and examples untouched (comments translated) - Markdown structure and relative links preserved - Professional translation maintaining technical accuracy This translation expands ECC accessibility to Japanese-speaking developers and teams. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
93 lines
4.1 KiB
Markdown
93 lines
4.1 KiB
Markdown
---
|
|
name: frontend-design-direction
|
|
description: フロントエンド設計の方向性、美的原則、および一貫した設計言語実装。
|
|
origin: community
|
|
---
|
|
|
|
# Frontend Design Direction
|
|
|
|
Use this skill when the work is not just making UI function, but making it feel
|
|
purposeful, polished, and appropriate to the product domain.
|
|
|
|
Source: salvaged from stale community PR #1659 by `linus707`.
|
|
|
|
Note: ECC intentionally does not rebundle the canonical Anthropic
|
|
`frontend-design` skill. Install that from `anthropics/skills` when you want the
|
|
official upstream skill. This skill is the ECC-specific design-direction salvage
|
|
of the useful local guidance from #1659.
|
|
|
|
## When to Use
|
|
|
|
- The user asks to build a web page, app, dashboard, artifact, component, or UI.
|
|
- The user asks to make an interface more polished, distinctive, beautiful, or
|
|
less generic.
|
|
- The implementation needs visual hierarchy, typography, color, motion, layout,
|
|
and interaction choices.
|
|
- The current UI works but reads as flat, generic, templated, or mismatched to
|
|
the audience.
|
|
|
|
## Design Direction
|
|
|
|
Before coding, choose a specific direction:
|
|
|
|
1. Purpose: what job does the interface do?
|
|
2. Audience: who repeats this workflow, and what do they need to scan first?
|
|
3. Tone: utilitarian, editorial, playful, industrial, refined, technical,
|
|
maximal, minimal, dense, calm, or another explicit direction.
|
|
4. Memorable detail: one design idea that makes the result feel intentional.
|
|
5. Constraints: framework, accessibility, performance, responsiveness, and
|
|
existing design system.
|
|
|
|
Match the direction to the domain. A SaaS operations tool should usually be
|
|
dense, quiet, and scannable. A portfolio, launch page, game, or editorial piece
|
|
can be more expressive. Do not force a landing-page composition onto a tool that
|
|
needs repeated daily use.
|
|
|
|
## Implementation Guidance
|
|
|
|
- Build the actual usable experience as the first screen unless the user
|
|
explicitly asks for marketing copy.
|
|
- Use existing project components, tokens, icon libraries, and routing patterns
|
|
before introducing a new visual system.
|
|
- Use real or generated visual assets when the interface depends on images,
|
|
products, places, people, gameplay, charts, or inspectable media.
|
|
- Prefer contextual typography and spacing over generic oversized hero text.
|
|
- Keep palettes multi-dimensional: avoid a UI dominated by one hue family.
|
|
- Use CSS variables or existing design tokens so the direction remains
|
|
coherent across states.
|
|
- Design responsive constraints explicitly: grids, aspect ratios, min/max
|
|
sizes, stable toolbars, and fixed-format controls should not shift when labels
|
|
or hover states appear.
|
|
- Use motion sparingly but deliberately. Prefer high-signal transitions that
|
|
clarify state over decorative animation.
|
|
- Verify text fit on mobile and desktop. Long labels must wrap or resize
|
|
cleanly rather than overflowing.
|
|
|
|
## Anti-Patterns
|
|
|
|
- Do not default to common generated patterns: purple gradients, decorative
|
|
blobs, oversized cards, vague hero copy, or stock-like atmospheric media.
|
|
- Do not add UI cards inside other cards.
|
|
- Do not use a single decorative style everywhere when the domain calls for
|
|
restraint.
|
|
- Do not hide the primary product, tool, object, or workflow behind generic
|
|
marketing sections.
|
|
- Do not add a new dependency for a design flourish unless it clearly pays for
|
|
itself.
|
|
- Do not describe the UI's features inside the UI when the controls can speak
|
|
for themselves.
|
|
|
|
## Review Checklist
|
|
|
|
- The first viewport immediately communicates the product, workflow, or object.
|
|
- The visual hierarchy supports scanning and repeated use.
|
|
- Typography fits the container and does not overlap adjacent content.
|
|
- Color choices have contrast and do not collapse into a one-note palette.
|
|
- Icons are used for familiar tool actions where available.
|
|
- Responsive layout has stable dimensions for boards, grids, toolbars,
|
|
controls, tiles, and counters.
|
|
- Assets render and carry the subject matter instead of acting as filler.
|
|
- Motion improves orientation and does not mask sluggishness.
|
|
- The result matches the repo's existing frontend conventions unless there is a
|
|
clear reason to depart.
|