publish-research-site

リサーチサイトの公開

概要

このスキルを使って、綿密なリサーチ、ビットマップ画像素材の生成、本番環境向けのインタラクティブなウェブサイトの作成、Vercel CLI によるデプロイという4段階のパイプラインを統括します。最終成果物は、公開して共有できるマイクロサイトとして扱います。引用に耐えるほど信頼性が高く、広く共有されるだけの視覚的な魅力があり、モバイルでもすばやく開けるサイトを目指します。

ワークフロー

0. 事前に依存関係を確認する

リサーチや実装を始める前に、必要なスキルと CLI が利用可能か確認します。コマンドがデフォルトの PATH にない場合は、ユーザーの Codex ローカルのツールチェーンのパスを優先してください。

export PATH="$HOME/.agent-reach-venv/bin:$HOME/.codex/toolchains/node-current/bin:$HOME/.codex/toolchains/gh-current/bin:$PATH"

for cmd in node npm npx vercel agent-reach mcporter yt-dlp gh; do
  command -v "$cmd" >/dev/null || {
    echo "Missing required dependency: $cmd"
    exit 1
  }
done

agent-reach doctor

環境にローカルのスキルフォルダーがある場合は、スキルファイルも存在することを確認します。

test -f "$HOME/.agents/skills/deep-research/SKILL.md" || echo "Missing skill: deep-research"
test -f "$HOME/.agents/skills/agent-reach/SKILL.md" || echo "Missing skill: agent-reach"
test -f "$HOME/.agents/skills/frontend-design/SKILL.md" || echo "Missing skill: frontend-design"
test -f "$HOME/.codex/skills/.system/imagegen/SKILL.md" || echo "Missing skill: imagegen"

必須の依存関係が不足している場合は、プロジェクトを開始する前に作業を中止し、不足している前提条件をインストールするようユーザーに依頼するか、インストールの許可を求めます。サイトの完成後にデプロイツールの不足が判明することのないようにしてください。

1. 命題の範囲を定める

ユーザーの主張やトピックを、作業用の概要としてまとめ直します。

• 中心となる命題または問い
• 想定読者と希望するトーン
• サイトを通じて、読者に何を信じ、理解、比較、探索してもらうべきか
• 必要な言語、地域、期間、デプロイ先の希望

意図が明確な場合は、自律的に進めます。命題、読者、デプロイ先が曖昧すぎて安全に対応できない場合に限り、質問してください。

2. 綿密なリサーチを行う

既存の $deep-research スキルが利用できる場合は、これを呼び出します。デフォルトでは標準モードを使用します。サイトが重要な意思決定、議論を呼ぶ主張、投資判断、技術アーキテクチャの評価、一般公開向けの事実報告を支える場合は、ディープまたはウルトラディープモードを使用します。

リサーチの成果物には、以下を含めてください。

• 信頼度を示したエグゼクティブ・テーゼ
• 引用 ID を付けた主要な主張
• 矛盾、反論、不確実性
• URL、該当する場合は公開日、信頼性に関する注記を記載した出典リスト
• ウェブサイトに掲載すべき重要な事実を5～10件
• 根拠に基づく視覚表現のアイデアを3～5件

主張を裏付けるだけの十分な根拠が集まるまで、サイトを構築しないでください。時事的なトピックでは、最新の出典で事実を確認し、日付を明記してください。

3. リサーチをサイト概要にまとめる

コーディングの前に、簡潔なサイト概要を作成します。複数のセクション、多数の主張、またはいくつもの生成素材を扱うプロジェクトでは、references/site-brief-template.md を使用してください。

概要では、以下を定めてください。

• ナラティブの流れ：導入、根拠の提示、対立点・別の見方、総括、行動または要点
• セクションとインタラクション
• 主張と出典の対応表
• ビジュアル素材の一覧と画像プロンプト
• フレームワークの選択とプロジェクトディレクトリー
• 検証とデプロイのチェックリスト

ウェブサイトの文章は簡潔に保ってください。リサーチの内容をそのままレポートとして UI に貼り付けるのではなく、読みやすく、要点を把握しやすい一般向けのコンテンツにまとめます。

4. 画像を生成する

サイトの質を大きく向上させるラスター画像（ヒーローアート、エディトリアルイラスト、製品・シーン画像、解説画像、ポスター、サムネイル、SNS 共有用ビジュアルなど）には、既存の $imagegen スキルを呼び出します。

