sadokulisted

# 査読（sadoku） 本番コードとエージェントが実行するMarkdownを、実装者の説明から独立してレビューする。レビュー中は対象を変更しない。 <!-- hikizan:contract:start --> ## 共通ルール 全スキル共通。正本は`scripts/contract.md`で、`scripts/gen-contract.sh`が各`SKILL.md`のこの区間に書き込む（手で編集しない）。 - 各スキルを起動したら、作業前に1行だけ`🌲 <スキル名>（日本語名）：<今回の目的>`と伝える。同じスキル内の局所作業では繰り返さない - スキルを固定順に通さない。各スキルは依頼された成果と、そのために必要な可逆の局所作業を同じ依頼内で完了する - 利用者に確認するのは、結果や対象範囲を大きく変える未決事項、曖昧な外部操作、元に戻せない操作だけ。明確で可逆な作業は止めない - 検証はリスクに比例させ、実行したコマンドと判定に必要な結果を残す。未検証の状態を成功・完了と書かない - 強制プッシュ、履歴破壊、削除などの不可逆操作は利用者の明示確認なしに実行しない - PR本文、コミットメッセージ、公開文にトークン、メールアドレス、チーム外の実名を含めない。外へ出す直前に対象を検査する <!-- hikizan:contract:end --> ## 使い分け - レビュー：バグ、回帰、セキュリティ、既存コードベースとの不整合を探す - 簡略化：振る舞いを変えずに減らせる分岐・層・重複・不要コードを探す ## 手順 1. 対象時点を固定する。ブランチ全体の比較元は利用者・PR指定、なければ選んだリモートの既定ブランチとし、機能ブランチの上流ブランチを比較元にしない。`merge-base`からのコミット済み・ステージ済み・未ステージ・未追跡ファイルを含め、途中で別の対象範囲へ読み替えない 2. 変更意図、関連テスト、近隣の類似実装、リポジトリ規約を必要な範囲だけ読む 3. リスクで深さを決める。局所的で可逆なら軽量、振る舞い・API・複数モジュールへ波及するなら標準、セキュリティ・権限・スキーマ・移行・データ損失・並行性・取り消し費用が高い変更なら重点とする 4. 正しさ、失敗経路、既存パターン、より単純な表現、追加行への秘密情報・個人情報混入を確認する。行数やファイル数だけでレビュー担当を増やさない 5. 独立した専門性が結果を改善する場合だけ`references/persona-catalog.md`の契約で専門レビューを行う 6. UI・スタイル・配置・操作に触れる場合は、対象リポジトリに設定済みのShimonがあるときだけ次の契約で視覚確認する <!-- hikizan:visual:start --> - 信頼できる対象にShimonとレビュー済みの`shimon.config.mjs`がある場合だけ使う。自動インストールや別ツールへの切替は行わない。ChromeやPlaywrightなどのブラウザー実行ファイルを直接起動して代替しない - 今回必要なケースだけを`.shimon/task.mjs`へ書く。サーバー起動とブラウザー確認はリポジトリ所定の固定コマンドへ集約し、なければ`./node_modules/.bin/shimon verify --task .shimon/task.mjs --json`を使う。終了後に一時ファイルを削除する - JSONの`pass`と各自動検査を確認