Identity Forge

Identity Forge MCP

コーディングエージェント向けのデザインシステム、ブランド名の考案、ドメイン調査。

人間向け · エージェント向け · MCP ツール · CLI リファレンス · ドキュメント

無料で利用できます。 79種類のデザインキットのうち69種類が無料で、6種類すべてのエクスポート形式、CLI、MCP サーバー、APIを利用できます。アカウントは不要です。Proでは、追加の10種類のキット、月1,000回のAI生成、高度な機能を利用できます。

人間向け

Identity Forgeを使えば、コーディングエージェントは構築を始める前に、完全なビジュアルシステムを利用できます。自分でデザインキットを選ぶことも、製品と希望する雰囲気に合わせて、エージェントにカタログの順位付けを任せることもできます。各キットには、タイポグラフィ、セマンティックカラーのトークン、レイアウト、モチーフ、推奨事項と禁止事項、およびエージェントが実装に使えるDESIGN.mdが含まれています。

エージェントはキットをCSS、Tailwind v3またはv4、shadcnレジストリデータ、DTCGトークン、JSONとしてエクスポートし、競合を防ぎながら適用できます。ブランド名の考案、ドメイン調査、共有可能なクライアントプロジェクトも同じワークフローで利用できます。

公開されているFreeキットは、アカウントなしですぐに利用できます。デザインキットを見る か、インストールの前にエージェントのワークフローの仕組みを読むことができます。

動作を見る

3分間のライフサイクル映像では、最初の選択から、製品画像、ECサイトの再構築、後日のブランド更新、古いサイトの再構築、チームレビューまで、デザインシステムを追っていきます。AubadeのストアフロントとShiftlyの再構築は、実際のIdentity Forgeデザインシステムを使ってエージェントが一度の指示で完成させたものです。Commonkeepのレビューでは、実際のレビュー機能に合成デモデータを使用しています。

https://github.com/user-attachments/assets/fc3cdba2-4876-46e5-a92a-09ce6d7071ff

1080pのフル解像度WebMをダウンロード。

エージェント向け

使用するクライアントにローカルMCP サーバーをインストールします。

npx --yes identityforge@latest install --client claude-code   # Claude Code
npx --yes identityforge@latest install --client cursor        # Cursor
npx --yes identityforge@latest install --client vscode        # VS Code / Copilot
npx --yes identityforge@latest install --client codex         # Codex

gemini、opencode、piにも対応しています。どのクライアントも同じローカルstdioサーバーを実行し、installは既存の設定を置き換えずにマージします。7種類すべての設定パスはエージェントへのインストールに記載しています。

公開されているFreeキットは、キーなしですぐに利用できます。エージェントに次のように指示してください。

Identity Forgeを使ってこの製品に合うテーマを選び、適用して、DESIGN.mdに従ってください。

永続的なプロジェクト、作業の保存、認証済みの利用枠、Proへのアクセスには、サインインしてください。

npx --yes identityforge@latest login

まだアカウントをお持ちでない場合は、ブラウザーで登録してセキュリティチェックを完了し、Send verification emailを選択して、メール内のリンクを開いてください。次にConfirm email and continueを選択し、再開された認証を承認すると、CLIが自動的にキーを受け取ります。

ユースケースの検出

各ユースケースレーンには2つのチェックがあります。まず、キットの作成者が想定する対象ユーザーまたは bestFor に、その種の製品が記載されている必要があります。次に、テキストのコントラスト、グラフの系列の識別しやすさ、情報密度など、具体的なトークンの測定値によって、条件を満たすキットを順位付けします。ビジュアルタグは検索に役立ちますが、製品との適合性を決めるものではありません。技術スコアが高くても、無関係なキットがレーンに入ることはありません。レーンごとの文章による説明は、カタログ全体の再エンリッチが完了するまで無効になっているため、スコアが表示されても、その理由を説明する文はありません。

• list_themes({ use: "data-dashboard" }) は、ダッシュボード向けに作成されたキットを返し、測定されたダッシュボード適合度の順に並べます。
• list_themes({ q: "calm fintech dashboard" }) は、ムード、業界、ユースケースを横断して、同義語を考慮したランキング検索を実行します。
• search_themes は、エージェントが微妙な要件を自ら判断できるよう、カタログ全体を順位付けせずに返します。

レーンで候補を絞り込み、並び順を比較に活用してください。スコアを説明として扱わないでください。スコアは作成者の意図を踏まえて技術的な適合度を順位付けしますが、そのキットが特定の要件に適している理由を示すものではありません。

データ関連のレーンでは、スコアよりも優れた判断材料があります。各キットの概要には、キットが提供するモードで測定された charts ブロックが含まれています。minDeltaE と cvdMinDeltaE（最も近い系列色のペア。通常時と色覚シミュレーション時）、distinct、hueFamilies、severityHeadroom（破壊的、警告、成功の各役割に、いずれかの系列がどれだけ近いか。0はカテゴリ色がステータス色と同じであることを示します）、sequentialReady、そして、キットにグラフ用スロットが定義されておらず、ブランドカラーの役割から5色を順番に割り当てた場合に false となる designed です。これらは測定値なので、適合度スコアとは異なり、推奨理由としてユーザーに示すことができます。

ユースケースレーン：data-dashboard、admin-internal-tool、saas-marketing、landing-page、ecommerce-store、portfolio、editorial-blog、docs-knowledge-base、mobile-app、business-services、community-social、ai-agent-chat。

