sekkeilisted

# 設計（sekkei） 実装前に価値のある判断だけを明確にする。小さな変更へ設計工程を追加しない。 <!-- hikizan:contract:start --> ## 共通ルール 全スキル共通。正本は`scripts/contract.md`で、`scripts/gen-contract.sh`が各`SKILL.md`のこの区間に書き込む（手で編集しない）。 - 各スキルを起動したら、作業前に1行だけ`🌲 <スキル名>（日本語名）：<今回の目的>`と伝える。同じスキル内の局所作業では繰り返さない - スキルを固定順に通さない。各スキルは依頼された成果と、そのために必要な可逆の局所作業を同じ依頼内で完了する - 利用者に確認するのは、結果や対象範囲を大きく変える未決事項、曖昧な外部操作、元に戻せない操作だけ。明確で可逆な作業は止めない - 検証はリスクに比例させ、実行したコマンドと判定に必要な結果を残す。未検証の状態を成功・完了と書かない - 強制プッシュ、履歴破壊、削除などの不可逆操作は利用者の明示確認なしに実行しない - PR本文、コミットメッセージ、公開文にトークン、メールアドレス、チーム外の実名を含めない。外へ出す直前に対象を検査する <!-- hikizan:contract:end --> ## 使い分け - 方針決定：推奨案と重要なトレードオフを決める - 評価：`Kill` / `Keep` / `Pivot`のどれかを理由付きで選ぶ - 計画：実装可能な手順と検証方法へ落とす ## 手順 1. 解決することと対象外を短く分ける 2. コード・テスト・文書から判断に必要な事実だけ確認する。広い未知領域の調査自体が成果なら`tansaku`を使えるが、局所確認は自分で行う 3. ゼロベース・メタ評価を求められた場合、または新しい仕組み・抽象化・工程を足す場合は、既存案をいったん外し、目的と必須制約だけから最小構成を考える。そもそもの必要性と、責務を置く層も確認する 4. 推奨案を1つ決める。代替案は結論が拮抗するときだけ1つ添える 5. 要求、既存構造、取り消しやすさ、セキュリティ・データ・公開インターフェースへの影響でリスクを評価する 6. 結果や対象範囲を大きく変える未決事項だけ利用者に確認する。明確な選択や可逆な詳細は自分で決める 7. 計画を求められたら、観測できる変更・主なファイル・検証を手順にする。`references/minimal-approach.md`で要求外の作業を落とす 8. 同じ依頼に実装も含まれる場合は、未決事項がなければ承認のためだけに止まらず実装へ続ける ## 報告 推奨する判断を最初に書く。必要な場合だけトレードオフ、未決事項、最小計画を続ける。評価では`Kill` / `Keep` / `Pivot`を曖昧にしない。 ## 禁止事項 - ファイル数や行数だけで設計工程を重くする - 明確な依頼へ選択肢一覧や形式的な再承認を追加する - 要求外の将来拡張を計画へ混ぜる ## 関連資料 - `minimal-approach.md`：計画や設計案から要求外の複雑さを落とすときに読む