画像のワークフロー：

• サイトで実際に使用する素材だけを生成します。
• リサーチ概要に基づいて、被写体、構図、スタイル、アスペクト比、避ける要素、テキストを含めないかどうかを指定したプロンプトを作成します。
• ユーザーがタイポグラフィアートを明示的に希望している場合を除き、生成画像に事実に関する主張や小さな文字を含めないでください。
• 出力を確認し、必要に応じて1～2回修正を重ね、使用可能な最終版のみを残します。
• プロジェクトで使用する最終素材をウェブサイトの作業領域に移動またはコピーします。通常は public/assets/ またはフレームワークに相当するフォルダーを使用してください。
• 最終プロンプトと保存先のパスを、サイト概要または最終報告に記録します。

5. インタラクティブなウェブサイトを構築する

利用可能な場合は $frontend-design を呼び出してから、マーケティング用の仮ページではなく、実際に使える体験を実装してください。

実装の基本方針：

• ワークスペースやデプロイの要件に応じて、Vite/React、Next.js、または静的な HTML/CSS/JS のサイトを優先してください。
• 最初のビューポートで、サイトの価値をすぐに伝えてください。
• スクロール連動型のストーリーテリング、タイムライン、比較スライダー、根拠カード、フィルター可能な主張マップ、シナリオ切り替え、チャート操作、注釈付き図、クイズ、計算ツールなど、意味のあるインタラクションを少なくとも 1 つ含めてください。
• 主張を裏付ける引用を、その主張の近くに示してください。
• 確認したい読者向けに、ソースドロワー、注記セクション、または参考資料パネルを用意してください。
• レスポンシブで、高速かつアクセシブルな、視覚的に印象に残るサイトにしてください。
• 生成した画像は、なくても伝達内容が変わらない装飾ではなく、実際のアセットとして使用してください。

汎用的な仮セクション、引用のない主張、ダミーのチャート、ストック画像のようなビジュアル、ユーザーに何も伝えないインタラクションは避けてください。

6. ローカルで検証する

デプロイの前に：

• 必要な場合に限って依存関係をインストールし、既存のパッケージマネージャーのスタイルを維持してください。
• 利用可能な場合は、lint、型チェック、テストを実行してください。
• 本番ビルドを実行してください。
• 必要に応じてローカルサーバーを起動してください。
• デスクトップとモバイルの幅でブラウザー検証を行ってください。
• 生成した画像がプロジェクト内のパスから読み込まれることを確認してください。
• 実用上可能な場合は、外部リンクと引用先にアクセスできることを確認してください。
• 表示上のレイアウトの問題、テキストの重なり、空白のキャンバス、コンソールエラー、壊れたルートを修正してください。

ビルドと表示の検証が実際に行われるまでは、サイトの準備が完了したと主張しないでください。検証できなかった項目があれば、明確に報告してください。

7. Vercel CLI でデプロイする

デプロイには Vercel CLI を使用してください。

推奨する手順：

export PATH="$HOME/.codex/toolchains/node-current/bin:$PATH"
vercel --version
npm run build
vercel --yes

ユーザーが本番環境へのデプロイを依頼した場合、またはタスクで本番デプロイが明確に必要な場合に限り、vercel --prod --yes を使用してください。既存の Vercel プロジェクトやドメインが上書きされる可能性がある場合は、本番デプロイの前に確認してください。

Codex ローカルの Node ツールチェーンを PATH に追加した後もローカルの vercel コマンドを利用できない場合は、npx vercel@latest を使用してください。Vercel の認証情報がない場合は、ユーザーにログインを依頼するか、別のデプロイ方法を確認してください。黙って CLI 以外のデプロイサービスに切り替えないでください。

CLI の出力からデプロイ URL を取得し、ブラウザーでテストしてください。デプロイに成功してもリモート検証に失敗した場合は、URL と失敗の両方を報告してください。

最終回答

引き継ぎに役立つ情報だけを報告してください。

• デプロイ URL
• ローカルのプロジェクトパス
• 調査範囲とソース数
• 生成した画像アセットのパス
• 実行した検証コマンド
• 既知の制限事項または未検証の項目

最終回答は簡潔にし、すぐに開けるリンクまたはファイルパスを含めてください。