同じ検出機能はキットギャラリーとHTTP API（GET /api/v1/kits?use=…&q=…。詳しくはllms.txtを参照）でも利用できます。

エージェントへのインストール

install --client <name> は、そのエージェント用の MCP サーバー設定を書き込み、既存の設定があれば統合します。

クライアント	--client	設定ファイル
Claude Code	claude-code	.mcp.json
Cursor	cursor	.cursor/mcp.json
Codex	codex	~/.codex/config.toml
Gemini CLI	gemini	.gemini/settings.json
VS Code / Copilot	vscode	.vscode/mcp.json
opencode	opencode	opencode.json
Pi	pi	.pi/agent/mcp.json

どのクライアントも、同じローカルの stdio サーバー npx -y identityforge@latest mcp を実行します。 インストール後、identityforge doctor --client <name> は、クライアントが最新パッケージを参照していることを確認し、Identity Forge API の呼び出しやクォータの消費を行わずに、パッケージの MCP サーバーを初期化します。

エージェントプラグインとスキルをインストールする

このリポジトリには、エージェントに Identity Forge を使うタイミング、無料アクセスと認証済みアクセスの違い、保留中のブラウザー認証を再開する前に人間を Send verification email へ誘導する方法を伝える Agent Skill も、MCP サーバーとともに含まれています。

Claude Code：

claude plugin marketplace add KasayoDotCom/identityforge-mcp
claude plugin install identity-forge@identity-forge

GitHub Copilot CLI：

copilot plugin marketplace add KasayoDotCom/identityforge-mcp
copilot plugin install identity-forge@identity-forge

Codex およびその他の Agent Skills 対応クライアント：

npx skills add KasayoDotCom/identityforge-mcp

ディレクトリ配布用に Cursor のメタデータも含まれています。そこに掲載されるまでは、上記の install --client cursor コマンドを使って同じ MCP サーバーに接続してください。

MCP ツール

接続すると、エージェントは63個のツールを利用できます。無料キットの閲覧にキーは不要です。適用されるスコープは記載されています。

デザインキットを探す

• list_themes：カタログを簡潔な概要で閲覧します。use で用途の分野ごとに順位付けし、q で順位付け検索を実行し、offset でページを指定します。featured、popular、recent、name、fit で並べ替えます。
• search_themes：順位付けせずにカタログ全体を返します。用途の分野に照らした順位付けが難しい、繊細な要件のブリーフに適しています。
• similar_themes：キットのスラッグを指定すると、配色、タグ、対象ユーザーを基に類似するキットを探します。
• match_palette：既存のブランドカラーを指定すると、知覚的な色差に基づいてキットを順位付けします。

キット以外のフォントを選ぶ

キットには見出し、本文、等幅フォントがすでに指定されています。次の2つのツールは、指定がない場合に使用します。

• search_fonts：Google Fonts カタログを名前やカテゴリで閲覧するか、すでに使用しているフォントファミリーを like に渡して、似たフォントを探します。取得できるのはメタデータのみで、like は字形を読み取らないため、見た目を確認してから提案してください。
• suggest_font_pairings：見出し／本文／等幅フォントの厳選された一覧を取得するか、ユーザーが使うと決めているフォントファミリーに合うフォントを探します。

キットを読み込んで適用する

• get_design_md：キットの DESIGN.md（完全版のデザインブリーフ）を取得します。
• get_tokens：トークンを dtcg、css、tailwind-v3、tailwind-v4、shadcn-registry、または json 形式で取得します。
• apply_theme：DESIGN.md、トークンファイル、identityforge.json のスタンプをプロジェクトに書き込みます。自ら書き込んだファイル以外は上書きせず、その場合は拒否します。詳細は以下をご覧ください。

apply が書き込むファイルと、上書きしないファイル

apply_theme（および identityforge apply）は、対象ディレクトリに3つのファイルを書き込みます。

Identity Forge のリクエストには、現在の CLI または MCP プロセス内でのみ有効なランダムな参照 ID が付与されます。ローカルでの適用結果は、書き込まれたファイル、すでに最新のアーティファクト、安全な競合による拒否、または失敗した段階のいずれかとして報告されます。レポートには件数と分類のみが含まれ、ローカルパスやエラーの説明文は含まれません。 MCP サーバーとして実行する場合、リクエストには、エディターまたはエージェントが MCP ハンドシェイクですでに送信しているクライアント名（claude-code、cursor-vscode、codex）も含まれます。これにより、利用状況を製品ごとに把握できます。パス、ファイル名、プロンプト、ファイルの内容、リポジトリ名、例外テキスト、永続的なインストール識別子は、いずれも含まれません。プロセス参照 ID とローカルでの結果レポートを省略するには、IDENTITYFORGE_TELEMETRY=0 を設定してください。通常の API リクエストは引き続きサーバーのアクセスログに記録されます。

ファイル	内容
DESIGN.md	エージェントが基にするデザインブリーフ
<slug>.css / .json / .js	指定した形式の名前が付いたトークン
identityforge.json	スタンプ。適用したキット、そのバージョン、書き込んだ各ファイルの SHA-256 を記録します

スタンプはキットではなく、リポジトリに属します。このコードベースが何を基に構築されたかを記録します。これはサーバーには分からない情報なので、スタンプをコミットしてください。また、スタンプがあることで安全に適用できます。apply は何かを書き込む前に、ディスク上のファイルとスタンプ内のハッシュを照合します。

