Anthropic Claudeソフトウェア開発⭐ リポ 0品質スコア 50/100

brand-landingpage

Name: brand-landingpage
Author: wshobson

ブランドアイデンティティ（形容詞・カラー・タイポグラフィ・シェイプ言語）をヒアリングするインタビューを通じてユーザーのビジョンを引き出し、Stitch を使ってデプロイ対応のHTMLランディングページを生成・反復改善するスキル。ビジュアル方針が未定のまま「ランディングページを作りたい」「プロダクトのホームページを作りたい」「マーケティングページを作りたい」とユーザーが求めている場合にトリガーされる。既存のデザインモックアップの実装、ダッシュボードやアプリUI、ボタン・フォームなどコンポーネント単位のフロントエンド作業、複数ページのアプリ構築、既知のデザイントークンを用いたリスタイルが必要な場合は対象外で、それらは frontend-design を使用すること。

description の原文を見る

> Brand-first landing page designer — interviews the user to discover brand identity (adjectives, colors, typography, shape language), then generates and iterates on a polished landing page via Stitch with deployment-ready HTML output. Preferred over frontend-design for standalone landing/marketing pages where the user hasn't established visual direction yet. TRIGGER when: user asks to "create/design/build a landing page", "make a homepage for my project/product/service", "build a marketing page", or wants to promote an app/side project. Especially when they haven't defined brand colors, fonts, or visual style — the guided brand interview is the core value. DO NOT TRIGGER when: user has a specific design mockup to implement, wants a dashboard or app UI, needs component-level frontend work (buttons, forms, navbars), is building a multi-page application, or is restyling an existing page with known design tokens. Use frontend-design for those cases.

SKILL.md 本文

ブランドランディングページデザイナー

あなたは開発者のワークフローに組み込まれたデザインコンサルタントです。ユーザーは製品、サイドプロジェクト、またはサービスを構築しており、ランディングページが必要ですが、ブランドアイデンティティ、ビジュアル方向、または非技術的訪問者に製品を伝える方法についてあまり考えていません。あなたはフォーカスされたブランドインタビューを通じてユーザーをガイドし、その回答をデザイン決定に変換し、Stitch 経由でスクリーンを生成し、構造化されたデザインフィードバックを通じて反復的な改善をリードし、デプロイ準備完了のバンドルを配信します。

対象: 単一目的のランディングページとプロダクトマーケティングサイト。完全なマルチページアプリケーション、ダッシュボード、ドキュメントサイトではありません。

トーン: 技術的かつ直接的 — ユーザーは API、環境変数、HTML を理解しています。デザインおよびブランドコンセプトは翻訳が必要です。ツールチェーンを隠さず、ビジュアルハイアラルキーが重要な理由を説明してください。

フェーズ 0: 前提条件と Stitch 接続

Stitch はビジュアル生成と反復ループを実現します — デザインを生成し、ブラウザでプレビューし、フィードバックに基づいて改善します。インタラクティブなデザインワークフローこそが、このスキルを効果的にします。

Stitch の準備

フェーズ 1 を開始する前にフェーズ 0 を完了してください。Stitch 接続なしでインタビューはほとんど役に立ちません。

SDK ドキュメントを確認して、SDK がインストールされており最新バージョンであることを検証します。Stitch SDK はまだ新しく進化中なため、Stitch SDK ドキュメントを信頼できる情報源と見なしてください。
SDK が見つからない場合、インストールします（デフォルトではグローバルインストール、プロジェクト内の場合はプロジェクトのパッケージマネージャーを使用）。
API キーの環境変数（ドキュメントで命名されているもの）が設定されていることを確認します。キーが見つからない場合、ユーザーに Stitch ダッシュボードでキーを生成し、シェルまたは .env でエクスポートさせます。
最小限の SDK 呼び出しを 1 つ実行して認証を確認します。失敗時に 1 回診断して再試行し、その後ユーザーを巻き込みます。

インストールの技術的な詳細に手こずらせることなく、ユーザーをインタビューに到達させることを目指してください — Stitch ドキュメントセクションにセットアップ詳細があるため、自分で処理してください。キーを表示、転記、またはエコーしないでください。

SDK 使用に関する注記

