Communitygithub.com

thecatthatflies/ブランドアイデンティティ

戦略と雰囲気、検証済みのカラーシステム(OKLCHランプ、ライト/ダークテーマ、WCAG準拠ロール)、タイポグラフィ、プロフェッショナルなSVGロゴ、ファビコン、アプリアセット、デザイントークン、ブランドガイドラインを、実際に使えるファイルとして生成します。

ブランドアイデンティティ とは?

このスキルは、「なんとなくかっこいい装飾」ではなく、「一貫した戦略に基づいた本物のブランドアイデンティティ」を、すぐに使えるファイルとして生成します。まずユーザーからブランドの核となる「アイデア」、ターゲット、競合などをヒアリングし、3つの方向性を提示します。その後、知覚的色空間OKLCHを用いた検証済みカラーパレット(ライト/ダークテーマ、WCAG 2.2アクセシビリティチェック済み)、意味と文脈に基づいたタイポグラフィペアリング、そして幾何学的に設計されたSVGロゴ(ワードマーク、幾何学マーク、象徴的マークから選択)を作成します。さらに、ファビコン、アプリアイコン、OGPカードなどのアセット、デザイントークン(JSON)、そしてすべてのルールをまとめたブランドガイドライン用HTMLページも生成します。このスキルは、インターフェース設計(ランディングページやWebアプリなど)のためのスキルと組み合わせて使用することを前提としており、本スキルはその設計の基盤となるブランド定義を提供します。結果はすべてファイルとして出力されるため、開発者はそのままプロジェクトに組み込むことができます。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/thecatthatflies/interface/tree/HEAD/skills/brand-identity

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

ブランドアイデンティティ は何をしますか?

ブランドアイデンティティとは、あらゆる場面で機能する少数の決断のセットです。すなわち、一つのアイデア、それを体現するマーク、そのアイデアを感じさせる色と書体、そして一貫性を保つためのルールです。よくある失敗は、アイデアのない装飾、つまり、グラデーションの塊、ありきたりなサンセリフ体、雰囲気だけで選ばれたパレット、そしてファビコンサイズや単色で潰れてしまうロゴです。このスキルは、これらの決断をファイルとして生成し、実際のレンダラーで検証します。

アイデンティティがインターフェースと接する部分では、interface-guidelinesの階層化された原則(誰でも使える > 真実を伝える > 意味が伝わる > 答えが先 > ミスは許容される > その場に留まる > 可能なことが見える > 慣習 > 洗練)を適用します。もしそのスキルがインストールされていれば、その監査スクリプトが本スキルが生成するガイドラインページをチェックします。

ブリーフ

何かを描き始める前に、これらに回答してください。ユーザーが不在の場合は、brand.jsonに前提条件を記載して作業を進めてください。

  • それは何か、誰のためか、誰に対抗するのか? カテゴリ、オーディエンス、2~3の競合。アイデンティティは、それらと差別化可能でなければなりません。「ブランド一般」と差別化できれば良いわけではありません。
  • 一つのアイデア。 ブランドが何であるかを、シンボルが伝えられる一文で表現します(「窯は柔らかい粘土を永続的なものに変える」)。スタイルではなく、主題、素材、プロセス、場所、約束そのものから取ってきます。references/strategy.mdを参照。
  • パーソナリティ: 3つの特性。それぞれについて、実践上何を意味するか、何を排除するかを記述します。「温かみ:アースカラーと平易な言葉。決して安っぽくならないこと。」
  • 機能しなければならない場所: ファビコン、アプリアイコン、スマートフォン画面、看板、印刷物、刺繍、ソーシャルアバター、ダークモード、メール。最も厳しいコンテキストが複雑さの上限を決定します。
  • 制約: 保持すべき既存の資産(顧客が知っている色、名前)、ライセンスフォントの予算、文化的市場(色や記号の意味は異なる)。
  • マークの複雑さレベル(references/logo.md セクション2):ワードマークのみ、単純な幾何学マーク、または階層的な象徴マーク。野心ではなく、コンテキストとアイデアに基づいて選択します。複雑なマークには、小さいサイズ用の簡略版が必要です。

ワークフロー

1. 方向性を出し、一つに決める

色だけでなく、アイデアが異なる3つの方向性を開発します。それぞれについて:アイデアを一文、ロゴコンセプトの手法(references/logo.md セクション3)、パレットスケッチ(2~3つのシード)、タイプペアリング、そしてそれがどのように感じられるかを一文。ユーザーがいる場合は書き留めて表示し、いない場合は一つ選んでその理由を説明します。方向性を混ぜてはいけません。混ぜると、通常、それぞれが機能していたアイデアが失われます。

2. brand.json を書く

これは、すべてのスクリプトが読み取る唯一の情報源です。最小限の形状は以下の通りです。