• 存在しないファイルは作成されます。
• 内容がすでにキットと一致するファイルは、そのまま残されます。
• 直近の適用で書き込まれ、バイト単位で変更されていないファイルは、キットが更新されていれば更新されます。
• スタンプに記録されていないファイル（自分で作成した DESIGN.md など）、または書き込まれた後に変更されたファイルは、競合となります。

競合がある場合、デフォルトでは何も書き込まず、競合しているファイルをすべて示して、ゼロ以外の終了コードで終了します。すべてのファイルについて処理を計画してから書き込むため、取得に失敗してもディレクトリへの適用が中途半端になることはありません。

identityforge apply acid-signal-black --preview   # plan only, writes nothing
identityforge apply acid-signal-black             # refuses if anything conflicts
identityforge apply acid-signal-black --force     # overwrites, content is lost

--force は破壊的な操作で、元に戻せません。競合しているファイルの現在の内容は失われ、レポートには各ファイルの名前が示されます。まずプレビューを行い、変更内容をユーザーに示して、判断を委ねてください。

スタンプに記録される内容と、後続の apply での読み取り方法

{
  "stampVersion": 1,          // shape of this file, so a reader never has to guess
  "designMdContract": "1.0",  // shape of the DESIGN.md you built against — not the kit's
                              // revision and not this file's. Three different versions
                              // live here; flattening any two invents a baseline.
  "kit": {
    "id": "c2d13a12-…",       // permanent. diff against this, never the slug
    "slug": "sage-slate-editorial",
    "version": 0,             // the kit's monotonic revision, as the export reported it
    "designMdDigest": "sha256:…"
  },
  "layers": [],
  "artifacts": [{ "path": "DESIGN.md", "hash": "sha256:…", "writtenAt": "…" }],
  "integration": { "tokensEntry": null },
  "appliedAt": "…"
}

kit.version には、混同してはならない3つの異なる意味があります。数値はキットのリビジョンです。0 は、キットは存在するものの、まだバージョンが付与されていないことを意味します。 null は、エクスポートでバージョンが報告されなかったことを意味し、これは別の事実です。これを 0 として読み取ると、実際には存在しなかったベースラインがリポジトリに設定されてしまいます。 ID はエクスポートのフロントマターからそのままコピーされます。ここでは何も推測しません。

再適用時には、これを読み取ります。

• バージョンが変わった — サーバー独自のカウントで、キットが変更されたことが示されています。ブリーフを再確認してください。
• バージョンは同じで、レンダリングされたファイルが異なる — 変更されたのは DESIGN.md のシリアライザーであり、キットではありません。対応は不要です。
• 両方ともバージョンがない — 利用できるのはダイジェストだけで、上記の2つのケースを区別できないため、推測せずその旨を伝えます。

ID は永続的な識別子であるため、キットのスラッグを変更しても、「別のキットを適用した」とは報告されません。自分の CLI より新しい CLI が書き込んだスタンプは、十分に読み取れないまま処理するのではなく拒否されます。すべてのファイルが未記録として扱われるため、完全に読み取れない記録をもとに上書きすることなく、apply は停止します。

status：スタンプに変更点を確認する

identityforge status              # the current directory
identityforge status --dir apps/web

スタンプにキットとバージョンの両方がすでに記録されているため、キットもバージョンも指定する必要はありません。themes diff --from N では、キットを把握し、JSON から数値を自分で読み取る必要があります。apply --preview ではスラッグを指定し、読み取り専用の質問に答えるために書き込み計画全体を取得する必要があります。status は identityforge.json を読み取り、ID でサーバーに問い合わせ、スタンプからわかる3種類の変更を個別に報告します。

• kitMoved — サーバー独自のバージョンカウントが異なります。デザインが変更されています。
• documentMoved — レンダリングされた DESIGN.md のバイト列が異なります。シリアライザーの変更だけでもすべてのキットに一度に影響するため、これだけを理由にコードを変更する必要はありません。
• contractMoved — designMdContract が異なります。ドキュメントの構造が変更されています。セクションの追加、名前の変更、削除などです。これは3つ目の別の観点であり、他の2つでは判断できません。

片側の情報だけでは判断できない場合、各項目は false ではなく null になり、どちら側の情報がなかったかを注記します。キットが変更され、両方のバージョンが数値である場合は、themes diff が出力したであろうものと同じ差分が含まれます。また、スタンプに記録された各成果物をディスク上のファイルと照合してハッシュ化するため、後から手作業で編集した DESIGN.md は、再適用で上書きする前に modified と表示されます。

何も書き込まず、作業ツリーにも触れません。キーを紛失した場合や Pro の利用制限に達した場合は、失敗するのではなく、注記付きのローカルのみのレポートに切り替わります。JSON は stdout に、人向けの概要は stderr に出力されるため、identityforge status | jq .moved が使え、同時に人には説明文が表示されます。

補完的なコレクション

これらはキットでは答えられない質問に答えるもので、キットの代わりにはなりません。

• list_image_directions / get_image_direction：プロジェクトの画像をどのように提示し、繰り返し使うかを選択してエクスポートします。
• list_interface_styles / get_interface_style：サーフェスと階層構造に適用する中立的なレンダリング文法を選択してエクスポートします。適用にはキットを使用します。
• list_page_recipes / get_page_recipe：ページでどのように主張を展開するかを選択してエクスポートします。

