sekkeilisted

# 設計（sekkei） 実装前に価値のある判断だけを明確にする。小さな変更へ設計工程を追加しない。 <!-- 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 --> ## 使い分け - 方針決定：推奨案と重要なトレードオフを決める - 評価：`Kill` / `Keep` / `Pivot`のどれかを理由付きで選ぶ - 計画：実装可能な手順と検証方法へ落とす ## 手順 1. 解決することと対象外を短く分ける 2. コード・テスト・文書から判断に必要な事実だけ確認する。広い未知領域の調査自体が成果なら`tansaku`を使えるが、局所確認は自分で行う 3. 新規構想、ゼロベース・メタ評価、新しい仕組みや抽象化では、既存案をいったん外し、目的と必須制約から必要性と責務を考える。利用者の例は意図を理解する材料とし、明示されない限りその表現や一件だけを仕様にしない。既存プロジェクトへの具体的な変更では、周辺コードと規約に合わせ、要求外へ広げない素直な案を選ぶ 4. 推奨案を1つ決める。代替案は結論が拮抗するときだけ1つ添える 5. 要求、既存構造、取り消しやすさ、セキュリティ・データ・公開インターフェースへの影響でリスクを評価する 6. 結果や対象範囲を大きく変える未決事項だけ利用者に確認する。明確な選択や可逆な詳細は自分で決める 7. 計画を求められたら、観測できる変更・主なファイル・検証を手順にする。`references/minimal-approach.md`で要求外の作業を落とす 8. 同じ依頼に実装も含まれる場合は、未決事項がなければ承認のためだけに止まらず実装へ続ける ## 報告 推奨する判