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
description, argument-hint
| description | argument-hint |
|---|---|
| 厳密なバリデーションループを伴う実装計画の実行 | <path/to/plan.md> |
PRPs-agentic-eng(Wirasm)から適応。PRP ワークフローシリーズの一部。
PRP 実装
計画ファイルをステップごとに実行し、継続的にバリデーションを行います。すべての変更は即座に検証されます。壊れた状態を蓄積してはなりません。
基本理念: バリデーションループはミスを早期に検出します。変更のたびにチェックを実行します。問題は即座に修正します。
黄金ルール: バリデーションが失敗した場合、次に進む前に修正してください。壊れた状態を蓄積してはなりません。
フェーズ 0 — 検出
パッケージマネージャーの検出
| ファイルの存在 | パッケージマネージャー | ランナー |
|---|---|---|
bun.lockb |
bun | bun run |
pnpm-lock.yaml |
pnpm | pnpm run |
yarn.lock |
yarn | yarn |
package-lock.json |
npm | npm run |
pyproject.toml または requirements.txt |
uv / pip | uv run または python -m |
Cargo.toml |
cargo | cargo |
go.mod |
go | go |
バリデーションスクリプト
package.json(または同等のファイル)で利用可能なスクリプトを確認します:
# Node.js プロジェクトの場合
cat package.json | grep -A 20 '"scripts"'
利用可能なコマンドを確認します: 型チェック、リント、テスト、ビルド。
フェーズ 1 — 読み込み
計画ファイルを読み込みます:
cat "$ARGUMENTS"
計画から以下のセクションを抽出します:
- 概要 — 何を構築するか
- ミラーするパターン — 従うべきコード規約
- 変更対象ファイル — 作成または変更するもの
- ステップごとのタスク — 実装の順序
- バリデーションコマンド — 正しさを検証する方法
- 受け入れ基準 — 完了の定義
ファイルが存在しないか、有効な計画でない場合:
Error: Plan file not found or invalid.
Run /prp-plan <feature-description> to create a plan first.
チェックポイント: 計画を読み込み完了。すべてのセクションを特定。タスクを抽出。
フェーズ 2 — 準備
Git の状態
git branch --show-current
git status --porcelain
ブランチの判断
| 現在の状態 | アクション |
|---|---|
| フィーチャーブランチにいる | 現在のブランチを使用 |
| main にいて、ワーキングツリーがクリーン | フィーチャーブランチを作成: git checkout -b feat/{plan-name} |
| main にいて、ワーキングツリーがダーティ | 停止 — スタッシュまたはコミットを先に行うようユーザーに確認 |
| このフィーチャー用の Git ワークツリー内にいる | そのワークツリーを使用 |
リモートとの同期
git pull --rebase origin $(git branch --show-current) 2>/dev/null || true
チェックポイント: 正しいブランチにいる。ワーキングツリー準備完了。リモート同期済み。
フェーズ 3 — 実行
計画の各タスクを順番に処理します。
タスクごとのループ
ステップごとのタスクの各タスクについて:
-
MIRROR リファレンスを読む — タスクの MIRROR フィールドで参照されているパターンファイルを開きます。コードを書く前に規約を理解します。
-
実装する — パターンに正確に従ってコードを書きます。GOTCHA 警告を適用します。指定された IMPORTS を使用します。
-
即座にバリデーションする — すべてのファイル変更後に:
# 型チェックを実行(プロジェクトに応じてコマンドを調整) [type-check command from Phase 0]型チェックが失敗した場合 → 次のファイルに進む前にエラーを修正します。
-
進捗を追跡する — ログ:
[done] Task N: [task name] — complete
逸脱の処理
実装が計画から逸脱する必要がある場合:
- 何が変わったかを記録
- なぜ変わったかを記録
- 修正されたアプローチで続行
- これらの逸脱はレポートに記録されます
チェックポイント: すべてのタスクを実行完了。逸脱を記録済み。
フェーズ 4 — バリデーション
計画のすべてのバリデーションレベルを実行します。各レベルで問題を修正してから次に進みます。
レベル 1: 静的解析
# 型チェック — エラーゼロが必須
[project type-check command]
# リント — 可能な場合は自動修正
[project lint command]
[project lint-fix command]
自動修正後もリントエラーが残る場合は、手動で修正します。
レベル 2: ユニットテスト
すべての新しい関数にテストを書きます(計画のテスト戦略で指定されたとおり)。
[project test command for affected area]
- すべての関数に少なくとも1つのテストが必要
- 計画に記載されたエッジケースをカバー
- テストが失敗した場合 → 実装を修正します(テストが間違っている場合を除き、テストではなく実装を修正)
レベル 3: ビルドチェック
[project build command]
ビルドはエラーゼロで成功する必要があります。
レベル 4: 統合テスト(該当する場合)
# サーバーを起動し、テストを実行し、サーバーを停止
[project dev server command] &
SERVER_PID=$!
# サーバーの準備完了を待機(ポートは必要に応じて調整)
SERVER_READY=0
for i in $(seq 1 30); do
if curl -sf http://localhost:PORT/health >/dev/null 2>&1; then
SERVER_READY=1
break
fi
sleep 1
done
if [ "$SERVER_READY" -ne 1 ]; then
kill "$SERVER_PID" 2>/dev/null || true
echo "ERROR: Server failed to start within 30s" >&2
exit 1
fi
[integration test command]
TEST_EXIT=$?
kill "$SERVER_PID" 2>/dev/null || true
wait "$SERVER_PID" 2>/dev/null || true
exit "$TEST_EXIT"
レベル 5: エッジケーステスト
計画のテスト戦略チェックリストからエッジケースを実行します。
チェックポイント: 5つのバリデーションレベルすべてが合格。エラーゼロ。
フェーズ 5 — レポート
実装レポートの作成
mkdir -p .claude/PRPs/reports
レポートを .claude/PRPs/reports/{plan-name}-report.md に書き込みます:
# Implementation Report: [Feature Name]
## Summary
[何を実装したか]
## Assessment vs Reality
| 指標 | 予測(計画) | 実績 |
|---|---|---|
| 複雑度 | [計画から] | [実績] |
| 信頼度 | [計画から] | [実績] |
| 変更ファイル数 | [計画から] | [実際の数] |
## Tasks Completed
| # | タスク | ステータス | 備考 |
|---|---|---|---|
| 1 | [task name] | [done] Complete | |
| 2 | [task name] | [done] Complete | Deviated — [理由] |
## Validation Results
| レベル | ステータス | 備考 |
|---|---|---|
| 静的解析 | [done] Pass | |
| ユニットテスト | [done] Pass | N件のテストを作成 |
| ビルド | [done] Pass | |
| 統合 | [done] Pass | または N/A |
| エッジケース | [done] Pass | |
## Files Changed
| ファイル | アクション | 行数 |
|---|---|---|
| `path/to/file` | CREATED | +N |
| `path/to/file` | UPDATED | +N / -M |
## Deviations from Plan
[逸脱の一覧(何が、なぜ)、または「なし」]
## Issues Encountered
[発生した問題とその解決方法の一覧、または「なし」]
## Tests Written
| テストファイル | テスト数 | カバレッジ |
|---|---|---|
| `path/to/test` | N件のテスト | [カバーした領域] |
## Next Steps
- [ ] `/code-review` でコードレビュー
- [ ] `/prp-pr` でPRを作成
PRD の更新(該当する場合)
この実装が PRD フェーズの一部だった場合:
- フェーズのステータスを
in-progressからcompleteに更新 - レポートパスを参照として追加
計画のアーカイブ
mkdir -p .claude/PRPs/plans/completed
mv "$ARGUMENTS" .claude/PRPs/plans/completed/
チェックポイント: レポート作成完了。PRD 更新完了。計画をアーカイブ済み。
フェーズ 6 — 出力
ユーザーに報告します:
## 実装完了
- **計画**: [plan file path] → completed/ にアーカイブ
- **ブランチ**: [current branch name]
- **ステータス**: [done] すべてのタスク完了
### バリデーション概要
| チェック | ステータス |
|---|---|
| 型チェック | [done] |
| リント | [done] |
| テスト | [done] (N件作成) |
| ビルド | [done] |
| 統合 | [done] または N/A |
### 変更されたファイル
- [N] ファイル作成、[M] ファイル更新
### 逸脱
[概要 または「なし — 計画どおりに実装」]
### 成果物
- レポート: `.claude/PRPs/reports/{name}-report.md`
- アーカイブ済み計画: `.claude/PRPs/plans/completed/{name}.plan.md`
### PRD 進捗(該当する場合)
| フェーズ | ステータス |
|---|---|
| フェーズ 1 | [done] 完了 |
| フェーズ 2 | [next] |
| ... | ... |
> 次のステップ: `/prp-pr` でプルリクエストを作成するか、`/code-review` で先に変更をレビューしてください。
失敗時の対処
型チェックの失敗
- エラーメッセージを注意深く読む
- ソースファイルの型エラーを修正
- 型チェックを再実行
- クリーンになってから次に進む
テストの失敗
- バグが実装にあるのかテストにあるのかを特定
- 根本原因を修正(通常は実装側)
- テストを再実行
- グリーンになってから次に進む
リントの失敗
- まず自動修正を実行
- エラーが残る場合は手動で修正
- リントを再実行
- クリーンになってから次に進む
ビルドの失敗
- 通常は型またはインポートの問題 — エラーメッセージを確認
- 問題のあるファイルを修正
- ビルドを再実行
- 成功してから次に進む
統合テストの失敗
- サーバーが正しく起動したか確認
- エンドポイント/ルートが存在するか確認
- リクエスト形式が期待どおりか確認
- 修正して再実行
成功基準
- TASKS_COMPLETE: 計画のすべてのタスクを実行
- TYPES_PASS: 型エラーゼロ
- LINT_PASS: リントエラーゼロ
- TESTS_PASS: すべてのテストがグリーン、新しいテストを作成
- BUILD_PASS: ビルド成功
- REPORT_CREATED: 実装レポートを保存
- PLAN_ARCHIVED: 計画を
completed/に移動
次のステップ
/code-reviewを実行してコミット前に変更をレビュー/prp-commitを実行して説明的なメッセージでコミット/prp-prを実行してプルリクエストを作成/prp-plan <next-phase>を実行(PRD にさらにフェーズがある場合)