Translate everything-claude-code repository to Japanese including: - 17 root documentation files - 60 agent documentation files - 80 command documentation files - 99 rule files across 18 language directories (common, angular, arkts, cpp, csharp, dart, fsharp, golang, java, kotlin, perl, php, python, ruby, rust, swift, typescript, web) - 199 skill documentation files Total: 455 files translated to Japanese with: - Consistent terminology glossary applied throughout - YAML field names preserved in English (name, description, etc.) - Code blocks and examples untouched (comments translated) - Markdown structure and relative links preserved - Professional translation maintaining technical accuracy This translation expands ECC accessibility to Japanese-speaking developers and teams. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
11 KiB
Everything Claude Code (ECC) — エージェント指示書
これは60の専門エージェント、228のスキル、75のコマンド、自動化フックワークフローを提供するプロダクション対応のAIコーディングプラグインです。
バージョン: 2.0.0-rc.1
コア原則
- エージェントファースト — ドメインタスクは専門エージェントに委任する
- テスト駆動 — 実装前にテストを書き、80%以上のカバレッジを必須とする
- セキュリティファースト — セキュリティに妥協せず、すべての入力を検証する
- イミュータビリティ — 常に新しいオブジェクトを生成し、既存のものを変更しない
- 実行前に計画 — 複雑な機能はコードを書く前に計画する
利用可能なエージェント
| エージェント | 目的 | 使用タイミング |
|---|---|---|
| planner | 実装計画 | 複雑な機能、リファクタリング |
| architect | システム設計とスケーラビリティ | アーキテクチャの意思決定 |
| tdd-guide | テスト駆動開発 | 新機能、バグ修正 |
| code-reviewer | コード品質と保守性 | コードの作成/変更後 |
| security-reviewer | 脆弱性検出 | コミット前、機密コード |
| build-error-resolver | ビルド/型エラーの修正 | ビルド失敗時 |
| e2e-runner | E2E Playwrightテスト | クリティカルなユーザーフロー |
| refactor-cleaner | デッドコードのクリーンアップ | コードメンテナンス |
| doc-updater | ドキュメントとコードマップ | ドキュメント更新 |
| cpp-reviewer | C/C++コードレビュー | C/C++プロジェクト |
| cpp-build-resolver | C/C++ビルドエラー | C/C++ビルド失敗 |
| fsharp-reviewer | F#関数型コードレビュー | F#プロジェクト |
| docs-lookup | Context7経由のドキュメント検索 | API/ドキュメントの質問 |
| go-reviewer | Goコードレビュー | Goプロジェクト |
| go-build-resolver | Goビルドエラー | Goビルド失敗 |
| kotlin-reviewer | Kotlinコードレビュー | Kotlin/Android/KMPプロジェクト |
| kotlin-build-resolver | Kotlin/Gradleビルドエラー | Kotlinビルド失敗 |
| database-reviewer | PostgreSQL/Supabaseスペシャリスト | スキーマ設計、クエリ最適化 |
| python-reviewer | Pythonコードレビュー | Pythonプロジェクト |
| django-reviewer | Djangoコードレビュー | Djangoアプリ、DRF API、ORM、マイグレーション |
| django-build-resolver | Djangoビルド、マイグレーション、セットアップエラー | Django起動、依存関係、マイグレーション、collectstatic失敗 |
| java-reviewer | JavaとSpring Bootコードレビュー | Java/Spring Bootプロジェクト |
| java-build-resolver | Java/Maven/Gradleビルドエラー | Javaビルド失敗 |
| loop-operator | 自律ループ実行 | ループの安全な実行、停滞の監視、介入 |
| harness-optimizer | ハーネス設定チューニング | 信頼性、コスト、スループット |
| rust-reviewer | Rustコードレビュー | Rustプロジェクト |
| rust-build-resolver | Rustビルドエラー | Rustビルド失敗 |
| pytorch-build-resolver | PyTorchランタイム/CUDA/トレーニングエラー | PyTorchビルド/トレーニング失敗 |
| mle-reviewer | 本番MLパイプラインレビュー | MLパイプライン、評価、サービング、モニタリング、ロールバック |
| typescript-reviewer | TypeScript/JavaScriptコードレビュー | TypeScript/JavaScriptプロジェクト |
エージェントオーケストレーション
ユーザーのプロンプトなしで積極的にエージェントを使用する:
- 複雑な機能リクエスト → 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%
テストの種類(すべて必須):
- ユニットテスト — 個々の関数、ユーティリティ、コンポーネント
- 統合テスト — APIエンドポイント、データベース操作
- E2Eテスト — クリティカルなユーザーフロー
TDDワークフロー(必須):
- テストを先に書く(RED) — テストは失敗するべき
- 最小限の実装を書く(GREEN) — テストは合格するべき
- リファクタリング(IMPROVE) — カバレッジ80%以上を確認
失敗のトラブルシューティング:テストの分離を確認 → モックを検証 → 実装を修正(テストが間違っている場合を除き、テストではなく実装を修正)。
開発ワークフロー
- 計画 — plannerエージェントを使用、依存関係とリスクを特定、フェーズに分割
- TDD — tdd-guideエージェントを使用、テストを先に書く、実装、リファクタリング
- レビュー — code-reviewerエージェントを即座に使用、CRITICAL/HIGH問題に対処
- 知識を適切な場所に記録する
- 個人的なデバッグメモ、好み、一時的なコンテキスト → オートメモリ
- チーム/プロジェクトの知識(アーキテクチャ決定、API変更、ランブック) → プロジェクトの既存ドキュメント構造
- 現在のタスクで関連するドキュメントやコードコメントが既に生成されている場合、同じ情報を別の場所に複製しない
- 明確なプロジェクトドキュメントの場所がない場合、新しいトップレベルファイルを作成する前に確認する
- コミット — 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%以上のカバレッジで合格
- セキュリティ脆弱性なし
- コードが読みやすく保守しやすい
- パフォーマンスが許容範囲内
- ユーザー要件が満たされている