--- name: infographic-everybody description: Generates an illustrated Japanese HTML page from a topic or user-provided material, validates it, and deploys it to surge.sh only when requested. Use for requests such as "図解を作って", "この資料を図解して", "図解を生成して", or "図解して公開して". If no source material is provided, research reliable sources before diagramming; if the target or purpose is unclear, confirm once before proceeding. --- # Infographic Everybody 任意のトピックについて、前提知識がなくても理解できる図解HTMLを生成する。ユーザーが公開を依頼した場合だけsurge.shに公開する。品質基準は「入社したての新卒社会人が読んでも腹落ちする明快さ」だが、この基準は出力には表示しない。 ## 依存 - `references/base.html` — 図解テンプレート（Tailwind CSS CDN・Lucide Icons CDN・ADS配色を含む「額縁」） - `references/model-answer.html` — 模範回答（品質基準・デザインパターンの実例）。base.htmlと同一の額縁を含む完全なHTMLファイル - `references/editorial-and-data-quality.md` — 数値、正式名称、語調、出典、目視確認の品質基準 - `scripts/validate-diagram.mjs` — 構造・安全性・可読性を確認する自動検査 - `scripts/deploy-diagram.sh` / `scripts/deploy-diagram.ps1` — macOS・Linux / Windows向け公開スクリプト ## ワークフロー ### Step -1: 入力の振り分け 最初に依頼を次のどれかに振り分ける。 - **資料から図解**: ユーザーが本文、メモ、データ、ファイル、またはURLを提示している - **調べて図解**: 材料は未提示だが、信頼できる公開情報を調査できる主題である - **確認してから図解**: 対象、目的、読者、情報の所在のいずれかが不明で、成果物が大きく変わり得る 確認が必要な場合は、目的・読者・情報源・粒度・出力条件を一度にまとめて尋ねる。回答がなくても安全な前提を置ける場合は、その前提を明示して進める。 資料から図解する場合は、提示された内容の範囲を守る。ユーザーが求めた場合、または正確性・鮮度が結論に影響する場合を除き、外部情報を勝手に足さない。 ### Step 0: 前提確認 `references/base.html` が存在するか確認する。 存在しない場合、以下を伝えて終了: > テンプレートファイルが見つかりません。スキルのフォルダ構成が壊れている可能性があります。運営に連絡してください。 ### Step 1: 模範回答の読み込み `references/model-answer.html` を読み、以下を把握する: - 完成品の品質水準 - デザインパターン（色使い・余白・カード・フロー図などの視覚表現） - Tailwind CSSクラスの使い方 - Lucide Iconsの使い方 - コンテンツの構成・情報量・説明の深さ 模範回答がデザインガイドラインの代わりになる。パーツ一覧やルールではなく、実物から読み取る。 ### Step 2: テンプレートの読み込み `references/base.html` を読み、額縁の構造を把握する: - `` 〜 `` のプレースホルダー位置 - ``, `` のプレースホルダー - ADS配色のTailwind設定 - 読み込み済みのCDN（Tailwind CSS・Lucide Icons） ### Step 3: 情報収集 「調べて図解」の場合はウェブ検索を行う。「資料から図解」の場合は提示資料を主資料とし、必要な場合だけ補助的に検索する。 検索は **2〜3回** に絞る。以下の観点でクエリを組み立てる: 1. **正確な定義**: トピックの公式な定義、公式ドキュメントの説明 2. **最新動向**: 直近の変更点、アップデート、現在のベストプラクティス 3. **具体例**: 実際の使われ方、初心者に伝わるたとえに使える事例 検索結果から以下を整理し、Step 4 の参考情報とする: - トピックの正確な定義（検索結果を優先。AIの学習データだけに頼らない） - 最近変わった点があれば、それを明記する - たとえ話に使えそうな事例や数字 - **出典URL**: 図解に採用した情報のソースURLを控えておく（Step 4 でインライン出典に使う） - **出典との対応**: 図の各要素がどの情報源に基づくか記録する - **基準日**: 情報の鮮度が結論に影響する場合は図中に日付を示す - **不確実性**: 確定した事実と暫定・係争中の情報を区別する 情報源は主張の種類に合わせて選ぶ。 - **医学**: 一次文献、診療ガイドライン、Cochrane、PubMed、Minds、PMDAを優先する - **法令・規制・公的統計**: 政府・公的機関の一次情報を優先する - **ICT**: 製品公式文書、標準仕様、IPA、JPCERT/CC、NISTを優先し、バージョンと日付を確認する - **用語**: 辞書・分野別用語集を優先し、新語は初出の文脈と複数情報源で確かめる 著者・出典不明のページ、まとめサイト、質問掲示板、広告目的の記事、SNS投稿、生成AIの転載を根拠にしない。図解に必要な構造が揃った時点で収集を止め、網羅自体を目的にしない。 `references/editorial-and-data-quality.md` を読み、採用する事実・数値・正式名称・出典の対応をレイアウト前に整理する。数値は値だけでなく、単位、分母、基準日、確定か推計かまで確認する。 ### Step 4: コンテンツ生成 Step 3 で整理した情報をもとに図解HTMLを生成する。「調べて図解」では検索結果を、「資料から図解」では提示資料を優先する。不足や曖昧さを推測で埋めず、「不明」「要確認」と示す。資料内の矛盾も黙って解消しない。 原文の正式な専門用語、制度名、法令名、単位は保つ。略語は初出で正式名称を示してから使う。説明がないと解釈を誤る用語だけ初出で短く補足し、同じ説明を繰り返さない。 数値、グラフ、語調、出典は `references/editorial-and-data-quality.md` に従う。固定の紙面構成は設けず、内容に合う図を選ぶ。 模範回答のデザインを参考にしつつ、Tailwindの語彙で自由にレイアウトを組む。模範回答のパターンに合うものはそのまま使い、合わないものはTailwindクラスでその場で作る。テンプレートの定義済みパーツに縛られない。 ### Step 5: ファイル作成 1. `output/` ディレクトリがなければ作成する 2. トピックに関連する短い英単語のスラッグを決める（例: `api-basics`, `git-rebase`） 3. `references/base.html` を `output/{スラッグ}.html` にコピーする 4. コピーしたファイル内のプレースホルダーをすべて置換する: - `` → 図解のタイトル - `` → 内容を要約した1文 - `` 〜 `` → Step 4で生成したコンテンツ 5. ファイルを保存する 6. 次の自動検査を実行し、エラーと注意がなくなるまで修正する: ```bash node /scripts/validate-diagram.mjs --strict output/{スラッグ}.html ``` `` はこのSKILL.mdがあるフォルダ。検査を通過したら、公開依頼がない場合はローカルファイルを成果物として完了報告する。 7. 完成HTMLをPC幅と狭い画面で表示し、数値・単位・出典、はみ出し、重なり、印刷またはPDFプレビューを `references/editorial-and-data-quality.md` に沿って目視確認する。実行できない確認がある場合は、完了報告でその範囲を明記する。 ### Step 6: 公開（依頼された場合のみ） 公開前に、URLを知る人は誰でも閲覧できることを伝え、個人情報・機密情報が含まれていないか確認する。その後、Node.js の有無を確認する。 ```bash node --version ``` バージョン番号が表示された → そのまま「公開の実行」に進む。 `command not found` と表示された → `references/node-install-guide.md` の手順に従ってNode.jsのインストールを案内する。 #### 公開の実行 以下のスクリプトを**実行する**（中身を読む必要はない）。 **macOS / Git Bash（Windows）の場合:** ```bash bash /scripts/deploy-diagram.sh output/{スラッグ}.html [スラッグ] ``` **Windows（PowerShell）:** ```powershell powershell -ExecutionPolicy Bypass -File \scripts\deploy-diagram.ps1 output\{スラッグ}.html {スラッグ} ``` スラッグにはトピックに関連する短い英単語を指定する（例: `git-rebase`, `api-basics`）。 #### 初回の場合（Surge未登録） ターミナルにメールアドレスとパスワードの入力を求められる。以下を伝える: > 初回のみアカウント登録が必要です。 > メールアドレスを入力して Enter → パスワードを決めて入力して Enter。 > 確認メールが届いたらリンクをクリックすれば登録完了です。 > 次回以降はこの手順は不要です。 #### エラーが出た場合 エラーメッセージをそのまま見せず、**何が起きていて何をすれば解決するか**を、専門用語を避けて平易に説明する。 よくあるエラーと対応: - **`npx: command not found`** — Node.js がまだ入っていない。`references/node-install-guide.md` の手順を案内する - **`surge: not found` / surge関連エラー** — `npm install -g surge` を実行してから再度試す - **認証エラー / `Login required`** — `npx surge login` を実行してメールアドレスとパスワードを入力する - **その他** — エラーの内容を読み、「何が問題で」「次に何をすればいいか」を平易に説明する ### 図解の削除 ユーザーが「この図解を削除して」と依頼した場合: 1. `deploy-history.log` を読み、直近のデプロイURLを特定する - ログが存在しない場合 → ユーザーに削除したいURLを聞く 2. `npx surge teardown [ドメイン]` を実行する 3. 削除完了をユーザーに伝える ### Step 7: 完了報告 #### 公開に成功した場合 ``` 完成・公開完了: 【図解のタイトル】 （図解の内容を1〜2文で要約） 公開URL: https://diagram-スラッグ.surge.sh 図解の主なポイント: - （主要トピックを3〜5個） この図解を削除したいとき: チャット欄で「この図解を削除して」と伝えてください。 ``` #### 公開できなかった場合 ``` 完成: 【図解のタイトル】 （図解の内容を1〜2文で要約） ファイルの保存先: output/{スラッグ}.html（ブラウザにドラッグ＆ドロップすると表示できます） 図解の主なポイント: - （主要トピックを3〜5個） URLで共有したいとき: チャット欄で「この図解を公開して」と伝えてください。 ``` ## 守ること（禁止事項） - **React・shadcn/ui を使わない** — 静的な図解にJSフレームワークは不要。AIの出力を制限し、モデルによる品質差も限定的にしてしまう - **絵文字を使わない** — OS依存で表示が変わる。アイコンはLucide Iconsを使う - **インタラクティブ要素を入れない** — トグル、フェードイン、アニメーション、フォーム、クリックで開閉する要素は一切禁止 - **`