ja-JP

Imported from unsalable/mctg (.cursor/skills/ecc/docs/ja-JP/AGENTS.md). Install upstream with npx skills add unsalable/mctg --skill ja-JP. Copyright stays with the author.

Everything Claude Code (ECC) — エージェント指示書

これは60の専門エージェント、228のスキル、75のコマンド、自動化フックワークフローを提供するプロダクション対応のAIコーディングプラグインです。

バージョン: 2.0.0-rc.1

コア原則

1. エージェントファースト — ドメインタスクは専門エージェントに委任する
2. テスト駆動 — 実装前にテストを書き、80%以上のカバレッジを必須とする
3. セキュリティファースト — セキュリティに妥協せず、すべての入力を検証する
4. イミュータビリティ — 常に新しいオブジェクトを生成し、既存のものを変更しない
5. 実行前に計画 — 複雑な機能はコードを書く前に計画する

利用可能なエージェント

エージェントオーケストレーション

ユーザーのプロンプトなしで積極的にエージェントを使用する：

• 複雑な機能リクエスト → planner
• コードの作成/変更直後 → code-reviewer
• バグ修正または新機能 → tdd-guide
• アーキテクチャの意思決定 → architect
• セキュリティに関わるコード → security-reviewer
• 自律ループ / ループ監視 → loop-operator
• ハーネス設定の信頼性とコスト → harness-optimizer

独立した操作には並列実行を使用する — 複数のエージェントを同時に起動する。

セキュリティガイドライン

コミット前に必ず確認：

• ハードコードされたシークレットがないこと（APIキー、パスワード、トークン）
• すべてのユーザー入力が検証されていること
• SQLインジェクション対策（パラメータ化クエリ）
• XSS対策（HTMLのサニタイズ）
• CSRF保護が有効であること
• 認証/認可が検証されていること
• すべてのエンドポイントにレート制限があること
• エラーメッセージが機密データを漏洩しないこと

シークレット管理： シークレットを絶対にハードコードしない。環境変数またはシークレットマネージャーを使用する。起動時に必要なシークレットを検証する。漏洩したシークレットは直ちにローテーションする。

セキュリティ問題が見つかった場合： 停止 → security-reviewerエージェントを使用 → CRITICALな問題を修正 → 漏洩したシークレットをローテーション → 類似の問題がないかコードベースをレビュー。

コーディングスタイル

イミュータビリティ（必須）： 常に新しいオブジェクトを生成し、変更しない。変更を適用した新しいコピーを返す。

ファイル構成： 少数の大きなファイルより、多数の小さなファイルを優先。200〜400行が標準、最大800行。型ではなく機能/ドメインで整理する。高凝集、低結合。

エラーハンドリング： あらゆるレベルでエラーを処理する。UIコードではユーザーフレンドリーなメッセージを提供する。サーバーサイドでは詳細なコンテキストをログに記録する。エラーを暗黙的に握りつぶさない。

入力バリデーション： システム境界ですべてのユーザー入力を検証する。スキーマベースのバリデーションを使用する。明確なメッセージで早期に失敗させる。外部データを決して信頼しない。

コード品質チェックリスト：

• 関数は小さく（<50行）、ファイルは焦点を絞る（<800行）
• 深いネストなし（>4レベル）
• 適切なエラーハンドリング、ハードコードされた値なし
• 読みやすく、適切に命名された識別子

テスト要件

最低カバレッジ：80%

テストの種類（すべて必須）：

1. ユニットテスト — 個々の関数、ユーティリティ、コンポーネント
2. 統合テスト — APIエンドポイント、データベース操作
3. E2Eテスト — クリティカルなユーザーフロー

TDDワークフロー（必須）：

1. テストを先に書く（RED） — テストは失敗するべき
2. 最小限の実装を書く（GREEN） — テストは合格するべき
3. リファクタリング（IMPROVE） — カバレッジ80%以上を確認

失敗のトラブルシューティング：テストの分離を確認 → モックを検証 → 実装を修正（テストが間違っている場合を除き、テストではなく実装を修正）。

開発ワークフロー

1. 計画 — plannerエージェントを使用、依存関係とリスクを特定、フェーズに分割
2. TDD — tdd-guideエージェントを使用、テストを先に書く、実装、リファクタリング
3. レビュー — code-reviewerエージェントを即座に使用、CRITICAL/HIGH問題に対処
4. 知識を適切な場所に記録する
   • 個人的なデバッグメモ、好み、一時的なコンテキスト → オートメモリ
   • チーム/プロジェクトの知識（アーキテクチャ決定、API変更、ランブック） → プロジェクトの既存ドキュメント構造
   • 現在のタスクで関連するドキュメントやコードコメントが既に生成されている場合、同じ情報を別の場所に複製しない
   • 明確なプロジェクトドキュメントの場所がない場合、新しいトップレベルファイルを作成する前に確認する
5. コミット — Conventional Commits形式、包括的なPRサマリー

ワークフローサーフェスポリシー

• skills/ が正規のワークフローサーフェスです。
• 新しいワークフローの貢献はまず skills/ に配置するべきです。
• commands/ はレガシーなスラッシュエントリー互換サーフェスであり、マイグレーションまたはクロスハーネスのパリティのためにシムが必要な場合にのみ追加・更新するべきです。

Gitワークフロー

コミット形式： <type>: <description> — タイプ：feat, fix, refactor, docs, test, chore, perf, ci

PRワークフロー： 完全なコミット履歴を分析 → 包括的なサマリーを作成 → テストプランを含める → -uフラグ付きでプッシュ。

アーキテクチャパターン

APIレスポンス形式： 成功インジケーター、データペイロード、エラーメッセージ、ページネーションメタデータを含む一貫したエンベロープ。

リポジトリパターン： 標準インターフェース（findAll, findById, create, update, delete）の背後にデータアクセスをカプセル化する。ビジネスロジックはストレージメカニズムではなく、抽象インターフェースに依存する。

スケルトンプロジェクト： 実績あるテンプレートを検索し、並列エージェント（セキュリティ、拡張性、関連性）で評価し、最適なものをクローンし、実績ある構造内で反復する。

パフォーマンス

コンテキスト管理： 大規模なリファクタリングやマルチファイル機能では、コンテキストウィンドウの最後の20%を避ける。低感度のタスク（単一の編集、ドキュメント、簡単な修正）はより高い使用率を許容する。

ビルドトラブルシューティング： build-error-resolverエージェントを使用 → エラーを分析 → 段階的に修正 → 各修正後に検証。

プロジェクト構造

agents/          — 60の専門サブエージェント
skills/          — 228のワークフロースキルとドメイン知識
commands/        — 75のスラッシュコマンド
hooks/           — トリガーベースの自動化
rules/           — 常に従うべきガイドライン（共通 + 言語別）
scripts/         — クロスプラットフォームNode.jsユーティリティ
mcp-configs/     — 14のMCPサーバー設定
tests/           — テストスイート

commands/ は互換性のためにリポジトリに残っていますが、長期的な方向性はスキルファーストです。

成功指標

• すべてのテストが80%以上のカバレッジで合格
• セキュリティ脆弱性なし
• コードが読みやすく保守しやすい
• パフォーマンスが許容範囲内
• ユーザー要件が満たされている