guarantee-auditlisted

**公開パイプラインの固定順**: `repo-standardize → guarantee-audit → repo-readme → readme-i18n → repo-publish → repo-about`。本 Skill は**第2**（新規リポではテストの有無を確認し、README 本格化より前に台帳を敷く）。この順は都度再判断しない。 相談者として保証台帳の棚卸しを行う。台帳ドラフトの作成、裁可済み欠落テストの追加、台帳の正式運用への格上げまでが担当。欠落テストはIssueにしない（裁可の時点でアサーションが確定しており、実装の自由度が残らないため。Issueは自由度の統制であり、統制すべき自由度が無い）。**プロダクトコード（src/）は書かない**。 1. 前提確認: 対象リポに `docs/guarantees.md` が無いことを確認する - 既にあれば「棚卸し済み」。この場合は 2〜3 を「現行台帳とテストの差分確認」に読み替える（乖離チェックモード） - ���ストが1本も無ければ、台帳ではなく通常Issueで最初のテストから始めるべき旨を報告する。**棚卸し文脈**（既存リポへの後付け実行）ではここで止まる。**パイプライン文脈**（公開パイプライン第2ステップとしての実行）では止まらず、skip した旨を明示的に報告して次ステップ���`repo-readme`）へ進む 2. 抽出: リポの全テストファイルを読み、テストが固定している振る舞いを自然言語の保証として書き出す - 契約面（公開API・CLI・配布物・外部から観測可能な振る舞い）と内部実装を仕分け、**契約面のみ**を一覧にする - 各保証に出典（テストファイル・テスト名）を付す - 契約面か内部実装か判断が割れる面（CLI内部関数群等）だけ、この時点で user に質問する 3. ドラフト書き出し: 抽出結果を `docs/guarantees.md` にドラフトとして書き出す。**一覧をチャットに全量貼らない**（user のレビュー対象はファイル）。構成・書式は `reference/example-guarantees.md` の例に従う（骨組み・主語の反復ルール・見出し言語ともにここが正）。要点: - **見出し（H1〜H3）は英語、本文（箇条書き・表・注釈）は日本語**。見出しの丸括弧も半角 `()`。タイトルは `# Guarantee Ledger (Draft)` - 本体は `## Guarantees` 節から始める。読み手が最初に読むのは保証そのものであり、前提説明ではない - `## Guarantees` の中はテストファイル単位で区切る（`### N. \`tests/test_x.py\` — target module/class (function)`。ファイルパスは常にバッククォート）。各区切りの中は、テストが保証している振る舞いをそのまま**宣言文**として箇条書きにする。見出しに機能名（例:「パラメータ上書き」）だけを立てて実際の保証を本文に書く二段構成にしない——見出しやラベルは保証の要約ではなく、保証文そのものが主役 - 区切り内が単一の関数・メソッドのみを扱うなら、箇条書きのたびに主語（その名前）を書き直さない。区切り内に複数の異なる関数・メソッドが混在するなら、行ごとに主語を明示する。前者で毎回主語を書くと型の反復になり、後者で省くとどの対象の