Annabellachildlike849/readme-skill

READE スキル

リポジトリの証拠またはユーザーの明示的な確認に基づいて、すべての外部主張を裏付けることで、正確で読みやすい GitHub README ファイルを作成します。まず価値を確立し、素早く使用するためのパスを提供し、読者をより深いドキュメントへと導きます。

絶対に守るルール

• ドラフトはデフォルトで会話内に表示されます。自動的にドラフトファイルを作成しないでください。
• ユーザーが明示的に書き込みまたは更新を指示するまで、README.md、README.zh-CN.md、またはその他の README を作成または変更しないでください。
• ユーザーが保存用のドラフトを希望する場合は、ユーザーが指定した正確なターゲットパスを使用してください。それ以外の場合は、パスを尋ねてください。ドラフトファイル名を独自に作成しないでください。
• コマンド、API、リンク、バッジ、パフォーマンスクレーム、互換性の約束、リリースデータ、コミュニティの場所、ライセンス条項、アーキテクチャコンポーネント、データフロー、またはリポジトリの所有者を決して作り出さないでください。
• README の内容、リポジトリにコミットするコマンド、ソースファイル、または画像 URL に API キーを公開しないでください。例では環境変数のみを参照できます。
• すべての README ドラフトには、利用可能性またはインストールから有用な結果に至るまでの、検証済みの最短パスを示すクイックスタートセクションを含める必要があります。そのパスがリポジトリの証拠またはユーザー確認から検証できない場合は、欠落している初回使用の詳細を尋ねてください。決して作り出したり、空欄にしたり、セクションを省略したりしないでください。
• 最初の発見スキャンで既存の README が見つかった場合は、停止してユーザーに処理モードを選択してもらいます：1) 完全に置き換える — 既存の README の情報をすべて無視します。2) 選択した既存情報で置き換える — ユーザーが承認した正確なコンテンツのみを保持して書き換えます。3) 既存の README を拡張する — 既存の README を保持し、コンテンツを追加または改善します。元のリクエストからモードを推測しないでください。
• 複数の明示的なオプションを含む質問を優先します。決定が合理的に予想できる場合は選択可能なリストを使用し、利用可能なオプションがユーザーの意図をカバーできない場合にのみ自由形式の「その他」オプションを提供します。
• リポジトリから検証済み、ユーザーが確認済み、不確か、欠落の情報を明確に区別してください。
• 別のリポジトリの表現、プロジェクト固有のコマンド、ブランディング、またはコンテンツをコピーしないでください。一般的な情報アーキテクチャと作成原則のみを使用してください。
• 生成された README ファイルでは絵文字を使用しないでください。視覚的なガイダンスは、検証済みの画像アセット、バッジ、およびソースに基づく ASCII ダイアグラムに限定します。
• デフォルトでヘッダーのアイデンティティバンドを中央揃えにします：オプションのビジュアル、プロジェクト名、1行のポジショニング、言語切り替え、バッジ。タイトルには <h1 align="center"> を使用し、他の各ブロックには個別の <p align="center"> を使用します。最初の ## 見出し以降はすべて左揃えにします — 見出し、散文、テーブル、リスト、コードブロック、ASCII ダイアグラムは中央揃えにしないでください。README 構造ガイダンス の中央揃えヘッダー標準に従ってください。
• アーキテクチャ図は、リポジトリの証拠またはユーザーがそのコンポーネント、境界、関係を確認した場合にのみ含めてください。アーキテクチャ図は、フェンス付き text ブロック内の ASCII アートです — Mermaid は絶対に使用しないでください。
• 使用例は、ユーザーが例の散文、画像/アセット、コードまたはコマンド、期待される結果、配置、言語を提供または確認した場合にのみ含めてください。未検証のアイデアを公開された例にしないでください。

ASCII アーキテクチャ図の標準

この標準は、ソースに基づくオプションの ## Architecture セクションにのみ使用します。Highlights の直後、オプションの Usage Example の前に配置します。Mermaid、Mermaid フェンス、または Mermaid 構文は決して使用しないでください。

許可される記号

boxes:       ┌─┐ │ └─┘
arrows:      ──▶  ◀──  ──▷  ↑ ↓ ←  →
double line: ═══  ║
labels:      ラベルを矢印の上または上に配置します。例：──[HTTP]──▶

レイアウト例

単層：

┌─────────┐     ┌─────────┐     ┌──────────┐
│  Client │────▶│   API   │────▶│ Database │
└─────────┘     └─────────┘     └──────────┘

グループ化または階層化：

┌─────────────────────────────────┐
│             Backend             │
│  ┌──────────┐  ┌─────────────┐  │
│  │   Auth   │  │  Business   │  │
│  │ Service  │  │   Service   │  │
│  └──────────┘  └─────────────┘  │
└─────────────────────────────────┘

ラベル付き矢印：

