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>
This commit is contained in:
Claude
2026-05-16 20:12:58 +09:00
committed by Affaan Mustafa
parent b66ae3fbe0
commit ec9ace9c54
376 changed files with 48957 additions and 0 deletions

View File

@@ -0,0 +1,175 @@
---
description: 敵対的デュアルレビュー収束ループ — 2つの独立したモデルレビュアーがコード出荷前に両方とも承認する必要があります。
---
# Santa Loop
santa-methodスキルを使用した敵対的デュアルレビュー収束ループ。2つの独立したレビュアー異なるモデル、共有コンテキストなしが、コード出荷前に両方ともNICEを返す必要があります。
## 目的
現在のタスク出力に対して2つの独立したレビュアーClaude Opus + 外部モデルを実行します。コードがプッシュされる前に、両方がNICEを返す必要があります。どちらかがNAUGHTYを返した場合、フラグが立てられたすべての問題を修正し、コミットして、新しいレビュアーで再実行します最大3ラウンド
## 使い方
```
/santa-loop [file-or-glob | description]
```
## ワークフロー
### ステップ 1: レビュー対象の特定
`$ARGUMENTS` からスコープを判定するか、コミットされていない変更にフォールバックします:
```bash
git diff --name-only HEAD
```
すべての変更ファイルを読み取り、完全なレビューコンテキストを構築します。`$ARGUMENTS` がパス、ファイル、または説明を指定している場合は、それをスコープとして使用します。
### ステップ 2: ルーブリックの構築
レビュー対象のファイルタイプに適したルーブリックを構築します。すべての基準には客観的なPASS/FAIL条件が必要です。最低限以下を含めてください
| 基準 | 合格条件 |
|------|----------|
| 正確性 | ロジックが正しく、バグがなく、エッジケースを処理している |
| セキュリティ | シークレット、インジェクション、XSS、OWASP Top 10の問題がない |
| エラーハンドリング | エラーが明示的に処理され、暗黙的な無視がない |
| 完全性 | すべての要件が対処され、欠落ケースがない |
| 内部一貫性 | ファイル間またはセクション間の矛盾がない |
| リグレッションなし | 変更が既存の動作を壊さない |
ファイルタイプに基づいてドメイン固有の基準を追加しますTSの型安全性、Rustのメモリ安全性、SQLのマイグレーション安全性
### ステップ 3: デュアル独立レビュー
Agentツールを使用して2つのレビュアーを**並列で**起動します同時実行のために両方を1つのメッセージで起動。判定ゲートに進む前に、両方が完了する必要があります。
各レビュアーはすべてのルーブリック基準をPASSまたはFAILとして評価し、構造化されたJSONを返します
```json
{
"verdict": "PASS" | "FAIL",
"checks": [
{"criterion": "...", "result": "PASS|FAIL", "detail": "..."}
],
"critical_issues": ["..."],
"suggestions": ["..."]
}
```
判定ゲート(ステップ 4はこれらをNICE/NAUGHTYにマッピングします両方PASS → NICE、どちらかFAIL → NAUGHTY。
#### レビュアー A: Claudeエージェント常に実行
完全なルーブリック + レビュー対象のすべてのファイルを持つエージェントsubagent_type: `code-reviewer`、model: `opus`)を起動します。プロンプトには以下を含める必要があります:
- 完全なルーブリック
- レビュー対象のすべてのファイル内容
- 「あなたは独立した品質レビュアーです。他のレビューは見ていません。あなたの仕事は問題を見つけることであり、承認することではありません。」
- 上記の構造化されたJSON判定を返すこと
#### レビュアー B: 外部モデル外部CLIがインストールされていない場合のみClaudeフォールバック
まず、利用可能なCLIを検出します
```bash
command -v codex >/dev/null 2>&1 && echo "codex" || true
command -v gemini >/dev/null 2>&1 && echo "gemini" || true
```
レビュアープロンプト(レビュアー Aと同一のルーブリック + 指示)を構築し、一意の一時ファイルに書き込みます:
```bash
PROMPT_FILE=$(mktemp /tmp/santa-reviewer-b-XXXXXX.txt)
cat > "$PROMPT_FILE" << 'EOF'
... 完全なルーブリック + ファイル内容 + レビュアー指示 ...
EOF
```
最初に利用可能なCLIを使用します
**Codex CLI**(インストールされている場合)
```bash
codex exec --sandbox read-only -m gpt-5.4 -C "$(pwd)" - < "$PROMPT_FILE"
rm -f "$PROMPT_FILE"
```
**Gemini CLI**インストールされていてcodexがない場合
```bash
gemini -p "$(cat "$PROMPT_FILE")" -m gemini-2.5-pro
rm -f "$PROMPT_FILE"
```
**Claudeエージェントフォールバック**`codex``gemini`もインストールされていない場合のみ)
2番目のClaudeエージェントsubagent_type: `code-reviewer`、model: `opus`)を起動します。両方のレビュアーが同じモデルファミリーを共有しているため、真のモデル多様性は達成されなかったが、コンテキスト分離は引き続き適用される旨の警告をログに記録します。
すべての場合において、レビュアーはレビュアー Aと同じ構造化されたJSON判定を返す必要があります。
### ステップ 4: 判定ゲート
- **両方PASS** → **NICE** — ステップ 6プッシュに進む
- **どちらかFAIL** → **NAUGHTY** — 両方のレビュアーからのすべてのクリティカルな問題をマージし、重複を排除し、ステップ 5に進む
### ステップ 5: 修正サイクルNAUGHTYパス
1. 両方のレビュアーからのすべてのクリティカルな問題を表示する
2. フラグが立てられたすべての問題を修正する — フラグが立てられたものだけを変更し、ついでのリファクタリングはしない
3. すべての修正を1つのコミットにまとめる
```
fix: address santa-loop review findings (round N)
```
4. **新しいレビュアー**でステップ 3を再実行する前のラウンドの記憶なし
5. 両方がPASSを返すまで繰り返す
**最大3イテレーション。** 3ラウンド後もNAUGHTYの場合、停止して残りの問題を提示します
```
SANTA LOOP ESCALATION (exceeded 3 iterations)
3ラウンド後の残存問題
- [両方のレビュアーからの未解決のクリティカルな問題をすべてリスト]
続行する前に手動レビューが必要です。
```
プッシュしないでください。
### ステップ 6: プッシュNICEパス
両方のレビュアーがPASSを返した場合
```bash
git push -u origin HEAD
```
### ステップ 7: 最終レポート
出力レポートを表示します(下記の出力セクションを参照)。
## 出力
```
SANTA VERDICT: [NICE / NAUGHTY (escalated)]
Reviewer A (Claude Opus): [PASS/FAIL]
Reviewer B ([model used]): [PASS/FAIL]
Agreement:
Both flagged: [両方が検出した問題]
Reviewer A only: [Aのみが検出した問題]
Reviewer B only: [Bのみが検出した問題]
Iterations: [N]/3
Result: [PUSHED / ESCALATED TO USER]
```
## 注意事項
- レビュアー AClaude Opusは常に実行されます — ツール環境に関係なく、少なくとも1つの強力なレビュアーが保証されます。
- レビュアー Bの目標はモデル多様性です。GPT-5.4またはGemini 2.5 Proは真の独立性を提供します — 異なる学習データ、異なるバイアス、異なる死角。Claudeのみのフォールバックでもコンテキスト分離による価値はありますが、モデル多様性は失われます。
- 利用可能な最も強力なモデルが使用されます:レビュアー AにはOpus、レビュアー BにはGPT-5.4またはGemini 2.5 Pro。
- 外部レビュアーはレビュー中のリポジトリ変更を防ぐため、`--sandbox read-only`Codexで実行されます。
- 各ラウンドで新しいレビュアーを使用することで、以前の発見に対するアンカリングバイアスを防ぎます。
- ルーブリックは最も重要な入力です。レビュアーがゴム印承認をしたり、主観的なスタイルの問題をフラグに立てる場合は、ルーブリックを厳格化してください。
- NAUGHTYラウンドでコミットが行われるため、ループが中断されても修正は保持されます。
- プッシュはNICE後にのみ発生します — ループ中には決して行われません。