ユーザーが実在する製品、人、物体を提供した場合は、承認済みの画像を、参照画像を保持する画像エディターへの固定入力として使用します。設定、補助要素、構図、照明、表面、トリミング、仕上げ、バリエーションのルールを工夫して、プロジェクトに固有の見せ方を組み立てます。元画像のアイデンティティを正確に保ち、すべての結果をフル解像度で元画像と比較してください。また、既存の製品をテキストから再現したり、切り抜き画像を別途生成した背景に重ねたりしないでください。現在のエージェントが参照画像を使った編集に対応していない場合は、元画像とエクスポートしたディレクションを製品画像ワークフローに引き渡してください。このフローでは、Identity Forge はブリーフを提供するものであり、画像をレンダリングするものではありません。

作成者向けキットとブランド（kits:write）

• create_theme：トークン、色、フォント、ファセットプリセットを対象とするオーバーライドを使って、一から、またはカタログキットをフォークして、プライベートキットを作成します。
• remix_theme：解決可能なキットをコピーし、オーバーライドを適用して新しいプライベートキットを作成します。
• update_theme：保存済みキットのスラッグと公開状態を維持したまま、その場で編集します。既存の利用者にも変更が反映されます。保存済みのキットは上書きされますが、保存のたびにバージョンが作成されるため、置き換え前の状態も下記のバージョンツールから引き続き参照できます。ここではスラッグを変更できません。また、expectedUpdatedAt を指定すると、同時編集が発生した場合に、無言で上書きする代わりに 409 が返されます。
• delete_theme：保存済みキットを完全に削除します。confirm: true を指定してください。ブランドプロジェクトから参照されているキットは 409 kit_in_use で削除を拒否されるため、先にその参照を解除するか、別のキットに切り替えてください。
• create_brand_project と list_brand_projects：ブランドのバリエーションとクライアント共有を管理するコンテナです。
• add_brand_variation：キットに加え、任意で名前、ドメイン、ラベル、メモを指定して、プロジェクトに提案を追加します。
• update_brand_variation：別のキットへの切り替えも含め、提案をその場で編集します。クライアントが次に表示したときに変更が反映されます。
• remove_brand_variation：提案とそのコメントを完全に削除します。confirm: true を指定してください。取り消しはできません。
• revoke_brand_share：クライアント用リンクを完全に無効化します。confirm: true を指定してください。再共有すると新しいトークンが作成されます。
• reorder_brand_variations：クライアントに提示する方向性の順序を設定します。すべてのバリエーションを一度ずつ指定する必要があります。
• share_brand_project：読み取り専用の /p/<token> クライアント共有リンクを作成または更新します。必要に応じてパスワードで保護できます。
• list_client_comments（kits:read）：各バリエーションについてクライアントが書いた内容を読み取ります。共有のやり取りを受け取るためのツールです。

ブランドに他の軸を組み合わせる

ブランドは、デザインキットに画像の方向性、インターフェーススタイル、任意の数のページレシピを組み合わせたものです。これらの参照先はキットではなくプロジェクトにあるため、キットを入れ替えてもそのまま維持されます。

• get_brand_layers（kits:read）：ブランドを構成する要素を取得します。すべての参照にリビジョン番号が付き、固定後にレコードが変更された場合に限り drift が表示されます。meta.drifted は変更された参照の数を示し、links.preview は構成を画像としてレンダリングしたものです。ブランドに対する変更はありません。バージョンは作成されず、固定されたリビジョンも変わりません。
• add_brand_layer：現在のリビジョンを記録してレコードをブランドに追加します。後で読み取る際に、変更を黙って適用するのではなく、変更があったことを報告できます。axis を使って3つの軸すべてに対応する単一のツールです。画像の方向性とインターフェーススタイルはそれぞれ1つまでで、replace: true を指定しない限り、2つ目の追加は 409 で拒否されます。replace: true は、ドリフトしたリビジョンを受け入れる場合にも使います。
• remove_brand_layer：レイヤーを1つ削除します。confirm: true を指定してください。軸ではなくレコードを指定するため、古いビューから、見たことのないレイヤーが削除されることはありません。また、同じ操作を繰り返しても何も起こりません。
• export_brand（kits:read）：ブランドを、構築に使える1つのドキュメントとして出力します。キットの DESIGN.md に固定済みのすべてのレイヤーを書き込み、意見が異なる場合にどちらを優先するかを決める優先順位ルール（アイデンティティはキットが、適用方法はレイヤーが担います）を適用します。キットと各レイヤーを自分で結合する代わりに、このツールを使ってください。キーで開けないレイヤーは削除されず、該当するページとアップグレード方法が示されます。選択済みのキットがないブランドでは、誰も選んでいないプレースホルダーを返す代わりに 409 が返されます。

プロダクトを一度説明すれば、それに基づいた提案が得られます

• get_project_context / set_project_context：ブランドプロジェクトに、プロダクトの概要（機能、対象ユーザー、制約、採用しないと決めたこと、画面、技術スタック）を保存します。以降の提案はすべてこの情報に基づきます。説明を把握していないセッションでも同様です。
• recommend_kits({projectId})：そのプロダクト向けの候補を提示します。各候補には、キット独自の根拠と、プロダクトが実際に備える画面に対する適合性の評価が含まれます。Pro と kits:write キーを利用すると、候補ごとの理由を含むモデルによるランキングも取得できます。meta.depth は ranked または candidates です。

意外に思われる点が2つあります。

