Claude ec9ace9c54 docs: add native Japanese translation of ECC documentation (ja-JP)
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>
2026-05-17 02:31:40 -04:00

11 KiB
Raw Blame History

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

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

バージョン: 2.0.0-rc.1

コア原則

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

利用可能なエージェント

エージェント 目的 使用タイミング
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%

テストの種類(すべて必須):

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