jikkoulisted

# 実行（jikkou） 必要な範囲を理解し、変更し、リスクに見合う検証まで完了する。明確な実装を計画待ちにしない。 <!-- hikizan:contract:start --> ## 共通ルール 全スキル共通。正本は`scripts/contract.md`で、`scripts/gen-contract.sh`が各`SKILL.md`のこの区間に書き込む（手で編集しない）。 - 各スキルを起動したら、作業前に1行だけ`🌲 <スキル名>（日本語名）：<今回の目的>`と伝える。同じスキル内の局所作業では繰り返さない - スキルを固定順に通さない。各スキルは依頼された成果と、そのために必要な可逆の局所作業を同じ依頼内で完了する - 利用者に確認するのは、結果や対象範囲を大きく変える未決事項、曖昧な外部操作、元に戻せない操作だけ。明確で可逆な作業は止めない - 検証はリスクに比例させ、実行したコマンドと判定に必要な結果を残す。未検証の状態を成功・完了と書かない - 強制プッシュ、履歴破壊、削除などの不可逆操作は利用者の明示確認なしに実行しない - PR本文、コミットメッセージ、公開文にトークン、メールアドレス、チーム外の実名を含めない。外へ出す直前に対象を検査する <!-- hikizan:contract:end --> ## 使い分け - 実装：依頼された観測可能な変更を完成させる - 診断：症状を再現し、原因を絞って修正する ## 手順 1. リポジトリ、対象範囲、期待結果を確認する。局所的で可逆な判断は既存コードと規約に合わせて自分で決める 2. セキュリティ・権限・公開API・スキーマ・データ移行・不可逆操作など、結果を大きく変える未承認の判断だけ実装前に確認する 3. 変更を小さな観測可能な振る舞い単位で実装する。調査や独立レビューに標準サブエージェントを使ってよいが、編集内容と検証結果は親エージェントが確認する 4. バグ修正は同じ入力で症状を再現し、安定したテスト基盤があるなら回帰テストを先に失敗させる。新しいロジックや公開契約も回帰価値が高い場合は`references/tdd.md`を使う 5. 文書・設定・UIなどは対象に合う検証を選ぶ。各編集へ儀式的にテストを追加しない 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`と各自動検査を確認し、返された全スクリーンショットを`intent`と`review`に沿って見る。`visualReviewRequired: true`を視覚確認済みとは扱わない - スクリーンショットとログへ秘密情報・個人情報を残さない。実行条件を満たさなければ、理由を添えて