# ルール ## 必ず守ること - ドメインタスクは専門エージェントに委任する。 - 実装前にテストを書き、クリティカルパスを検証する。 - 入力を検証し、セキュリティチェックを維持する。 - 共有状態のミューテーションよりもイミュータブルな更新を優先する。 - 新しいパターンを発明する前に、確立されたリポジトリパターンに従う。 - 貢献は焦点を絞り、レビュー可能で、十分に説明されたものにする。 ## 絶対にしないこと - APIキー、トークン、シークレット、絶対パス/システムファイルパスなどの機密データを出力に含める。 - テストされていない変更を提出する。 - セキュリティチェックやバリデーションフックをバイパスする。 - 明確な理由なく既存の機能を複製する。 - 関連するテストスイートを確認せずにコードを出荷する。 ## エージェント形式 - エージェントは `agents/*.md` に配置する。 - 各ファイルには `name`、`description`、`tools`、`model` を含むYAMLフロントマターが必要。 - ファイル名は小文字のハイフン区切りで、エージェント名と一致させる。 - descriptionにはエージェントを呼び出すべきタイミングを明確に伝える。 ## スキル形式 - スキルは `skills//SKILL.md` に配置する。 - 各スキルには `name`、`description`、`origin` を含むYAMLフロントマターが必要。 - ファーストパーティのスキルには `origin: ECC`、インポート/コミュニティのスキルには `origin: community` を使用する。 - スキル本文には実践的なガイダンス、テスト済みの例、明確な「使用タイミング」セクションを含める。 ## フック形式 - フックはマッチャー駆動のJSON登録とシェルまたはNodeのエントリーポイントを使用する。 - マッチャーは広範なキャッチオールではなく、具体的にする。 - ブロック動作が意図的な場合にのみ `exit 1` を使用し、それ以外は `exit 0` とする。 - エラーメッセージと情報メッセージはアクショナブルにする。 ## コミットスタイル - `feat(skills):`、`fix(hooks):`、`docs:` などのConventional Commitsを使用する。 - 変更はモジュール化し、PRサマリーにユーザー向けの影響を説明する。