• set_project_context は置き換えます。 エンドポイントは PATCH ではなく PUT なので、省略したフィールドは保持されず削除されます。これは意図的な仕様です。マージ更新だと、一覧から画面を削除しても古い画面が気付かれないまま残る可能性があるためです。ただし、編集内容を反映したオブジェクト全体を送る前に、get_project_context で読み込む必要があります。
• recommend_kits はクォータを3ユニット消費し、キーが必要です。 一方、list_themes は1ユニット消費し、それ以外の探索ルートはすべて匿名で利用できます。この理由はルート自身の docstring に記載されています。クエリパラメーターではなく自由記述の本文を受け取り、従量課金のモデル呼び出しへ発展する可能性がある唯一のルートだからです。コンテキストの書き込みには kits:write が必要ですが、読み込みには kits:read だけで済みます。

構築してから変更されていますか？（読み取り専用）

• list_kit_versions、get_kit_version、diff_kit_versions：キットのバージョン履歴、過去のスナップショット全体、2つのバージョン間で変更された内容です。上限を指定せずに diff_kit_versions({slug, from}) を呼び出すと、現在のバージョンと比較します。これは、identityforge.json があるリポジトリが実際に知りたいことです。

• list_brand_project_versions、get_brand_project_version、diff_brand_project_versions：ブランドプロジェクト向けの同じ3つの機能です。オーナーごとにスコープが設定されています。

• list_kit_history、get_kit_history_event：同じキットの履歴台帳です。バージョン履歴よりも幅広い記録を扱います。kit_history_events には「作成」「保存」「ブランドへの適用」の3種類のイベントがあり、バージョンが作成されるのは最初の2つだけです。そのため、適用の記録は台帳にのみ残ります。キットが実際に使われたことがあるかは台帳で確認し、トークンの内容はバージョン履歴で確認してください。イベントにはページ送りに使える順序番号がないため、バージョン番号ではなく不透明なカーソルを使ってページ送りします。 共有：一時停止するか、取り消すか。 可逆的な update-share がほとんどの場合に適した方法です。--disable でリンクを一時停止でき、トークンはそのままです。クライアントがすでに持っている URL は、再開した時点ですぐに再び使えるようになります。revoke-share は取り消すと元に戻せません。貼り付け先がどこであっても、すでに送信済みのメール内も含め、/p/<token> URL は解決されなくなります。再度共有すると新しいトークンが発行され、古いトークンが再利用されることはありません。--yes を指定しない場合、この操作は拒否されます。

• whoami：プラン、付与済みおよび不足しているスコープ、残りのクォータ、AI クレジット、保存できるキット数です。無料で利用でき、クォータ超過によって拒否されることはありません。そのため、429 の発生後も応答します。

これらの操作はいずれも何も書き込みません。古い状態に戻すには、意図的に update_theme を呼び出してください。

実際に履歴が残るもの。 保存済みのキットと管理対象カタログのキットには、バージョンが蓄積されます。静的カタログのフォールバックは、管理対象カタログに昇格するまでバージョン 0 のままです。別途用意されたキット履歴台帳はオーナーのみが参照でき、作成、保存、ブランドへの適用を記録します。ブランドプロジェクトでは、名前とドメイン、フォント、固定レイヤー、プロジェクトのコンテキスト、並べ替えを含むバリエーションなど、ブランド全体が記録されます。意図的に記録されないのは共有です。ブランドを誰が見られるかは、ブランドそのものではないからです。

Pro の制限による影響。 利用権のないキットの場合でも、バージョン履歴にはバージョンが表示されますが、作成者の自由記述のメモは null になり、差分では各変更に redacted: true とパスおよび CSS 変数が表示される一方、変更前後の値は表示されません。また、redactedChanges の件数も返されます。get_kit_version はペイロード全体を返すため、代わりに 403 を返します。

ブランド名を付ける（naming:read / naming:write）

• list_naming_recipes：命名戦略のカタログ全体を表示します。
• list_naming_projects と create_naming_project：既存のボードを再利用するか、永続的なボードを作成します。
• generate_names：Identity Forge 独自のモデルを使って名前を生成します。一意の候補が保存された場合にのみ、AI クレジットを消費します。
• add_name_candidates：アクティブなエージェント、承認済みのオフラインプロセス、または手動調査から得た名前を、安定した呼び出し元 UUID を使って保存します。クレジットは消費しません。
• list_name_candidates：出典情報と根拠を含むカンバンボードを読み取ります。
• list_name_generations：モデル、プロンプト、リクエスト、クレジットの出所を監査します。
• move_name_candidates と rank_name_candidates：候補をまとめて確認し、絞り込み、順位付け、選定します。
• get_naming_research_context：サーバーによる順位付けを行わずに、ブリーフ、ボード、根拠、機能、小規模タスクの引き継ぎ契約を読み取ります。
• search_name_evidence：セルフホストの SearXNG を通じて、モデルが作成した検索を範囲限定で実行し、判定を加えずに根拠を返します。クエリごとに、アカウント全体の月間利用枠を 1 単位消費します。
• check_domains：DNS と、個別の RDAP、レジストラ、任意のセルフホスト SERP の根拠を調べます。基本調査では一意のドメインごとに 1 単位を消費し、SERP を追加するとさらに 1 単位を消費します。DNS レコードが存在しない場合、それはドメインを取得できる可能性があることを示すだけです。
• assess_domain_acquisition：新規登録、アフターマーケットでの購入、またはそのどちらも目標とするかを指定します。レジストラの登録状況に関する根拠と、範囲を限定した公開ランディングページの根拠を分けて報告します。これには、販売を示す文言、マーケットプレイス、予約済みページ、表示価格のシグナルが含まれます。販売者の正当性を検証したり、購入を保証したりすることはありません。アフターマーケットの根拠を調べると、一意のドメインごとに 1 単位を消費します。10 分以内に同じ内容で正常に再実行した場合は、クレジットを消費しません。