{
  "name": "Kiln", "tagline": "Small-batch ceramics, fired in Leeds.", "url": "https://kiln.example",
  "idea": "マークが伝える一文。",
  "personality": [{ "trait": "Warm", "means": "Earth tones and plain words, never slick." }],
  "voice": { "is": ["Plain", "Specific"], "isnt": ["Twee", "Salesy"], "examples": [{ "say": "Fired at 1,260°C.", "not": "Lovingly handcrafted!" }] },
  "colors": { "primary": "#d9480f", "accent": "#0b7285", "neutral": { "chroma": 0.01 } },
  "type": { "display": { "family": "Fraunces", "weights": [400, 700] }, "text": { "family": "Inter", "weights": [400, 600] }, "scale": { "base": 16, "ratio": 1.25 } },
  "logo": { "primary": "logo/lockup.svg", "mark": "logo/mark.svg", "story": "マークがこのように見える理由。", "minSizePx": 16 }
}

3. 色

意味のあるシードを2つまたは3つ選び(references/color.mdを参照)、次に以下を実行します。

node <skill-dir>/scripts/palette.mjs brand.json

これにより、知覚的OKLCHランプが構築され、各シードが最も近いステップで正確に保持され、ニュートラルカラーがブランドに向けて着色され、ステータスカラー(成功、警告、危険、情報)はブランドから分離されるため、危険は常に危険として認識され、ライト/ダークのセマンティックロールがマッピングされ、表示可能なすべてのペアがWCAG 2.2に対してチェックされます。失敗は、シードまたはロールを変更することで修正し、無視してはいけません。tokens/palette.htmlを開き、ライトとダークのデモを確認します。

4. タイポグラフィ

アイデアと読み取りコンテキストに関連した理由(references/typography.mdを参照)をもとに、見出し用書体と本文用書体を選びます(多くの場合、1ファミリーで十分です)。ライセンス、言語対応、ウェイト、数字が重要な場合は表組み用数字、14~16pxでのレンダリングを確認します。ユーザーがライセンスを持っていない限り、オープンライセンス(SIL OFL)のファミリーを優先します。

5. ロゴ

SVGでマークを手描きします。グリッド上でジオメトリを計画し、意図を持ってパスを書き、切り抜きは実際の穴(fill-rule="evenodd" または結合パス)にし、決して白い図形を上から塗って表現してはいけません。ワードマークはアウトライン化して、インストールされているフォントに依存しないようにします。