┌─────────┐  REST/HTTPS  ┌─────────┐  SQL  ┌──────────┐
│  Client │─────────────▶│   API   │──────▶│ Postgres │
└─────────┘              └─────────┘       └──────────┘
                               │
                          gRPC │
                               ▼
                         ┌─────────┐
                         │  Cache  │
                         │ (Redis) │
                         └─────────┘

図のルール

• GitHub で配置が維持されるように、フェンス付き text ブロックを使用します。
• ボックスの幅を揃え、同じレイヤーのボックスを同じ高さに保ちます。
• 水平レイアウトを優先します。階層が必要な場合にのみ垂直レイアウトに切り替えます。
• 矢印のラベルは、接続線の上または線に沿って配置します。
• 検証済みまたはユーザー確認済みのコンポーネント、境界、フローのみを描画します。これらの事実が欠落している場合は、セクション全体を省略します。

ワークフロー

1. まずリポジトリの事実を発見する

範囲を限定したスキャンを実行します。README 固有の理由なしにコードベース全体を読み取らないでください。

1. ディレクトリが Git リポジトリかどうかを判断します。ルートファイルリストと、利用可能な場合は設定されたリモート URL を検査します。
2. 既存の README バリアント、LICENSE*、コントリビューションおよびセキュリティファイル、さらにドキュメントインデックスを読み取ります。
3. 存在するマニフェストのみを読み取ります。例：package.json、pyproject.toml、Cargo.toml、go.mod、pom.xml、または言語相当のメタデータ。
4. CI、リリース/公開、デプロイ設定、例、およびパブリックエントリポイントは、インストール、初回使用、プラットフォームサポート、アーキテクチャ、使用例、またはドキュメントリンクを検証するために必要な場合にのみ検査します。
5. いずれかの README バリアントが存在する場合は、ドラフト作成前にユーザーに処理モードを選択してもらいます：
   • 1) 完全に置き換える： 既存の README の情報を一切使用せずに新しい README を作成します。
   • 2) 選択した既存情報で置き換える： 新しい README を作成し、ユーザーが承認した正確な既存コンテンツのみを保持します。
   • 3) 既存の README を拡張する： 既存の README の構造と正確なコンテンツを保持し、その場でコンテンツを追加または改善します。
6. ドラフト作成の前に事実台帳を作成します：

ステータス	意味
リポジトリから検証済み	ローカルファイル、マニフェスト、CI 設定、または設定されたリモートによって直接サポートされている。
ユーザーが確認済み	ユーザーによって明示的に提供または承認された。
不確か	もっともらしいが、確認なしに公に述べるのは安全ではない。
欠落	望ましいセクションに必要だが、発見できない。

リモートリポジトリを検証できない場合は、その旨を述べてください。所有者、リポジトリ URL、パブリックデモ、リリースページ、コミュニティ、ホスティングプロバイダー、またはアーキテクチャを想定しないでください。

2. 該当するガイダンスのみを読み込む

• セクションを選択したり散文を作成したりする前に、README 構造ガイダンス を読んでください。
• バッジが要求または評価された場合は、バッジガイダンス を読んでください。
• 画像が要求された場合は、画像ガイダンス を読んでください。
• 最終ドラフトを提示する前とファイルを作成する前に、品質チェックリスト を読んでください。
• プロジェクトタイプと言語レイアウトが判明した後、templates/ 内の該当するテンプレートのみを読んでください。

3. 証拠が答えられない決定のみを尋ねる

一度に 1 つの質問をしてください。実用的な場合は、決定を明示的なオプションのリストとして提示し、必要な場合にのみ自由形式の「その他」オプションを含めてください。すでに検証または回答された情報を繰り返さないでください。

1. 発見中に既存の README が見つかった場合は、後続のコンテンツ設定を尋ねる前に、ユーザーに上記の処理モードを選択してもらいます。
2. 言語レイアウトを尋ねます：英語、英語と簡体字中国語、または中国語。
   • バイリンガル出力の場合、README.md は英語の主要な GitHub ランディングページであり、README.zh-CN.md は中国語バージョンです。
   • 中国語のみの出力の場合、GitHub はデフォルトでルート README.md を表示することを説明し、中国語を主要ページにするかどうかを尋ねます。
3. ユーザーが Shields.io バッジの推奨を希望するかどうかを尋ねます。
   • 検証済みの推奨を含める、バッジを省略する、その他などの明示的な選択肢を提供します。
   • リポジトリに検証済みの LICENSE* ファイルが含まれている場合は、検証済みバッジセットの一部として、リンクされた静的ライセンスバッジをデフォルトで推奨し、ユーザーに承認または削除を任せます。
   • 主張と宛先が検証可能なバッジのみを推奨し、ユーザーに承認、削除、または追加を任せます。
4. ASCII アーキテクチャ図を含めるかどうかを尋ねます。
   • ソースに基づく ASCII 図を含める、省略する、その他を提供します。
   • 含める場合、描画する前にリポジトリの証拠またはユーザーからコンポーネント、グループ境界、関係、ラベルを確認します。