商標のスクリーニングは、該当する各管轄区域の公式登録簿を使った別途の手動作業として行ってください。検索クエリ、区分、情報源の URL、結果の文言、日付を記録してください。これは予備調査であり、法的なクリアランスではありません。

ブランドを構築し、クライアントと共有する

kits:write ツールを使うと、エージェントはブランド一式を最初から最後まで構築できます。

1. create_theme または remix_theme を使い、対照的な 4 つまたは 5 つの方向性を組み立てます。カタログのキットを分岐して色、フォント、ファセットを上書きする方法と、最初から作成する方法があります。
2. クライアントのブリーフごとに 1 つのプロジェクトを作成するため、create_brand_project を使います。
3. add_brand_variation を使い、ブランド名、ドメイン、ラベルを付けて各方向性を追加します。
4. share_brand_project を使い、クライアントに /p/<token> リンクを渡します。任意でパスワードを設定できます。クライアントはこのリンクから各バリエーションを切り替えてコメントできます。
5. list_client_comments で返信を確認し、update_theme、update_brand_variation、remove_brand_variation、reorder_brand_variations を使って、2 つ目のボードを作らずに同じボードを修正します。

エージェントは、作成したものをすべて修正することもできます。書き込みツールは、クライアントから見えるライブ状態を変更します。破壊的なツールを実行するには confirm: true が必要なので、変更を適用する前にフィードバックを確認してください。

新しいキーには、デフォルトで kits:write が付与されます。このスコープが追加される前に発行されたキーは、identityforge login を再実行するか、新しいスコープ付きキーを作成するまで 403 を返します。

MCP サーバーには、接続時にこのワークフローを説明する指示も含まれているため、接続したエージェントは手順を伝えられなくても、意図からキットの適用までの進め方を把握できます。

エージェントがキットを選ぶ方法

エージェントにルック＆フィールを尋ねると、次のように進めます。

1. 意図を把握する：製品の内容、対象ユーザー、希望する雰囲気を確認します。たとえば、「中小企業向けの、落ち着きと信頼感のあるフィンテックダッシュボード」のように伝えます。
2. 候補を探す：構築対象がユースケースのカテゴリに当てはまる場合は list_themes({ use })、検索結果を順位付けする場合は list_themes({ q })、漠然とした要望をもとにカタログ全体を順位付けする場合は search_themes を使います。ブランドカラーがすでにある場合は、match_palette({ colors }) で最も近いキットを探します。
3. 確認する：各結果には、名前、タグ、フォントと色の概要、ティア、適合度の評価を簡潔にまとめています。similar_themes(slug) で類似するキットを確認し、適用を決める前に get_design_md(slug) でブリーフ全体を読みます。
4. 適用する：apply_theme(slug) を実行すると、必要に応じてスタックに合った tokensFormat を指定し、DESIGN.md、トークンファイル、identityforge.json のスタンプをプロジェクトに書き込みます。プロジェクトにこのツールが書き込んでいないファイルがすでにある場合は、上書きせずに競合を表示します。
5. 実装する：DESIGN.md に従い、CSS 変数、Tailwind の @theme ブロック、shadcn のいずれを使う場合も、トークンをスタイリングレイヤーに組み込みます。

説明が具体的であるほど、より適切な候補が見つかります。

ID とスラッグ

すべてのキットには不透明な id と slug があり、どちらを使っても直接指定できるため、キットが決まった後は検索を省略できます。両者の永続性は異なります。

• id は変更されません。一度発行されると再割り当てされず、常に同じキットを参照します。
• slug は所有者が変更できる公開用の識別子です。廃止されたスラッグはエイリアス経由で引き続き解決されるため、名前を変更しただけで参照できなくなることはありません。ただし、空いたスラッグは後から別のキットが取得でき、その場合は有効なキットが優先されます。そのため、保存していたスラッグがエラーになるのではなく、気付かないうちに別のキットを参照し始める可能性があります。

人が入力した場合はスラッグを渡します。エージェントが保持するもの、たとえば設定値、バージョンスタンプ、後のセッションで再利用する選択内容には ID を保存してください。list_themes は両方を表示します。

画像の方向性、インターフェーススタイル、ページのレシピにも ID があります。これらにはエイリアステーブルがないため、スラッグ名を変更すると解決できなくなります。同じ注意がさらに強く当てはまります。

CLI コマンド

npx -y identityforge@latest login    # browser sign-in (PKCE loopback)
identityforge login --key ifk_…      # or paste a key (headless)
identityforge whoami                 # plan, scopes, quota, credits, saved-kit slots (free)
identityforge usage                  # alias for whoami
identityforge update-check           # current/latest package version as JSON
identityforge doctor --client codex  # verify config and MCP capabilities without API usage
identityforge logout                 # remove stored credentials
identityforge themes                 # list kits
identityforge themes -q "fintech dashboard, calm and trustworthy"
identityforge themes get <id|slug>   # print DESIGN.md to stdout, writing nothing
identityforge themes get <id|slug> --format tailwind-v4 > tokens.css
identityforge themes get <id|slug> --format json      # the whole kit
identityforge themes get <id|slug> --marker           # stale-write marker only

