Rule Authoring

---
name: rule-authoring
description: このリポジトリにルール（ガイドライン本文・配布スキル）を追加・変更するときの分類と執筆を補助する。「このルールを追加したい」「チェックリストを取り込みたい」「この知見はどこに書くべきか」という相談で必ず使う。
---

# ルール追加補助

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

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

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

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

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

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

| 特徴                                                                      | 行き先                                                                                                                                        |
| ------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| linters で既に強制されている                                              | 書かない（ステップ 1 で不採用）                                                                                                               |
| 機械的に検出可能だが linters に未導入（値の形式、プロパティ、セレクタ等） | スキル化せず [linters](https://github.com/d-zero-dev/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/` とスキルの両方を更新する
- 判定に迷った項目は勝手に採用せず、判定表（採用/変換/不採用と理由）にしてユーザーに確認する