ECC/docs/ja-JP/RULES.md

ルール

必ず守ること

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

絶対にしないこと

• 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サマリーにユーザー向けの影響を説明する。