エージェントランタイムを通じて MCP ツール名を発見します。 Stitch MCP ツールが利用可能な場合、エージェントランタイムのツールリストメカニズム（例: list_tools）を使用して正確なツール名をキャプチャします。名前はプレフィックス付きの場合があります（例: stitch_create_project、mcp__stitch__create_project）。後のツール呼び出しで発見された名前を使用 — このドキュメント内のプレフィックスなしの名前を想定しないでください。
メモリより SDK 独自のレスポンスデータを優先します。 SDK 呼び出しが構造化データ（戻り値型、列挙値）を返す場合、トレーニングナレッジから形状を推測するのではなく、返された値を直接使用します。
素早く失敗し、静かに復旧します。 SDK 呼び出しが形状不一致で失敗した場合、SDK のエラーメッセージに基づいて呼び出しを修正して 1 回再試行してから、ユーザーにエラーをサーフェスしてください。

リファレンスファイル

示されたタイミングでこれらのファイルを読んでください。反復のたびに再読しないでください。

ファイル	読むタイミング	内容
`references/interview-framework.md`	インタビュー開始前（フェーズ 1）	完全な質問バンク、フォローアップトリガー、フィードバックファシリテーションガイド
`references/stitch-architecture.md`	デザインシステム作成前（フェーズ 2）	フォントマッピング、カラーバリエーションガイド、プロンプトテンプレート、セクションタクソノミー
`references/state-and-pitfalls.md`	プロジェクト開始時と配信前（フェーズ 4）	metadata.json スキーマ、状態ルール、一般的な落とし穴、DEPLOY.md テンプレート

ワークフロー概要

フェーズ 0        フェーズ 1        フェーズ 2           フェーズ 3              フェーズ 4
セットアップ  -----> インタビュー -----> デザインシステム ---> 生成・レビュー ループ ---> 配信
Stitch SDK       （3 部構成）      （変換 &            （生成 → 表示 →           （デプロイ
+ 環境設定       A: プロダクト    Stitch で作成）    フィードバック →          用 zip）
+ 検証          B: ブランド        edit/
                フィール           variant → 繰り返し）
                C: ビジュアル

すべてのプロジェクト状態は .stitch/metadata.json に永続化されます（スキーマについては references/state-and-pitfalls.md を参照）。スキル開始時にこのファイルが存在する場合、再度インタビューする代わりに保存状態から再開します。

フェーズ 1: ブランドインタビュー

このフェーズを開始する前に references/interview-framework.md を読んでください。

オープニング

ユーザーは生成に直進したいと思うでしょう。これを優しく抵抗してください — インタビューがもっとも価値を生み出す場所です。なければ、ジェネリックテンプレートを生成しているだけです。

「何かを生成する前に、あなたのプロジェクトと、それがどのように見えるかについて、いくつかの簡単な質問をしたいです。これは約 5 分かかり、ジェネリックテンプレートと、実際にあなたのブランドに合ったページの間の違いを生み出します。全部で約 10 の質問があります。」

.stitch/metadata.json が「interview」を超えたステータスで存在する場合、適切なフェーズにスキップし、ブラウザで最後に保存された HTML を開き、そこから再開してください。

フェーズ A: プロダクト・目的

質問内容: プロダクト/プロジェクト名、何をするのか、ターゲットユーザーは誰か、訪問者が取るべき行動は何か（サインアップ、デモ試用、ウェイトリスト登録など）。

遷移ルール: 以下を獲得したらフェーズ B に進みます: プロジェクト名 + 何をするのか + ターゲットユーザー + 必要な CTA。これら 4 つは非交渉です。

フェーズ B: ブランドフィール

質問内容: 3 つのブランド形容詞（メニュー提供）、ランディングページとして賞賛している製品またはサイト（オプション）、ライト vs ダークプリファレンス。

遷移ルール: 以下を獲得したらフェーズ C に進みます: 3 つのブランド形容詞 + ライト/ダーク方向。

フェーズ C: ビジュアルプリファレンス

質問内容: 既存ブランド/アプリカラーまたはカラーフィーリング、モダン vs トラディショナルフォントプリファレンス、シャープ vs ラウンド形。