# Author, fork, and find neighbours (kits:write for the first two)
identityforge themes create --name "Acme" --base bento-noir --overrides o.json
identityforge themes remix <id|slug> --overrides o.json   # copies; original untouched
identityforge themes delete <id|slug> --yes                # permanent; refuses kits still in use
identityforge themes similar <id|slug>                    # nearby published kits
identityforge themes match "#1d4ed8" "#f97316"            # kits closest to colors you hold

# Typography, for the cases a kit does not already settle
identityforge fonts search grotesk --category sans-serif   # Google Fonts metadata, no files
identityforge fonts similar Inter                          # faces that resemble one you have
identityforge fonts pairings Fraunces --role heading       # curated table + contrast suggestions

# Has this kit moved since I built against it? (read-only)
identityforge themes versions <id|slug>               # version timeline, newest first
identityforge themes version <id|slug> 3              # one past snapshot, whole kit
identityforge themes diff <id|slug> --from 3          # what changed since version 3

# Everything that happened to it, which is a wider record (read-only)
identityforge themes history <id|slug>                # + every apply-to-brand
identityforge themes history <id|slug> --cursor "$NEXT"
identityforge themes snapshot <id|slug> <event-id>    # the kit at that entry

# Build a client brand project and read the feedback back (kits:write)
identityforge brand create --name "Acme rebrand" --brief "Calm fintech"
identityforge brand add-variation --project <uuid> --kit <id|slug> --brand-name Acme --label "Direction A"
identityforge brand share --project <uuid> --password hunter2
identityforge brand update-share --project <uuid> --disable   # pause; token survives
identityforge brand revoke-share --project <uuid> --yes       # permanent, new token next time
identityforge brand get --project <uuid>              # one project in full
identityforge brand layers --project <uuid>           # pinned catalogue records
identityforge brand add-layer --project <uuid> --axis imageDirection --record <id>
identityforge brand remove-layer --project <uuid> --axis imageDirection --record <id> --yes
# The kit's DESIGN.md with every pinned layer composed into it: the one document to build from
identityforge brand export --project <uuid> > DESIGN.md
identityforge brand comments --project <uuid>
identityforge brand projects
# Describe the product once, then ask for grounded proposals
identityforge brand context --project <uuid>          # read the stored context
identityforge brand set-context --project <uuid> --file context.json   # REPLACES it
identityforge brand recommend --project <uuid>        # candidates (3 units, needs a key)
# Queue mockups: one AI credit per variation and scene combination
identityforge brand mockups generate --project <uuid> --variation <uuid> --item tshirt:front
identityforge brand mockups list --project <uuid>
identityforge brand mockups get --project <uuid> --job <uuid>

identityforge brand versions --project <uuid>         # project history
identityforge brand version 3 --project <uuid>        # one stored version, in full
identityforge brand diff --project <uuid> --from 2

# Act on the feedback: revise, retire, reorder (kits:write)
identityforge brand update-variation --project <uuid> --variation <uuid> --label "Warmer" --clear notes
identityforge brand remove-variation --project <uuid> --variation <uuid> --yes
identityforge brand reorder --project <uuid> <variation-uuid> <variation-uuid> <variation-uuid>
identityforge themes update <id|slug> --name "Acme v2" --expected-updated-at "$MARKER"
identityforge image-directions list  # list public imagery judgments
identityforge image-directions get <slug> --format markdown
identityforge interface-styles list  # list public render-grammar judgments
identityforge interface-styles get <slug> --format markdown
identityforge page-recipes list      # list public page communication judgments
identityforge page-recipes get <slug> --format markdown
identityforge apply <slug>           # write DESIGN.md + tokens + stamp into the current dir
identityforge apply <slug> --preview # plan it first, writing nothing
identityforge status                 # read the stamp: has the kit, the document, or its shape moved?
identityforge status --dir apps/web
identityforge mcp                    # run the MCP server over stdio

# Naming commands always print JSON
identityforge naming recipes
identityforge naming projects
identityforge naming create-project --name "My product" --description "Product, audience, market, desired character"
identityforge naming generate --project <uuid> --description "..." --recipes compoundWords,metaphor --count 12 --idempotency-key my-product-run-1
# Persist candidates proposed by the active agent or an authorized offline process (1-50 items)
identityforge naming add-candidates --project <uuid> --file candidates.json
# The same command accepts a JSON array or {"candidates":[...]} on stdin
identityforge naming add-candidates --project <uuid> --file - < candidates.json
identityforge naming candidates --project <uuid> --status shortlisted,finalist
identityforge naming generations --project <uuid>
identityforge naming research-context --project <uuid>
identityforge naming search --file research-tasks.json
identityforge naming acquisition candidate.com --intent either
identityforge naming move <candidate-uuid> --project <uuid> --status finalist --notes "Strong market fit"
identityforge naming rank <candidate-uuid>=1 <candidate-uuid>=2 --project <uuid>
identityforge naming domains candidate.de candidate.com --serp --market "Germany heating retail" --language de-DE
# Registrar evidence alongside DNS and RDAP, the closest this gets to an availability answer
identityforge naming domains candidate.de --registrar
# Record WHY a candidate moved, not only that it did
identityforge naming move <candidate-uuid> --project <uuid> --status rejected --evidence why.json