5. 使用例を含めるかどうかを尋ねます。
   • 提供された例を含める、省略する、その他を提供します。
   • 含める場合、確認済みの例の散文、画像/アセット、コードまたはコマンド、期待される結果、希望する配置、言語を収集します。参照する前にローカル画像パスを検証し、資格情報を決して公開しないでください。
6. デフォルトで中央揃えヘッダーを使用します。ユーザーが異なる外観を要求した場合にのみ尋ね、最小限の HTML による中央揃えヘッダー、プレーンな左揃えの Markdown ヘッダー、その他を提供します。
7. 画像が必要かどうかを尋ねます。
   • 画像なし、既存のアセットを使用、新しい画像を生成を提供します。
   • 「はい」の場合、既存のアセットが利用可能かどうかを尋ねます。
   • アセットが利用できない場合、ビジュアルをアイコンのみ、アイコンと 1 行の短いテキスト、またはアイコンとプロジェクト名と 1 行の短いテキストのいずれにするかを尋ねます。
   • ユーザーが OpenAI 画像サービスを選択した場合、何かを生成する前に API URL と API キー（またはそれらをすでに含む環境変数の名前）を尋ねてください。エンドポイント、モデル、応答形式、出力場所を推測しないでください。
   • 生成リクエストには scripts/generate-image.py を使用します。資格情報は環境変数またはプロセス引数でのみ渡し、リポジトリ、README、プロンプト、画像 URL、または Git にコミットするコマンドに決して書き込まないでください。
   • 生成されたローカルアセットを README にパスを追加する前に検証します。生成が失敗した場合は、プロバイダーニュートラルなプロンプトを表示して失敗を報告し、画像参照を作り出さないでください。
8. Star History チャートを追加するかどうかを尋ねます。
   • 含める、省略する、その他を提供します。
   • ユーザー確認後かつ、リモート URL からパブリック GitHub owner/repo 識別子を検証できるか、ユーザーによって提供された場合にのみ含めます。
   • Community & support の後、License の直前に配置します。
   • パブリック GitHub リポジトリ用のサードパーティ製動的 SVG を埋め込むことを明記します。リポジトリがプライベートである場合、owner/repo が不明確である場合、またはユーザーが辞退した場合は省略します。
9. 検証できない残りの公開情報のみを尋ねます：ターゲットオーディエンス、主要な強調点、ドキュメントサイト、デモ、コミュニティ、コントリビューションルート、FAQ、ロードマップ、引用、またはセキュリティポリシー。

4. ドラフトを作成する

関連する構造とテンプレートを使用し、Quick Start を除くすべての該当しないセクションを削除します。Quick Start はすべてのドラフトに残り、検証済みの最短の初回使用パスを使用する必要があります。そのようなパスが存在しない場合は、最終ドラフトを提示する前にユーザーに尋ねてください。網羅的な機能リストよりも、簡潔で証拠に基づいた散文と有用な初回実行体験を優先します。

選択およびサポートされている場合、すべての README の先頭近くで次の順序を維持します：

Highlights → オプションの Architecture → オプションの Usage Example → Quick Install → Quick Start

ファイルの書き込み前に、以下を提示します：

1. 簡潔な構造に関する推奨事項。
2. 選択された各言語ファイルの完全な Markdown ドラフト。
3. 事実台帳とユーザー確認済みの詳細のリスト。
4. 提案されたバッジと各バッジのデータソース。
5. 要求された場合の、ソースに基づく ASCII アーキテクチャ図。
6. 要求された場合の、使用例の内容、出典、配置。
7. 要求された場合の、画像の配置と生成に関する推奨事項。
8. 要求された場合の、Star History の配置と検証済みの owner/repo。
9. README がすでに存在する場合、明示的な 保持 / 移動 / マージ / 削除 の要約。

5. 明示的な確認後にのみ書き込む

README のドラフト作成、改善、レビュー、表示のリクエストは、ファイルを書き込む許可ではありません。ユーザーが名前付きのターゲットパスへの書き込み、更新、置き換え、保存を明示的に要求した場合にのみ書き込んでください。

書き込む直前に、すべてのターゲットファイルと変更内容を明記します：

• 英語：README.md。
• バイリンガル：README.md と README.zh-CN.md。
• 中国語：ユーザーが確認したプライマリパスを使用します。
• 保存されたドラフト：ユーザーが指定したパスのみ。

既存のファイルの場合、可能な限り有用で正確なコンテンツを保持します。コンテンツを黙って破棄しないでください。重要な移動、マージ、削除を説明します。書き込み後、実際のファイルに対して品質チェックリストを実行します。

最終報告

次のコンパクトな結果形式を使用します：

Files changed:
- <パスと目的、または「なし — ドラフトは会話内でのみ表示」>

Verified:
- <事実、コマンド、パス、リンク、またはバッジのソース>

Needs confirmation:
- <未検証の公開情報または手動チェック>

Not included:
- <未検証または拒否されたために省略されたセクション、バッジ、画像、またはチャート>