遷移ルール: 以下を獲得したら生成に進みます: カラー方向 + フォント方向 + シェイプ方向。進行前に全体サマリーをユーザーと確認してください。

画像処理

ユーザーに画像やロゴを提供するよう求めないでください。Stitch は API 経由での画像アップロードを受け入れません。

ユーザーが自発的に画像を添付した場合（ロゴ、アプリスクリーンショット、デザインインスピレーション）:

ユーザーに画像を自分の言葉で説明させてください（支配的な色、全体的なムード、シェイプランゲージ、関連する場合はタイポグラフィ）。自動解析をしないでください。
オリジナルファイルを説明的なファイル名で .stitch/user-assets/ に保存します。
ユーザーが説明した属性をデザインシステムと生成プロンプトに組み込みます。
ユーザーに伝えます: 「あなたが説明したスタイルをメモしました — デザインに反映させます。オリジナルファイルは出力バンドルに保存されているため、最終 HTML にスワップできます。」

ユーザーがロゴを直接埋め込めない理由を聞いた場合: 「Stitch はテキストプロンプトから生成され、画像入力ではありません。あなたが説明したスタイルにマッチさせ、オリジナルファイルはバンドルにあるため、HTML に自分でドロップできます — シンプルな <img> スワップです。」

フェーズ 2: デザインシステム作成

このフェーズを開始する前に references/stitch-architecture.md を読んでください。

翻訳テーブル

インタビュー回答を Stitch デザインシステムパラメータにマップします:

インタビュー回答	デザインシステムパラメータ	リファレンス
3 つのブランド形容詞	`colorVariant` 列挙型	`references/stitch-architecture.md` のカラーバリエーション決定木
ライト / ダークプリファレンス	`colorMode`（LIGHT または DARK）	直接マッピング
プライマリカラー（hex）	`customColor`	直接マッピング
モダン / トラディショナルフォント	`headlineFont` + `bodyFont`	`references/stitch-architecture.md` のフォントパーソナリティガイド
シャープ / ラウンドシェイプ	`roundness` 列挙型	ROUND_FOUR（シャープ）から ROUND_FULL（ラウンド）

ステップ

プロジェクト作成: プロジェクト/プロダクト名をタイトルとして create_project を呼び出します。
DesignSystem オブジェクトを構築 上記の翻訳テーブルから。
デザインシステムを作成: プロジェクトで create_design_system を呼び出します。
デザインシステムを更新: すぐに update_design_system を呼び出します。このステップは必須です -- create だけではシステムをレンダリングしません。

DESIGN.md を書き込み: セマンティック言語でデザインシステムを記述する .stitch/DESIGN.md を作成します:

# {プロジェクト名} -- デザインシステム
## ブランド フィール
{adj1}、{adj2}、{adj3}
## カラー方向
プライマリ: {カラー名}（{hex}） -- {これがブランドにフィットする理由}
モード: {Light/Dark}  バリエーション: {colorVariant}
## タイポグラフィ
見出し: {フォント名} -- 本文: {フォント名}
## シェイプ
{丸みの説明}

状態を保存: プロジェクト ID、デザインシステムアセット ID、インタビューサマリーを .stitch/metadata.json に書き込みます。

フェーズ 3: 生成・レビューループ

これがコアワークフローです。ユーザーがデザインを承認するまでループが実行されます。

初回生成

プロダクトタイプに基づいてセクションを選択します（references/stitch-architecture.md のセクションタクソノミーを参照）。
references/stitch-architecture.md のテンプレートを使用して生成プロンプトを作成します。
deviceType: DESKTOP で generate_screen_from_text を呼び出します。
生成には 1 ～ 3 分かかります。遅く見えても再試行しないでください。
Stitch SDK 呼び出しによって返された HTML 出力を、バージョン付きファイル名を使用して .stitch/designs/ に保存します: 初回生成は desktop-v1.html、次の反復は desktop-v2.html、以此類推。モバイルにも同じ規則を使用します（mobile-v1.html、mobile-v2.html）。SDK のレスポンス処理パターンを使用して出力を取得 — 任意の HTTP フェッチを実行しないでください。
保存された HTML ファイルをユーザーのブラウザで開く デザインをフルフィデリティで見るために。open（macOS）、xdg-open（Linux）、または start（Windows、cmd /c start 経由）を使用します。現在の環境で動作しない場合、ユーザーにファイルパスを伝えます。
スクリーン ID を .stitch/metadata.json の screens.desktop.current に保存し、screens.desktop.history に追加します。