命名情報の書き込みを保護する。 naming move と naming rank は --expected-updated-at を受け取ります。読み取り後に候補が変更されていた場合、黙って上書きするのではなく 409 を返します。naming candidates からマーカーを取得し、1 バイトも変えずに渡してください。マーカーは解析しないでください。タイムスタンプのように見えますが、不透明な文字列として比較されます。

identityforge naming candidates --project <uuid> --status finalist   # read updatedAt from the row
identityforge naming move <candidate-uuid> --project <uuid> --status selected \
  --expected-updated-at "<marker>"

このマーカーが保護する候補は1 件だけです。そのため、複数の ID とともに渡すと、すべてに適用されるのではなく、送信前に拒否されます。各行にはそれぞれ独自のマーカーがあり、1 つのマーカーをバッチ全体に適用すると、保護する行を間違えるためです。保護対象の候補は個別に移動してください。これは、プロジェクトで選択したブランド名も設定する --status selected で特に重要です。

--evidence は異なります。行ごとの指定ではないため、バッチ内のすべての候補に適用されます。パスまたは標準入力を表す - を指定します。解析できないファイルは、空のオブジェクトとして送信されません。空のオブジェクトを送ると、検討した結果であるかのように「証拠なし」と記録されるためです。

同時編集を上書きせずに保存済みキットを編集する

PATCH は expectedUpdatedAt マーカーを受け付け、読み取り後に変更されたキットを上書きする代わりに 409 を返します。現在のマーカーは themes get --marker で読み取ります。

MARKER=$(identityforge themes get my-kit --marker)
identityforge themes get my-kit --format json > kit.json
# ... edit kit.json, then guard the write with the marker you read
identityforge themes update my-kit --kit kit.json --expected-updated-at "$MARKER"

--kit は保存済みキットに対してディープマージされるため、変更内容だけを含むファイルで十分です。slug はそのままにしてください。これはキットの公開用ハンドルであり、異なる値を含むペイロードは無視されるのではなく、400 slug_rename_unsupported で拒否されます。--expected-updated-at を省略しても引き続き動作し、書き込みも行われます。ただし、読み取り後に誰かが加えた編集を含め、保存されている内容をすべて上書きするため、その旨が stderr に表示されます。

マーカーは不透明な値です。そのままのバイト列で返し、解析しないでください。 ISO-8601 ではなく、生の Postgres タイムスタンプとしてワイヤーを通過し、ガードは文字列を比較します。そのため、マーカーを Date に解析してシリアライズし直すクライアントは一致せず、常に 409 が返されます。また、解析するとマイクロ秒が失われるため、両方の値を正規化して比較すると、本当に古い書き込みが誤って一致し、通ってしまう可能性があります。キュレーション済みカタログのキットには行がなく編集できないため、マーカーもありません。

認証

コマンドの認証には Identity Forge API キー（ifk_…）を使用します。login はキーをモード 600 で ~/.identityforge/config.json に保存します。シェルごとに設定することもできます。

export IDENTITYFORGE_API_KEY=ifk_…
export IDENTITYFORGE_API_URL=https://identityforge.io   # override the API base
export IDENTITYFORGE_TELEMETRY=0                        # optional: disable apply-completion counting

無料キットの利用と命名レシピの検索にはキーは不要です。認証済みのクォータ内で、永続的なプロジェクトや保存済みの作業を維持するにはサインインしてください。所有する命名プロジェクトとドメイン調査には naming:read、生成とボードの編集には naming:write、デザインシステムの読み取りには kits:read、キットの作成やリミックス、および共有可能なブランドプロジェクトの構築には kits:write が必要です。API 呼び出しは、すべてのキーで共有されるアカウント全体の月間 API クォータにカウントされます。一方、生成では、正常に保存された一意の候補に対して AI クレジットが別途消費されます。キーの管理は https://identityforge.io/account/api-keys で行えます。

ローカルでの適用が成功すると、クライアントは集計ビルドを記録するため、メタデータのみを含む完了リクエストを 1 回送信します。このリクエストには、キット識別子と、すべての API リクエストにすでに含まれているクライアント名およびバージョンが含まれます。リポジトリのパスやファイル内容が送信されることはなく、適用結果が変更されることもありません。IDENTITYFORGE_TELEMETRY=0 で無効にできます。

既存のデザイン専用キーが暗黙的にアップグレードされることはありません。キーに naming:read または naming:write が不足しているというエラーが表示された場合は、スコープ付きのキーを作成するか、ブラウザーで再度ログインしてください。

Docker

MCP サーバーは、標準入出力を使用するコンテナーとしても実行できます。

docker build -t identityforge-mcp .
docker run -i --rm -e IDENTITYFORGE_API_KEY=ifk_… identityforge-mcp

イメージにはキットのペイロードは含まれていません。キーは任意です。キーがなくてもサーバーは起動し、Identity Forge プラットフォーム API から公開済みの無料キットを取得します。Pro キット、保存済みの作業、書き込みにはアカウントキーが必要です。

リンク

• ソースとエージェントプラグイン：公開 CLI および MCP の実装です。
• キットギャラリー：ライブプレビュー、作成者が意図したユースケースによるフィルター、検索機能を使って、すべてのキットを閲覧できます。
• エージェント向け情報：エージェントとの統合についての詳細です。
• API マニフェスト および llms.txt。
• 公式 MCP レジストリの登録情報 および 独立したビルド・セキュリティ分析付きの Glama 掲載情報。

Identity Forge がワークフローに役立つと感じたら、GitHub でスターを付けていただくと、ほかのビルダーにも見つけてもらいやすくなります。

ライセンス

MIT