README スクリーンショット
稼働中のプロジェクトを、ドキュメント化された視覚的なものに変えます：アプリを実行し、実際のスクリーンショットをキャプチャし、それらを基に活気のあるクリーンな README.md を構成します。結果は、よく手入れされたオープンソースプロジェクトのランディングページのように読めるべきです。
プラットフォームに関わらず、絶対に守るべきこと：
- スクリーンショットは、実際に動作しているアプリの本物のキャプチャです。画像を描いたり、モックアップしたり、偽造したりしてはいけません。
- 画像はリポジトリ内 (
docs/screenshots/) に配置し、README はそれらを相対パスで参照するため、GitHub 上で正しく表示されます。 - 破壊的な操作は一切行いません：スクリーンショットを撮るためにプロジェクトのソースコードを変更することは決してせず、必要な場合はランタイムでデモ状態を注入し、その旨を明記します。
ワークフロー
フェーズ 1 — プラットフォームの検出
プロジェクトルートで以下のシグナルを探し、対応する references/ 内の実行手順書を読み込みます：
| シグナル | → 実行手順書 |
|---|---|
package.json に dev/start スクリプト、または index.html、または src/public フォルダ内の純粋なWebフロントエンド | references/web.md |
manifest.json (WebExtension/MV3/V2) | references/web.md (拡張機能セクション) |
Android: build.gradle(.kts), AndroidManifest.xml, settings.gradle, Kotlin/Java アプリソース | references/android.md |
iOS: *.xcodeproj, *.xcworkspace, Info.plist, Swift のアプリコード | references/ios.md |
Flutter: pubspec.yaml に flutter: と lib/main.dart | references/flutter.md |
| 複数プラットフォーム (例: Flutter + ネイティブ、モノレポ) | 最初にフラッグシップUIのプラットフォームをドキュメント化し、他のプラットフォームはREADME内で言及する |
プラットフォームが真に曖昧な場合は、リポジトリの最も適切な解釈を提示して一度だけユーザーに確認します。プロジェクトにユーザーから見えるインターフェースが全くない場合（純粋なライブラリ/CLI）、UIのスクリーンショットを偽装せず、ターミナルデモ、洗練された図、または生成されたバナーにフォールバックし、それでも優れたREADMEを生成します。
フェーズ 2 — 実行手順書に従ってアプリを実行
各実行手順書には以下の内容が記載されています：
- このマシンに既に存在しなければならないもの（ツールチェーンチェック、繰り返し可能なワンライナーコマンド）。
- アプリのUIがレンダリングされるように起動する方法。
- 実際にピクセルをキャプチャする方法（
scripts/内のバンドルスクリプト、またはネイティブのキャプチャコマンド）。 - 何かが空白になった場合の復旧方法（「レンダリングを待つ」は「盲目的にリトライ」より優れています）。
フェーズ 3 — キャプチャ
すべてのプラットフォームに適用される規則：
- 保存先は
<repo>/docs/screenshots/とし、ケバブケースの名前でその瞬間を説明します（hero-dashboard.png,settings-screen.png）。ツール名（screenshot-2026-01-04-14-22.png）は使用しません。 - 各画面は自然な形状でキャプチャします：ダイアログ/ポップアップはネイティブサイズ、ページは1280×800または全ページ。スマートフォンの場合は、デバイス画面をそのままキャプチャします（解像度自体がストーリーの一部です）。
- アプリがダークテーマを持っている場合は、ヒーローショットにはダークモードを優先します（ダークUIはREADMEで映えます）。ただし、実際のダークテーマがある場合に限り、無理に適用しないでください。
- ステージングされたデモ状態は許可されます（空のカウンター、「Loading…」プレースホルダーはマーケティングショットでは壊れて見えます）。ただし、ランタイムで注入する必要があり、プロジェクトコードに書き込んではいけません。また、サマリーでユーザーにその旨を開示しなければなりません。
- 空白やちらつきフレームはタイミングの問題であり、アプリのせいではありません：読み込みが完了するのを待ち、さらにフォント/アイコン/トランジションのための一拍を置き、より長い待機時間で一度リトライします。
フェーズ 4 — README の構成
リポジトリルートに README.md を書き込み（または書き換え）ます。既に豊富なREADMEコンテンツが存在する場合（git-readme.md、散文ファイル、ドキュメント）、その事実をすべて活用します。プレゼンテーションをアップグレードするのであり、情報を削除するのではありません。
ターゲット構造（自由に適応し、スキャンしやすく保ちます）：
# <プロジェクト名>
<p align="center"><img src="docs/screenshots/hero.png" width="…"></p>
> 個性のある一行ピッチ。
バッジ: ライセンス、言語、インストールリンク
## 存在理由 ← 問題点、2～4行、実際の数字があれば太字
## 機能 ← ✨ タイトな機能リスト（機能の横にスクリーンショットを配置）
## スクリーンショットツアー ← 一行キャプション付きギャラリー
## 仕組み ← 平易な言葉でのアーキテクチャ。箇条書きよりテーブル
## インストール ← 番号付き、コピペ可能
## 設定 ← アプリに設定がある場合はパラメータテーブル
## プライバシー/安全性 ← 意味がある場合のみ
## ライセンス
スタイルのルール：
- ヒーローショットはファーストビューに配置し、明示的な幅（スマホショットは
width="400"、デスクトップは約728px未満）を指定して、GitHub上で適切にレイアウトされるようにします。 - セクションごとに一つのアイデア。短い段落。スキャン補助のためだけに太字を使用。
- 互換性マトリックスや設定にはテーブルを使用 — 散文よりも優れています。
- ヘッダーへの控えめでセンスの良い絵文字（⏱ 🎨 🚀）は許容されますが、すべての行に振りかけるのは避けます。
- 画像は常に相対パスとaltテキストを使用します。
- README内でスクリーンショット撮影プロセスについて説明しないでください。プロジェクト自体が書いたかのように読めるようにします。
フェーズ 5 — 検証
- README内のすべての画像パスが、存在するファイルに解決されること。
- スクリーンショットが約1.5MBを超えないこと。大きい場合は圧縮（PNG→WebPまたはダウンスケール）します。
- ユーザーに以下の情報を伝えます：READMEの場所、作成されたスクリーンショットの一覧、デモが注入された値を持つスクリーンショットがあるかどうか。また、ヒーロー画像の選択、テーマ、順序の差し替えを提案します。
ツールチェーンポリシー（依存関係不足の処理）
このスキルは、マシン上に既に存在するツールチェーンのみを使用し、プラットフォームSDK（Android SDK、Xcode、Androidエミュレーター — ユーザーの同意が必要な数GBのダウンロード）をサイレントにインストールすることは決してありません。実行手順書のツールチェーンチェックが失敗した場合は、以下の形式でクリーンに停止します：
[プラットフォーム] のスクリーンショットには [ツール] が必要ですが、インストールされていません。有効にするには：
<正確なインストールコマンドまたは手順>。インストール後、「リトライ」と言っていただければ、続行します — これまでに行った作業（検出、READMEの骨組み）は保存されています。
iOSは特別なケースです：ホストがmacOSでない場合は、一文でその旨を伝えてスキップします — Windows/Linuxではリトライでも有効にできません。ユーザーが自分でキャプチャしたスクリーンショットを提供できるオプションを提案します。