node <skill-dir>/scripts/logo.mjs outline --text "Kiln" --google "Fraunces:700" --tracking -0.01 --out logo/wordmark.svg
node <skill-dir>/scripts/logo.mjs check logo/*.svg
node <skill-dir>/scripts/logo.mjs sheet logo/lockup.svg --mark logo/mark.svg --colors tokens/tokens.json --out logo/sheet.png

シートを確認します。16pxおよび24pxでもマークがそれ自体として認識できなければなりません。単色の黒、反転、賑やかな画像の上でも、すべてのパーツが消えてはいけません。詳細が消える場合は、簡略化するか、別の小サイズ用マークを描きます。良いマークは通常、数回の縮小プロセスを経ます。ロックアップ(マーク+ワードマーク)は、数学的ではなく、視覚的な位置合わせで構築し、明確なスペースと最小サイズを定義します。詳細とSVGの技術については、references/logo.mdを参照。

6. アセットとシステム

node <skill-dir>/scripts/assets.mjs brand.json    # ファビコン、ICO、Apple Touch、PWAおよびマスク可能アイコン、Open Graphカード、マニフェスト、headタグ
node <skill-dir>/scripts/book.mjs brand.json      # ブランドガイドラインページ + type.css

次に、ブリーフに必要なものを追加します。ソーシャルアバター、メールヘッダー、マークから派生したパターンやテクスチャ、アイコンスタイル、イラストレーションや写真の方向性(references/system.mdを参照)。すべてのアセットは、コピーされた16進数値ではなく、トークンを使用します。

7. 検証と引き渡し

  • 利用可能であれば、ガイドラインページに対してinterface-guidelinesの監査を実行します。node <interface-guidelines>/scripts/audit.mjs brand-book
  • ロゴシート、パレットページ、Open Graphカード、アイコンを自分で確認します。おかしいところを修正します。
  • アイデンティティをコンテキストでテストします。製品の実際の画面(最低でもヘッダーとボタン)にロゴとトークンを配置し、ライトモードとダークモードの両方で確認します。
  • 引き渡し:アイデア、各ファイルの説明、検証した内容、検証していない内容(商標検索、ターゲット市場での文化的レビュー、印刷校正)、および受け入れたコントラスト例外とその理由を伝えます。

注意すべき落とし穴

  • アイデアがなく、スタイルだけ。 「モダンで、クリーンで、ボールド」と選ぶことはアイデアではありません。マークの意味を一文で言えなければ、まだ何も意味していません。
  • ありきたりなマーク: 稲妻、スウッシュ、スパーク、六角形、グラデーションの球体、無改造のイニシャルを円で囲んだもの。アイデアがそれを必要とし、かつ何か独自性がある場合にのみ使用します。
  • 塗りつぶしのように見える切り抜き。 色付きマーク上の白い図形は、単色、写真上、反転時にベタ塗りブロックになります。logo.mjs checkがこれらを検出します。
  • 小さいサイズで消える詳細。 細いストロークや内部の詳細は16pxで消えます。シートにそれが表示されます。小サイズ用マークを用意してください。
  • ロゴSVG内の<text>。 フォントがない場所ではフォールバックフォントでレンダリングされます。アウトライン化してください。
  • ブランドカラーを危険色に、または危険色をブランドカラーにすること。 赤いブランドでも、明確で認識可能な危険色が必要であり、そのエラーテキストはコントラスト基準を満たさなければなりません。
  • 色の意味を事実のように語ること。 「青色は信頼を意味する」は弱く、文化に依存した連想であり、法則ではありません(references/color.md セクション1)。カテゴリ内での差別化とアイデアのために選択します。
  • コピー。 既存のブランドのマーク、名前、またはトレードドレスを再作成したり、酷似させたりしないでください。実際の商標検索は、ローンチ前のユーザーの責任であることに注意してください。
  • 実在の組織の模倣。 その組織ではないユーザーが実在の組織を模倣することはブランディングではありません。辞退してください。

参考資料

ファイル参照するタイミング
references/strategy.mdアイデア、パーソナリティの発見、雰囲気の命名、方向性の作成時
references/logo.mdロゴに関するすべての作業:タイプ、複雑さレベル、コンセプト手法、構成、SVG技術、ロックアップ、テスト
references/color.mdシードの選択、色の意味の根拠、OKLCH、ロール、ダークモード、アクセシビリティ
references/typography.md書体の選択とペアリング、ライセンス、スケール、数字、Web読み込み
references/system.mdアイコン、パターン、画像、モーション、ボイス、アセット、トークン、ガイドライン

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

thecatthatflies/content-site-design

Design, build, write, and review sites people come to read - documentation, developer docs and API references, help centers and knowledge bases, blogs, editorial and news articles, guides, changelogs, and personal or company writing - so readers find the answer fast and agents can read, cite, and navigate them. Use when someone says "build a docs site", "set up our help center", "make my blog", "our docs are hard to navigate", "restructure the knowledge base", "nobody finds anything with search", "write this page so people understand it", "make our docs work for AI coding agents", or when choosing page structure, headings, navigation, search, typography for long reading, or llms.txt and Markdown versions of pages. Not for marketing or launch pages meant to convert (use landing-page-design), app screens (use web-app-design), or visual identity (use brand-identity).

thecatthatflies/form-design

Design, build, and review forms and multi-step flows that people finish without errors and agents can fill without guessing - sign-up and sign-in, checkout and payment details, address and contact forms, applications, onboarding questionnaires, wizards, settings forms, validation and error messages, passwords and passkeys. Use whenever someone builds or fixes a form ("add a sign-up form", "our checkout converts badly", "make these errors better", "why won't autofill work", "turn this into a wizard"), even if they only mention one field. Includes a rendered-page checker for labels, autocomplete, input types, paste, and error wiring. Not for the surrounding app shell, tables, or settings navigation (web-app-design), store layout and product pages (ecommerce-design), or native desktop dialogs (desktop-app-design).

thecatthatflies/landing-page-design

Design and build marketing pages that people remember and understand, and that agents can read accurately - product and launch pages, homepages for a product or studio, pricing pages, waitlists, feature pages, one-pagers, event and campaign pages. Covers art direction (a concept drawn from the subject, one memorable idea, composition), message and page structure, honest proof, pricing, sign-up and waitlist flows, and speed. Use whenever someone asks for a landing page, "a site for my app", "a page to announce X", "make our homepage less generic", "a pricing page", "a coming-soon page", or wants an existing marketing page redesigned or critiqued, even if they only say "make it look good". Consumes brand tokens from `brand-identity` and does not invent logos, palettes or type systems; run that skill first when no brand exists. Not for product UI behind a login (`web-app-design`), docs or blogs (`content-site-design`), storefronts and checkout (`ecommerce-design`), or HTML email (`email-design`).

thecatthatflies/web-app-design

Design, build, and review SaaS and internal web application UI that people use for work and agents can operate - app shells and navigation, list and detail views, data tables with sorting, filtering, bulk actions and pagination, empty states, settings, onboarding, roles and permissions, workspace or tenant switching, optimistic updates and undo, command palettes, and URL-driven view state. Use whenever building or reviewing an admin panel, CRM, back office, internal tool, project tracker, or any logged-in product ("build me an admin for orders", "our app feels clunky", "add bulk delete", "make the table filterable", "add an org switcher"), even when the request names only one screen. Not for KPI and monitoring pages (dashboard-design), forms and wizards in depth (form-design), marketing pages (landing-page-design), native desktop shells (desktop-app-design), or AI chat surfaces (ai-chat-design).

関連スキル