tansakulisted

# 探索（tansaku） 調査結果を証拠付きで返す。設計や実装を求められていない限り、対象を変更しない。 <!-- hikizan:contract:start --> ## 共通ルール 全スキル共通。正本は`scripts/contract.md`で、`scripts/gen-contract.sh`が各`SKILL.md`のこの区間に書き込む（手で編集しない）。 - 各スキルを起動したら、作業前に1行だけ`🌲 <スキル名>（日本語名）：<今回の目的>`と伝える。同じスキル内の局所作業では繰り返さない - スキルを固定順に通さない。各スキルは依頼された成果と、そのために必要な可逆の局所作業を同じ依頼内で完了する - 利用者に確認するのは、結果や対象範囲を大きく変える未決事項、曖昧な外部操作、元に戻せない操作だけ。明確で可逆な作業は止めない - 検証はリスクに比例させ、実行したコマンドと判定に必要な結果を残す。未検証の状態を成功・完了と書かない - 強制プッシュ、履歴破壊、削除などの不可逆操作は利用者の明示確認なしに実行しない - PR本文、コミットメッセージ、公開文にトークン、メールアドレス、チーム外の実名を含めない。外へ出す直前に対象を検査する <!-- hikizan:contract:end --> ## 手順 1. 調べる問いと対象範囲を1文で固定する。対象が一意なら確認のために止まらない 2. README、プロジェクト指示、関連するコード・テストから、問いに答える最小範囲を読む 3. 定義、参照、呼び出し元、データの流れを辿る。履歴や`TODO`は、現在のコードだけでは理由を判断できない場合に限って見る 4. 独立した重い調査軸が複数あり、標準サブエージェントが使える場合だけ読み取り専用で分担する。契約は`references/fanout.md`を読む 5. リポジトリ固有のドメイン用語や一般的な意味と異なる語があれば、初出に平易な意味、コード上の役割、`file:line`を1〜2文で添える。一般的な技術用語の用語集は作らない 6. 観測した事実、そこから直接導ける影響、まだ分からないことを分ける。推測で空欄を埋めない 7. ドメイン用語や不変条件の永続化は、利用者が文書化を求めた場合か、同じ誤解が繰り返される根拠がある場合だけ提案する。通常の探索では新しい`CONTEXT.md`を持ち込まない ## 報告 結論を先に置き、主要なパス・シンボル・テストへ`file:line`を添える。リポジトリ固有の用語は必要なものだけ短く説明し、影響範囲と未確認事項があれば続ける。図が文章より明確な依存関係だけ、小さなMermaid図を1枚使う。 ## 禁止事項 - 調査依頼を設計会議や文書化作業へ自動的に広げる - 根拠のない推測を確定事項として扱う - サブエージェントへ用語確定、設計判断、ファイル変更を任せる ## 関連資料 - `fanout.md`：広い調査を標準サブエージェントへ分ける場合だけ読む