ルール追加補助

新しいルール案（レビュー指摘の知見、チェックリスト、注意点など）を受け取ったら、執筆する前に以下のトリアージを順に通し、判定結果と根拠をユーザーに提示して合意を取る。

ステップ 1: 一次原理の問い

置き場所を考える前に、次の 4 つを必ず問う。

1. そもそもルール化すべきか
   • linters の共通設定（stylelint / eslint / markuplint 等）で既に強制されていないか → 強制済みなら不採用。強制ハーネスが担保するものを原則に書く必要はない（重複はトークンと保守の無駄）
   • 既存スキル・別ドキュメントで担保されていないか → 担保済みなら不採用
   • 一過性の事象ではないか、ルール化のコストに見合うか → 見合わなければ不採用を提案
2. 本質の抽象度は何か
   • ツール名・時代性を剥がして原則に言い換えられるか
   • 例: 「Figma の数値を固定値で書いてしまう」→ 本質は「デザインデータの数値は結果であって仕様ではない」（Figma 固有ではなく、あらゆるデザインカンプに当てはまる）
   • 固有名詞は原則に据えず、具体例・起動トリガー（description の語彙）としてのみ使う
3. 恒常的原則か、一時的補正か
   • 現時点の AI・ツールの欠陥への補正（モデル改善や環境整備で不要になるもの）なら、解消条件と削除メモを付けて登録する
   • 例: 「lint ルール○○が linters に導入されたらこの項目は削除する」
4. 宛先は誰か
   • 実装エージェント / レビュアー / デザイナー / lint（機械） / 人間の運用ルール
   • 実装エージェント以外が宛先の知見はスキルに混ぜず、該当先（デザイナー向けガイドライン、linters リポ、運用ドキュメント等）への提案として分離する

ステップ 2: 置き場所の分類

ステップ 1 を通過したルールを、次の基準で分類する。

特徴	行き先
linters で既に強制されている	書かない（ステップ 1 で不採用）
機械的に検出可能だが linters に未導入（値の形式、プロパティ、セレクタ等）	スキル化せず linters への追加を提案。lint 導入までの暫定記載は明示合意がある場合のみ（削除メモ必須）
実装レイヤー（HTML/CSS/JS）の選定に関わる	skills/dzero-tech-selection
デザインカンプの解釈・デザインとの突き合わせに関わる	skills/dzero-design-to-code
技術軸の設計判断・文脈依存の規範（lint で拾えない）	skills/dzero-css / dzero-js / dzero-a11y / dzero-html の「実装規範」（レビュー観点は独立して書かない。規範がレビューの基準を兼ねる）
レビューの進め方そのもの	skills/dzero-review
ビルダー（kamado）や scaffold 構成に固有	frontend-env リポジトリ（scaffold テンプレートの AGENTS.md / commands）へ提案
常時ロードが必要な短い原則	scaffold テンプレートの AGENTS.md へ提案
案件固有・非公開情報を含む	汎化して採用。汎化できなければ不採用（このリポジトリは公開）

ステップ 3: 執筆

• skills/README.md の執筆規約（frontmatter の制約、内容ポリシー、構成）に従う
• 根拠のない一般論を書かない。書けるだけの根拠がなければ空のセクション + TODO のまま残す
• 精神論・心構えは書かない。エージェントの行動を変えない宣言（「理解して書く」等）は、ガイドライン本文（src/）にあってもスキルには載せない。実用核が埋まっている場合は「X の場合は Y する」という実行・検証可能な判断規則に変換して載せる
• ルールがガイドライン本文（src/）にも関わる場合は、同じ PR で src/ とスキルの両方を更新する
• 判定に迷った項目は勝手に採用せず、判定表（採用/変換/不採用と理由）にしてユーザーに確認する