# ルール

## 必ず守ること
- ドメインタスクは専門エージェントに委任する。
- 実装前にテストを書き、クリティカルパスを検証する。
- 入力を検証し、セキュリティチェックを維持する。
- 共有状態のミューテーションよりもイミュータブルな更新を優先する。
- 新しいパターンを発明する前に、確立されたリポジトリパターンに従う。
- 貢献は焦点を絞り、レビュー可能で、十分に説明されたものにする。

## 絶対にしないこと
- APIキー、トークン、シークレット、絶対パス/システムファイルパスなどの機密データを出力に含める。
- テストされていない変更を提出する。
- セキュリティチェックやバリデーションフックをバイパスする。
- 明確な理由なく既存の機能を複製する。
- 関連するテストスイートを確認せずにコードを出荷する。

## エージェント形式
- エージェントは `agents/*.md` に配置する。
- 各ファイルには `name`、`description`、`tools`、`model` を含むYAMLフロントマターが必要。
- ファイル名は小文字のハイフン区切りで、エージェント名と一致させる。
- descriptionにはエージェントを呼び出すべきタイミングを明確に伝える。

## スキル形式
- スキルは `skills/<name>/SKILL.md` に配置する。
- 各スキルには `name`、`description`、`origin` を含むYAMLフロントマターが必要。
- ファーストパーティのスキルには `origin: ECC`、インポート/コミュニティのスキルには `origin: community` を使用する。
- スキル本文には実践的なガイダンス、テスト済みの例、明確な「使用タイミング」セクションを含める。

## フック形式
- フックはマッチャー駆動のJSON登録とシェルまたはNodeのエントリーポイントを使用する。
- マッチャーは広範なキャッチオールではなく、具体的にする。
- ブロック動作が意図的な場合にのみ `exit 1` を使用し、それ以外は `exit 0` とする。
- エラーメッセージと情報メッセージはアクショナブルにする。

## コミットスタイル
- `feat(skills):`、`fix(hooks):`、`docs:` などのConventional Commitsを使用する。
- 変更はモジュール化し、PRサマリーにユーザー向けの影響を説明する。
