jikkoulisted

# 実行（jikkou） 明示された変更範囲を理解し、実装とリスクに見合う検証まで完了する。 <!-- hikizan:contract:start --> ## 共通ルール 全スキル共通。正本は`scripts/contract.md`で、`scripts/gen-contract.sh`が各`SKILL.md`のこの区間に書き込む（手で編集しない）。 - 各スキルを起動したら、そのスキルの作業を始める直前に1行だけ`🌲 <スキル名>（日本語名）：<今回の目的>`と伝える。複数スキルを1行にまとめず、まだ始めないスキルを予告しない。同じスキル内の局所作業では繰り返さない - 調査、相談、設計、レビューだけの依頼では対象を変更しない。修正、追加、削除、実行、PR提出が依頼に含まれる場合だけ、必要なスキルをつないで明示された終点まで進む - スキルを固定順に通さず、依頼された成果に必要な観点だけを使う。明示済みの終点へ向かう途中で、形式的な承認を追加しない - 利用者が示した例や問題箇所を変更範囲そのものとみなさない。背景の原因と守るべき規則を確認し、同じ原因を防ぐ最小の共通箇所を変更する。要求外の一般化はしない - 検証はリスクに比例させ、未検証の状態を成功や完了と書かない - 人へ渡す日本語は結果か判断を先に置き、簡潔で分かりやすく書く。文章の表現や構成自体が成果なら`houkoku`を使う - PRのマージと既定ブランチへの直接のpush、公開・配布・本番環境や共有データを変更する操作は、利用者が依頼の終点として明示した場合だけ行う。「PRまで」はマージを含めない。明示済みなら作業判断のために再確認せず、ハーネスが実行直前の確認を表示した場合はその結果に従う - 停止するときに意味のある次の進め方があれば、最大3件を推奨順に`A（あ）`、`I（い）`、`U（う）`で示し、英字とひらがなのどちらの回答も同じ選択として扱う <!-- hikizan:contract:end --> ## 使い分け - 実装：依頼された観測可能な変更を完成させる - 障害修正：症状を再現し、原因を絞ってから修正する ## 手順 1. リポジトリ、提示された事象、期待結果を確認する。提示箇所を変更範囲と決めつけず、原因を共有する近隣経路を必要な範囲だけ確認する。局所的で可逆な判断は既存コードと規約に合わせて自分で決める 2. セキュリティ・権限・公開API・スキーマ・データ移行・不可逆操作など、結果を大きく変える未承認の判断だけ実装前に確認する 3. 変更を小さな観測可能な振る舞い単位で実装する。調査や独立レビューに標準サブエージェントを使ってよいが、編集内容と検証結果は親エージェントが確認する 4. バグ修正は同じ入力で症状を再現し、安定したテスト基盤があるなら回帰テストを先に失敗させる。新しいロジックや公開契約も回帰価値が高い場合は`references/tdd.md`を使う 5. 文書・設定・UIなどは対象に合う検証を選ぶ。各編集へ儀式的にテストを追加しない 6. UI・スタイル・配置・操作を���更する場合は、`references/visual-verification.md`に従い、対象プロジェクトまたは現在のハーネスで利用できる視覚検証方法を使う 7. 文言や局所的な可逆変更は最寄りの検査、ロジック・API・バグ修正は関連する回帰検査、セキュリティ・権限・スキーマ・移行・データ損失・取り消しが難しい変更は、関連検査に加えてリポジトリの