boxlog-frontend-design
BoxLog専用のフロントエンドデザインスキル。「装飾のない基本体験」を実現するためのUI設計ガイドライン。STYLE_GUIDE.mdを補完し、フォント・アニメーション・デザイン判断基準を提供。
Best use case
boxlog-frontend-design is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
BoxLog専用のフロントエンドデザインスキル。「装飾のない基本体験」を実現するためのUI設計ガイドライン。STYLE_GUIDE.mdを補完し、フォント・アニメーション・デザイン判断基準を提供。
Teams using boxlog-frontend-design should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/boxlog-frontend-design/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How boxlog-frontend-design Compares
| Feature / Agent | boxlog-frontend-design | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
BoxLog専用のフロントエンドデザインスキル。「装飾のない基本体験」を実現するためのUI設計ガイドライン。STYLE_GUIDE.mdを補完し、フォント・アニメーション・デザイン判断基準を提供。
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# BoxLog Frontend Design Skill 「GoogleカレンダーやTogglと同等の装飾のない基本体験」を実現するためのデザインスキル。 > **参照**: 詳細なトークン定義は `docs/design-system/STYLE_GUIDE.md` を確認すること。 ## 設計原則: 装飾のない基本体験 ### 判断基準フローチャート ``` この要素は機能を伝えるために必要か? ├─ Yes → 実装する │ └─ 最小限のスタイルで表現できるか? │ ├─ Yes → そのまま実装 │ └─ No → 機能を分割して再検討 └─ No → 実装しない(装飾的要素は避ける) ``` ### 良い例(採用) | パターン | 理由 | | -------------------- | --------------------- | | 控えめなホバー状態 | 機能的フィードバック | | セマンティックカラー | 意味を伝える色使い | | 一貫したスペーシング | 8pxグリッドで予測可能 | | シンプルなアイコン | 機能を瞬時に伝える | ### 避けるべき例(不採用) | パターン | 理由 | | ------------------------ | ---------------------- | | 派手なグラデーション背景 | 装飾的、集中を妨げる | | 過剰なアニメーション | 生産性ツールにはノイズ | | 影の多用 | フラットで十分 | | イラスト・装飾画像 | 機能に寄与しない | --- ## Typography(タイポグラフィ) ### フォント選定 **現行**: プロジェクトのシステムフォントを維持 ```css /* 変更不要 - システムフォントスタック */ font-family: system-ui, -apple-system, BlinkMacSystemFont, sans-serif; ``` **禁止**: フォント変更の提案(Inter, Roboto, カスタムフォント追加など) ### サイズ・ウェイト STYLE_GUIDE.mdの8pxグリッドに従う: | 用途 | サイズ | ウェイト | Tailwind | | -------- | ------ | -------- | ------------------------ | | 本文 | 16px | 400 | `text-base font-normal` | | 強調本文 | 16px | 500 | `text-base font-medium` | | 小見出し | 24px | 600 | `text-2xl font-semibold` | | ラベル | 14px | 400 | `text-sm font-normal` | --- ## Motion(アニメーション) ### 基本原則: 機能的アニメーションのみ ``` アニメーションを追加する前に確認: 1. ユーザーの操作に対するフィードバックか? → OK 2. 状態変化を伝えるものか? → OK 3. 視覚的な装飾か? → NG ``` ### 許可されるアニメーション | 種類 | 用途 | 実装 | | ---------- | ------------------ | --------------------------------- | | Transition | ホバー、フォーカス | `transition-colors duration-150` | | Fade | 表示/非表示 | `transition-opacity duration-200` | | Scale | 押下フィードバック | `active:scale-95` | ### 禁止されるアニメーション | 種類 | 理由 | | ---------------------------- | ------------------------ | | ページ遷移アニメーション | 速度が優先 | | 背景のパーティクル | 装飾的 | | ローディングの凝った演出 | シンプルなスピナーで十分 | | バウンス、弾性アニメーション | 生産性ツールには不適切 | ### 統一パターン ```tsx // ✅ 標準トランジション(150ms) className = 'transition-colors duration-150'; // ✅ 表示切り替え(200ms) className = 'transition-opacity duration-200'; // ✅ ホバー + 押下フィードバック className = 'transition-colors hover:bg-state-hover active:scale-[0.98]'; // ❌ 過剰なアニメーション className = 'animate-bounce animate-pulse'; ``` --- ## Color(カラー) ### セマンティックトークン厳守 STYLE_GUIDE.mdで定義されたトークンのみ使用。直接色指定禁止。 ```tsx // ✅ セマンティックトークン className = 'bg-card text-foreground border-border'; // ❌ 直接色指定 className = 'bg-white text-gray-900 border-gray-200'; className = 'bg-blue-500'; ``` ### Primary色の制限 Primary = 「ユーザーアクションを促す要素」にのみ: - ✅ CTAボタン、リンク、フォーカスリング - ❌ 装飾、背景、待機状態 --- ## Layout(レイアウト) ### 情報密度 **目標**: Google Calendar / Toggl と同等の情報密度 | コンポーネント | 密度 | | -------------- | -------------------------------- | | カレンダーセル | 高密度(多くのイベント表示可能) | | リスト項目 | 中密度(必要情報のみ) | | フォーム | 低密度(操作性優先) | ### 余白 8pxグリッド厳守(STYLE_GUIDE.md参照): ```tsx // ✅ 8の倍数 className = 'p-4 gap-4'; // 16px // ❌ 8の倍数でない className = 'p-3 gap-5'; // 12px, 20px ``` --- ## Components(コンポーネント設計) ### shadcn/ui活用原則 1. **そのまま使う**: カスタマイズは最小限 2. **薄いラッパー**: スタイル統一のみ 3. **オーバーライド禁止**: 基本動作を変えない ### 新規コンポーネント判断 ``` 新しいコンポーネントが必要か? ├─ shadcn/uiにあるか? → あれば使う ├─ 3箇所以上で使うか? → Yes: components/common/に追加 └─ 1-2箇所のみか? → インラインで実装 ``` --- ## 参照リンク - [STYLE_GUIDE.md](docs/design-system/STYLE_GUIDE.md) - 詳細なトークン定義 - [src/CLAUDE.md](src/CLAUDE.md) - コーディング規約 - [globals.css](src/styles/globals.css) - CSS変数定義 --- **バージョン**: 1.0.0 **最終更新**: 2026-01-19
Related Skills
cc-skill-frontend-patterns
Frontend development patterns for React, Next.js, state management, performance optimization, and UI best practices.
backend-designer-skill
Design backend architecture, API contracts, core business logic boundaries, and language/framework choices based on architecture/story artifacts. Use when selecting backend stack, auth strategy, and service design.
backend-design
Elite Tier Backend standards, including Vertical Slice Architecture, Zero Trust Security, and High-Performance API protocols.
award-winning-designer
The 'Awwwards Singularity' - Transforms websites into breathtaking digital experiences through cinematic motion, 3D graphics, and avant-garde typography. Eradicates boring, template-based web design.
auditor-frontend-ui-ux
Audit frontend code quality, UI/UX, forms, state management, and translations. Typically loaded by the audit-orchestrator skill via sub-agents, but can be used standalone.
architecture-designer
Use when designing new system architecture, reviewing existing designs, or making architectural decisions. Invoke for system design, architecture review, design patterns, ADRs, scalability planning.
architecture-design
Designs comprehensive software solution architectures including system components, technology stacks, integration patterns, scalability strategies, and deployment models. Produces architecture diagrams, technical specifications, and implementation roadmaps. Use when planning new software systems, modernizing legacy applications, designing microservices, evaluating technology choices, creating architecture documentation, or when users mention system design, architecture patterns, scalability planning, or technical architecture decisions.
architecture-design-review
Conducts comprehensive architecture design reviews including system design validation, architecture pattern assessment, quality attributes evaluation, technology stack review, and scalability analysis. Produces detailed review reports with findings, recommendations, and risk assessments. Use when reviewing software architecture designs, validating architecture decisions, assessing system scalability, evaluating technology choices, or when users mention architecture review, design assessment, technical review, or architecture validation.
applying-frontend-patterns
Framework-agnostic frontend component design patterns.
aposd-reviewing-module-design
Evaluate module design using APOSD principles with 40-item checklist. Detect complexity symptoms (change amplification, cognitive load, unknown unknowns), shallow modules, information leakage, pass-through methods, and structural anti-patterns. Produce categorized design review (Critical/Moderate/Observations/Positive). Use when reviewing code, assessing interfaces, during PR review, or evaluating 'is this too complex?' Triggers on: code review, design review, module complexity, interface assessment, PR review, structural analysis.
aposd-maintaining-design-quality
Enforce strategic programming discipline when modifying existing code. Guide through STOP-ASK-DECIDE-VERIFY workflow with urgency tier assessment (trivial/minor/standard/emergency). Include when NOT to refactor (Chesterton's Fence, performance-critical, no tests) and block tactical shortcuts via anti-rationalization tables. Use when fixing bugs, extending features, or tempted to make quick fixes. Triggers on: modify code, fix bug, extend feature, quick fix, tactical change.
aposd-designing-deep-modules
Enforce Design-It-Twice workflow: generate 2-3 radically different approaches, compare them, then implement. Use when designing modules, APIs, or classes before implementation. Triggers on: design, create class, add module, implement feature, new service, API design, before implementing. Produces structured design document with approaches, comparison table, choice rationale, and depth check.