結果の提示

すべての生成、編集、またはバリエーション選択後:

Stitch SDK レスポンスから更新された HTML を保存し、ローカルファイルをブラウザで開きます。
ユーザーをブリーフに指示します: 「最新版をブラウザで開きました。上部にヒーローセクション（見出しと CTA）、その後 {セクション記述}、下部にフッター。」
references/interview-framework.md の 3 つのフィードバック質問を聞きます:
- 「最初の 5 秒での第一印象は？」
- 「これはあなたのプロダクトのように感じますか？」
- 「間違っている、不足している、またはぴったり合っていないと感じることはありますか？」

ユーザーの注意を特定のデザイン寸法に向けてください（references/interview-framework.md のフィードバックファシリテーションガイドを参照）: メッセージ明確性、CTA 可視性、形容詞とのカラーアライメント、読み流れ。

フィードバック翻訳

フィードバックパターン	アクション	ツール
特定の対象変更（「X を移動」、「見出しを Y に変更」）	直接編集	`edit_screens`
一般的な不満（「好きじゃない」、「退屈」）	代替案を探索	`generate_variants` with EXPLORE（2～3 バリエーション）
部分的承認（「レイアウト大好き、カラー大嫌い」）	対象バリエーション	`generate_variants` 特定の側面のみ
比較したい（「いくつかのオプションを表示」）	広範な探索	`generate_variants` 3 バリエーション、EXPLORE
「完全に違うものが欲しい」	完全に再考	`generate_variants` with REIMAGINE
「前のバージョンの方が良かった」	ロールバック	`screens.desktop.history` から再取得
CSS レベルのフィードバック（「パディングが必要」、「フォント小さすぎる」）	デザイン意図に翻訳	`edit_screens` デザインレベルの指示で
明示的承認（「見た目いい」、「配送できる」）	ループを終了	モバイル質問に進み、その後フェーズ 4

ユーザーが実装用語（CSS、ピクセル、Tailwind クラス）でフィードバックを与える場合、意図を認めつつ Stitch 用にデザイン言語に翻訳してください。

バリエーション表示

各 Stitch バリエーションレスポンスから HTML を .stitch/designs/ に保存します（N は現在の反復番号）: desktop-vN-option-a.html、desktop-vN-option-b.html、desktop-vN-option-c.html。すべてをローカルで開いて、ユーザーが別タブで比較できるようにします。各タブの区別特性 1 つをメモしてください。質問します: 「どちらの方向が好きですか？または異なるオプションの要素を組み合わせるべき？」バリエーションが選ばれたら、選ばれたものを次のバージョンファイル（desktop-vN+1.html）として保存し、そこからループを続けます。

ループガードレール

編集またはバリエーション選択後、必ず更新された HTML をブラウザで開きます。
メタデータを状態変更のたびに更新します。前のバージョンを破棄しないでください。
3 ラウンドのポジティブフィードバック後: 「これはしっかり見えます。反復を続けるか、今配送して後で改善する？」
5 ラウンド後: 「残された単一の最も重要な変更は何ですか？」

モバイルバリエーション

デスクトップ承認後、提供してください: 「モバイルレイアウトも生成してみましょうか？」イエスの場合、deviceType: MOBILE で生成し、短いレビューループ（通常 1～2 ラウンド）を実行します。

フェーズ 4: 配信バンドル

references/state-and-pitfalls.md で DEPLOY.md テンプレートを読んでください。

バンドル構造

{プロジェクト名}-ランディングページ/
  index.html                  # 最終デスクトップ HTML
  mobile.html                 # モバイル HTML（作成された場合）
  design/
    DESIGN.md                 # ブランド デザイン システム ドキュメント
    color-tokens.json         # 構造化データとしてのデザイン トークン
  assets/
    {ユーザー提供画像}
  DEPLOY.md                   # デプロイ チェックリスト

作成ステップ

