repo-readmelisted

# repo-readme 本リポの `docs-agents/readme-guide.md` を唯一の基準として README を作成/更新する。 **公開パイプラインの固定順**: `repo-standardize → guarantee-audit → repo-readme → readme-i18n → repo-publish → repo-about`。本 Skill は**第3**。足場とコアメッセージは `repo-standardize` が先に作り、保証台帳は `guarantee-audit` が先に敷く（README が台帳へリンクするには台帳が先に要るため）。本 Skill は**中身（アーキテクチャ・技術選定・判断）が固まった publish 前**に走らせる。この順は都度再判断しない。 ## 0. 基準を読む（必須・最初に） 本 Skill は `docs-agents/` の**判断層**に伴走する側を担う（readme-guide.md §1 のリトマス試験はリポごとに答えが変わる）。 - `docs-agents/readme-guide.md` — README の構成・言語規則・JUDGE.md/PLAN.md 統合・docs/ 分離 - 必要に応じ `docs-agents/cicd-guide.md`（Deploy 節の書き方）・`docs-agents/repo-guide.md`（Secrets を README に書かない方針） 基準は本ファイルに転記しない。食い違ったらガイドを優先する。 ## 1. 種別判定 → 素材を集める readme-guide.md §1 のリトマス試験（使わせる？→ Type B。読ませるなら証拠がコードか数字かで Type A / Type C）でリポの種別を判定する。判定した種別を前提に、以下を読んでから書く。README は創作でなく**既にあるものの集約**。 - リポのコード・ディレクトリ構成（実際の構造・データフロー） - `PLAN.md`（MVP 定義・完成条件）— 生きている内容を README の Scope へ吸収する。**統合ソース（後で削除する対象）** - `JUDGE.md`（あれば）— 技術選定・判断ログ。README の Design Decisions と Tech Stack の Reason 列へ統合する（判断基準を AI が創作しない）。**統合ソース（後で削除する対象）** - `context/structure.md` / `context/conventions.md`（設計の意図。これらは残す） - `.github/workflows/`（CI/Deploy バッジ・デプロイ方式） - 既存 README（あれば差分更新。良い記述は壊さない） ## 2. readme-guide に従って書く readme-guide.md §0 の考える順序に従う。固定の H2 リストを流し込むのではなく、次を順に決める。**H2 の順序・命名・分割は固定しない**。 1. **下限（§2）**: 1で判定した種別（Type A/B/C）の下限チェックリストを満たすことを最低条件にする 2. **コアメッセージ（§3）**: 1文で「何を解決/実証/問うか＋どういう手段で」を確定し、H1直下の概要と一致させる 3. **ターゲット（§4）**: 習熟度／職種・レイヤー／技術利用者のどの軸で誰に向ける