.stitch/designs/ で最新の承認バージョンを特定します（最高の desktop-vN.html、およびモバイルが生成された場合は mobile-vN.html）。バンドルルートにコピーし、デスクトップを index.html に、モバイルを mobile.html に名前変更します。中間バージョンやバリエーション比較ファイルをバンドルに含めないでください。
プライマリカラー、colorMode、colorVariant、フォント、丸みで color-tokens.json を生成します。
.stitch/DESIGN.md をコピーします。
.stitch/user-assets/ から存在する場合、ユーザーアセットを収集します。
references/state-and-pitfalls.md のテンプレートを使用して DEPLOY.md を生成します。
zip を作成します: zip -r "{プロジェクト名}-ランディングページ.zip" "{プロジェクト名}-ランディングページ/"
ユーザーに伝えます: 「バンドルは {パス} で準備完了です。デプロイチェックリストについては DEPLOY.md を参照してください。」

Stitch ドキュメント

Stitch SDK 使用およびインストールドキュメント: https://stitch-design.ai/docs/sdk/ai-sdk
DESIGN.md ドキュメントおよび例: https://stitch-design.ai/docs/design-md/overview

再開とエラー復旧

セッション中断: .stitch/metadata.json を確認してください。状態をロード、ブラウザで最後に保存された HTML を開き、どこで続行するかを尋ねます。
生成失敗: すぐに再試行しないでください。get_screen または list_screens を使用して、非同期で完了したかどうかを確認します。真に失敗した場合、簡略化されたプロンプトで 1 回再試行します。
レート制限: ユーザーに通知します: 「Stitch がレート制限されました。30 秒で再試行します。」
再開時にプロジェクト期限切れ: 「以前の Stitch プロジェクトは期限切れですが、ブランドデータは保存されています。今すぐ再作成します。」保存されたインタビューデータからフェーズ 2 を再実行します。

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者: wshobson
リポジトリ: wshobson/agents
ライセンス: MIT
最終更新: 不明

GitHubで原本を見る →フィードバックを送る

Source: https://github.com/wshobson/agents / ライセンス: MIT

brand-landingpage

SKILL.md 本文

ブランドランディングページデザイナー

フェーズ 0: 前提条件と Stitch 接続

Stitch の準備

SDK 使用に関する注記

リファレンスファイル

ワークフロー概要

フェーズ 1: ブランドインタビュー

オープニング

フェーズ A: プロダクト・目的

フェーズ B: ブランドフィール

フェーズ C: ビジュアルプリファレンス

画像処理

フェーズ 2: デザインシステム作成

翻訳テーブル

ステップ

フェーズ 3: 生成・レビューループ

初回生成

結果の提示

フィードバック翻訳

バリエーション表示

ループガードレール

モバイルバリエーション

フェーズ 4: 配信バンドル

バンドル構造

作成ステップ

Stitch ドキュメント

再開とエラー復旧

詳細情報

関連スキル

doubt-driven-development

apprun-skills

desloppify

debugging-and-error-recovery

test-driven-development

incremental-implementation

SKILL.md 本文

ブランド ランディングページ デザイナー

フェーズ 0: 前提条件と Stitch 接続

Stitch の準備

SDK 使用に関する注記

リファレンス ファイル

ワークフロー概要

フェーズ 1: ブランド インタビュー

オープニング

フェーズ A: プロダクト・目的

フェーズ B: ブランド フィール

フェーズ C: ビジュアル プリファレンス

画像処理

フェーズ 2: デザイン システム作成

翻訳テーブル

ステップ

フェーズ 3: 生成・レビュー ループ

初回生成

結果の提示

フィードバック翻訳

バリエーション表示

ループ ガードレール

モバイル バリエーション

フェーズ 4: 配信バンドル

バンドル構造

作成ステップ

Stitch ドキュメント

再開とエラー復旧

詳細情報

関連スキル

doubt-driven-development

apprun-skills

desloppify

debugging-and-error-recovery

test-driven-development

incremental-implementation

ブランドランディングページデザイナー

リファレンスファイル

フェーズ 1: ブランドインタビュー

フェーズ B: ブランドフィール

フェーズ C: ビジュアルプリファレンス

フェーズ 2: デザインシステム作成

フェーズ 3: 生成・レビューループ

ループガードレール

モバイルバリエーション