zsp/everything-claude-code
1
0
Fork 0
mirror of https://github.com/affaan-m/everything-claude-code.git synced 2026-05-18 14:53:05 +08:00
Code Issues Packages Projects Releases Wiki Activity

docs: add native Japanese translation of ECC documentation (ja-JP)

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files

166
docs/ja-JP/commands/aside.md Normal file
View File

@@ -0,0 +1,166 @@
---
description: 現在のタスクを中断せずにサイドの質問にすばやく回答します。回答後は自動的に作業を再開します。
---
# Asideコマンド
タスク中に質問をして即座に集中した回答を受け取り、中断した場所から作業を続行します。現在のタスク、ファイル、コンテキストは一切変更されません。
## 使用するタイミング
- Claudeが作業中に気になることがあり、勢いを失いたくない場合
- Claudeが現在編集しているコードのクイック説明が必要な場合
- タスクを脱線させずに判断のセカンドオピニオンや確認が必要な場合
- Claudeが続行する前にエラー、概念、パターンを理解したい場合
- 現在のタスクと無関係なことを新しいセッションを開始せずに質問したい場合
## 使い方
```
/aside <質問>
/aside この関数は実際に何を返す？
/aside このパターンはスレッドセーフ？
/aside なぜここでYの代わりにXを使っている？
/aside foo()とbar()の違いは？
/aside 追加したN+1クエリは心配すべき？
```
## プロセス
### ステップ1: 現在のタスク状態をフリーズ
回答する前に、以下を確認:
- アクティブなタスクは何か？（どのファイル、機能、問題に取り組んでいたか）
- `/aside`が呼び出された時点でどのステップが進行中だったか？
- 次に何が行われる予定だったか？
aside中はファイルの編集、作成、削除を一切行わない。
### ステップ2: 質問に直接回答
完全で有用でありながら最も簡潔な形式で回答する。
- 推論ではなく回答から始める
- 短く保つ — 詳細な説明が必要な場合は、タスク後に掘り下げることを提案
- 現在作業中のファイルやコードについての質問の場合、正確に参照（関連する場合はファイルパスと行番号）
- 回答にファイル読み取りが必要な場合、読み取る — ただし読み取り専用、書き込みは絶対にしない
レスポンスのフォーマット:
```
ASIDE: [質問を簡潔に再表現]
[回答]
— タスクに戻る: [行っていた作業の一行説明]
```
### ステップ3: メインタスクを再開
回答を提供した後、即座にアクティブなタスクを一時停止した正確なポイントから続行する。asideの回答がブロッカーや現在のアプローチを再考する理由を明らかにしない限り、再開の許可を求めない（エッジケースを参照）。
---
## エッジケース
**質問が提供されない（`/aside`のみ）:**
応答:
```
ASIDE: 質問が提供されていません
何を知りたいですか？（質問してください。現在のタスクコンテキストを失わずに回答します）
— タスクに戻る: [行っていた作業の一行説明]
```
**質問が現在のタスクの潜在的な問題を明らかにする:**
再開前に明確にフラグを立てる:
```
ASIDE: [回答]
WARNING: この回答は現在のアプローチに[問題]があることを示唆しています。続行する前にこれに対処しますか、それとも予定通り進めますか？
```
再開前にユーザーの判断を待つ。
**質問が実際にはタスクのリダイレクト（サイドの質問ではない）:**
質問が構築中のものを変更することを意味する場合（例: `/aside 実は、代わりにRedisを使おう`）、確認:
```
ASIDE: それはサイドの質問ではなく、方向転換のようです。
どうしますか:
(a) 情報としてのみ回答し、現在の計画を維持
(b) 現在のタスクを一時停止してアプローチを変更
```
ユーザーの回答を待つ — 仮定を立てない。
**現在開いているファイルやコードについての質問:**
ライブコンテキストから回答する。ファイルがセッション中に既に読み取られている場合、直接参照する。そうでない場合、今読み取り（読み取り専用）、file:line参照で回答する。
**アクティブなタスクがない（`/aside`呼び出し時に進行中のものがない）:**
レスポンスの形状を一貫させるため、標準ラッパーを使用:
```
ASIDE: [質問を簡潔に再表現]
[回答]
— タスクに戻る: 再開するアクティブなタスクなし
```
**長い回答が必要な質問:**
本質的な回答を簡潔に述べ、次に提案:
```
以上が短いバージョンです。[現在のタスク]を終えた後、より詳しい説明が必要ですか？
```
**連続した複数の`/aside`質問:**
それぞれ順番に回答する。最後の回答の後、メインタスクを再開する。一連のaside全体でタスク状態を失わない。
**asideの回答がコード変更が必要であることを示す:**
必要な変更を記録するが、aside中は実行しない:
```
ASIDE: [回答]
修正すべき点: [変更内容]。現在のタスク後にフラグを立てますが、今対処したい場合はお知らせください。
```
**質問が曖昧または漠然としすぎる:**
1つの明確化質問をする — 回答に必要な情報を得るための最短の質問。複数の質問はしない。
---
## 出力例
```
User: /aside fetchWithRetry()は実際に何をする？
ASIDE: fetchWithRetry()は何をする？
fetchWithRetry() (src/api/retry.ts:12) はリクエストを指数バックオフ
（250ms → 500ms → 1s）で最大3回試行します。5xxレスポンスと
ネットワークエラーのみリトライし、4xxエラーは最終的なものとして
リトライしません。
— タスクに戻る: src/middleware/auth.tsの認証ミドルウェアのリファクタリング
```
```
User: /aside 現在取っているアプローチはスレッドセーフ？
ASIDE: 現在のアプローチはスレッドセーフ？
いいえ — src/cache/store.ts:34の共有キャッシュオブジェクトがロックなしで
変更されています。並行リクエスト下ではこれは競合状態です。
シングルプロセスのNode.jsサーバーではリスクは低いですが、ワーカースレッドや
クラスタリングでは実際の問題になります。
WARNING: これは構築中の機能に影響する可能性があります。今対処しますか、それとも続行してフォローアップで修正しますか？
```
---
## ノート
- aside中はファイルを変更しない — 読み取り専用アクセスのみ
- asideは会話の一時停止であり、新しいタスクではない — 元のタスクは必ず再開しなければならない
- 回答は焦点を絞る: 目標はユーザーのブロックをすばやく解除すること、講義を行うことではない
- asideがより大きな議論を引き起こす場合、asideがブロッカーを明らかにしない限り、現在のタスクを先に終了する
- asideはタスク結果に明示的に関連しない限り、セッションファイルに保存されない

28
docs/ja-JP/commands/auto-update.md Normal file
View File

@@ -0,0 +1,28 @@
---
description: 最新のECCリポジトリ変更をプルし、現在の管理対象ターゲットを再インストールします。
disable-model-invocation: true
---
# 自動更新
ECCをアップストリームリポジトリから更新し、元のインストール状態リクエストを使用して現在のコンテキストの管理対象インストールを再生成します。
## 使い方
```bash
# 何も変更せずに更新をプレビュー
ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();console.log(r)")}"
node "$ECC_ROOT/scripts/auto-update.js" --dry-run
# 現在のプロジェクトのCursor管理ファイルのみ更新
node "$ECC_ROOT/scripts/auto-update.js" --target cursor
# ECCリポジトリルートを明示的に上書き
node "$ECC_ROOT/scripts/auto-update.js" --repo-root /path/to/everything-claude-code
```
## ノート
- このコマンドは記録されたインストール状態リクエストを使用し、最新のリポジトリ変更をプルした後に`install-apply.js`を再実行します。
- 再インストールは意図的です: `repair.js`が古い操作から安全に再構築できないアップストリームの名前変更や削除を処理します。
- 何も変更する前に再構築された再インストール計画を確認したい場合は、先に`--dry-run`を使用してください。

99
docs/ja-JP/commands/cost-report.md Normal file
View File

@@ -0,0 +1,99 @@
---
description: コストトラッカーSQLiteデータベースからローカルClaude Codeコストレポートを生成します。
argument-hint: [csv]
---
# コストレポート
ローカルのコスト追跡データベースにクエリを実行し、日別、プロジェクト別、ツール別、セッション別の支出レポートを表示します。このコマンドは、コスト追跡フックまたはプラグインが既に`~/.claude-cost-tracker/usage.db`に使用行を書き込んでいることを前提としています。
## このコマンドの動作
1. `sqlite3`が利用可能か確認する。
2. `~/.claude-cost-tracker/usage.db`が存在するか確認する。
3. `usage`テーブルに対して集計クエリを実行する。
4. コンパクトなレポートを表示するか、引数が`csv`の場合は最近の行をCSVとしてエクスポートする。
## 前提条件
データベースはローカルのコストトラッカーによって入力されている必要があります。ファイルが存在しない場合、トラッカーがセットアップされていないことをユーザーに伝え、信頼できるClaude Codeコスト追跡フック/プラグインのインストールまたは有効化を先に提案します。
```bash
test -f ~/.claude-cost-tracker/usage.db && echo "Database found" || echo "Database not found"
```
## サマリークエリ
```bash
sqlite3 -header -column ~/.claude-cost-tracker/usage.db "
SELECT
ROUND(COALESCE(SUM(CASE WHEN date(timestamp) = date('now') THEN cost_usd END), 0), 4) AS today_cost,
ROUND(COALESCE(SUM(CASE WHEN date(timestamp) = date('now', '-1 day') THEN cost_usd END), 0), 4) AS yesterday_cost,
ROUND(COALESCE(SUM(cost_usd), 0), 4) AS total_cost,
COUNT(*) AS total_calls,
COUNT(DISTINCT session_id) AS sessions
FROM usage;
"
```
## プロジェクト別内訳
```bash
sqlite3 -header -column ~/.claude-cost-tracker/usage.db "
SELECT project, ROUND(SUM(cost_usd), 4) AS cost, COUNT(*) AS calls
FROM usage
GROUP BY project
ORDER BY cost DESC;
"
```
## ツール別内訳
```bash
sqlite3 -header -column ~/.claude-cost-tracker/usage.db "
SELECT tool_name, ROUND(SUM(cost_usd), 4) AS cost, COUNT(*) AS calls
FROM usage
GROUP BY tool_name
ORDER BY cost DESC;
"
```
## 直近7日間
```bash
sqlite3 -header -column ~/.claude-cost-tracker/usage.db "
SELECT date(timestamp) AS date, ROUND(SUM(cost_usd), 4) AS cost, COUNT(*) AS calls
FROM usage
GROUP BY date(timestamp)
ORDER BY date DESC
LIMIT 7;
"
```
## CSVエクスポート
ユーザーが`/cost-report csv`を要求した場合、明示的なカラムリストで最新の使用行をエクスポート:
```bash
sqlite3 -csv -header ~/.claude-cost-tracker/usage.db "
SELECT timestamp, project, tool_name, input_tokens, output_tokens, cost_usd, session_id, model
FROM usage
ORDER BY timestamp DESC
LIMIT 100;
"
```
## レポートフォーマット
レスポンスを以下のフォーマットで整形:
1. サマリー: 今日、昨日、合計、呼び出し回数、セッション数。
2. プロジェクト別: 合計コスト順にランク付けされたプロジェクト。
3. ツール別: 合計コスト順にランク付けされたツール。
4. 直近7日間: 日付、コスト、呼び出し回数。
1ドル未満の金額は小数点以下4桁を使用する。このコマンドでは生のトークンから料金を見積もらない。トラッカーが書き込んだ事前計算済みの`cost_usd`値に依存する。
## ソース
`MayurBhavsar`氏の古いコミュニティPR #1304から復活。

78
docs/ja-JP/commands/cpp-build.md Normal file
View File

@@ -0,0 +1,78 @@
---
description: C++ビルドエラー、CMakeの問題、リンカーの問題をインクリメンタルに修正します。最小限の外科的修正のためにcpp-build-resolverエージェントを呼び出します。
---
# C++ビルドと修正
このコマンドは**cpp-build-resolver**エージェントを呼び出し、C++ビルドエラーを最小限の変更でインクリメンタルに修正します。
## このコマンドの動作
1. **診断を実行**: `cmake --build`、`clang-tidy`、`cppcheck`を実行
2. **エラーを解析**: ファイルごとにグループ化し、重大度でソート
3. **インクリメンタルに修正**: 一度に1つのエラー
4. **各修正を検証**: 各変更後にビルドを再実行
5. **サマリーを報告**: 修正されたものと残りを表示
## 使用するタイミング
`/cpp-build`を使用するのは:
- `cmake --build build`がエラーで失敗する場合
- リンカーエラー（未定義参照、多重定義）
- テンプレートインスタンシエーションの失敗
- インクルード/依存関係の問題
- ビルドを壊す変更をプルした後
## 実行される診断コマンド
```bash
# CMake設定
cmake -B build -S .
# ビルド
cmake --build build 2>&1 | head -100
# 静的解析（利用可能な場合）
clang-tidy src/*.cpp -- -std=c++17
cppcheck --enable=all src/
```
## 一般的に修正されるエラー
| エラー | 典型的な修正 |
|--------|------------|
| `undeclared identifier` | `#include`を追加またはタイプミスを修正 |
| `no matching function` | 引数の型を修正またはオーバーロードを追加 |
| `undefined reference` | ライブラリをリンクまたは実装を追加 |
| `multiple definition` | `inline`を使用または.cppに移動 |
| `incomplete type` | 前方宣言を`#include`に置換 |
| `no member named X` | メンバー名を修正またはinclude |
| `cannot convert X to Y` | 適切なキャストを追加 |
| `CMake Error` | CMakeLists.txt設定を修正 |
## 修正戦略
1. **コンパイルエラーを最初に** — コードがコンパイルできなければならない
2. **リンカーエラーを次に** — 未定義参照を解決
3. **警告を3番目に** — `-Wall -Wextra`で修正
4. **一度に1つの修正** — 各変更を検証
5. **最小限の変更** — リファクタリングせず、修正のみ
## 停止条件
エージェントは以下の場合に停止して報告する:
- 3回の試行後も同じエラーが持続
- 修正がより多くのエラーを導入
- アーキテクチャ変更が必要
- 外部依存関係が不足
## 関連コマンド
- `/cpp-test` — ビルド成功後にテストを実行
- `/cpp-review` — コード品質をレビュー
- `verification-loop`スキル — 完全な検証ループ
## 関連
- エージェント: `agents/cpp-build-resolver.md`
- スキル: `skills/cpp-coding-standards/`

82
docs/ja-JP/commands/cpp-review.md Normal file
View File

@@ -0,0 +1,82 @@
---
description: メモリ安全性、モダンC++イディオム、並行性、セキュリティの包括的C++コードレビュー。cpp-reviewerエージェントを呼び出します。
---
# C++コードレビュー
このコマンドは**cpp-reviewer**エージェントを呼び出し、C++固有の包括的なコードレビューを行います。
## このコマンドの動作
1. **C++の変更を特定**: `git diff`で変更された`.cpp`、`.hpp`、`.cc`、`.h`ファイルを検索
2. **静的解析を実行**: `clang-tidy`と`cppcheck`を実行
3. **メモリ安全性スキャン**: 生のnew/delete、バッファオーバーフロー、use-after-freeをチェック
4. **並行性レビュー**: スレッド安全性、mutex使用、データ競合を分析
5. **モダンC++チェック**: コードがC++17/20の規約とベストプラクティスに従っているか検証
6. **レポート生成**: 問題を重大度別に分類
## 使用するタイミング
`/cpp-review`を使用するのは:
- C++コードを書いたり修正した後
- C++の変更をコミットする前
- C++コードを含むプルリクエストをレビューする時
- 新しいC++コードベースにオンボーディングする時
- メモリ安全性の問題をチェックする時
## レビューカテゴリ
### CRITICAL（修正必須）
- RAIIなしの生の`new`/`delete`
- バッファオーバーフローとuse-after-free
- 同期なしのデータ競合
- `system()`によるコマンドインジェクション
- 未初期化変数の読み取り
- ヌルポインタデリファレンス
### HIGH（修正すべき）
- Rule of Five違反
- `std::lock_guard` / `std::scoped_lock`の欠如
- 適切なライフタイム管理なしのデタッチされたスレッド
- `static_cast`/`dynamic_cast`の代わりのCスタイルキャスト
- `const`正確性の欠如
### MEDIUM（検討）
- 不要なコピー（`const&`の代わりに値渡し）
- 既知のサイズのコンテナでの`reserve()`の欠如
- ヘッダでの`using namespace std;`
- 重要な戻り値での`[[nodiscard]]`の欠如
- 過度に複雑なテンプレートメタプログラミング
## 実行される自動チェック
```bash
# 静的解析
clang-tidy --checks='*,-llvmlibc-*' src/*.cpp -- -std=c++17
# 追加分析
cppcheck --enable=all --suppress=missingIncludeSystem src/
# 警告付きビルド
cmake --build build -- -Wall -Wextra -Wpedantic
```
## 承認基準
| ステータス | 条件 |
|-----------|------|
| 承認 | CRITICALまたはHIGHの問題なし |
| 警告 | MEDIUMの問題のみ（注意してマージ） |
| ブロック | CRITICALまたはHIGHの問題あり |
## 他のコマンドとの統合
- テストが通ることを確認するためにまず`/cpp-test`を使用
- ビルドエラーが発生した場合は`/cpp-build`を使用
- コミット前に`/cpp-review`を使用
- C++固有でない懸念には`/code-review`を使用
## 関連
- エージェント: `agents/cpp-reviewer.md`
- スキル: `skills/cpp-coding-standards/`、`skills/cpp-testing/`

128
docs/ja-JP/commands/cpp-test.md Normal file
View File

@@ -0,0 +1,128 @@
---
description: C++のTDDワークフローを強制します。最初にGoogleTestテストを書き、その後実装します。gcov/lcovでカバレッジを検証します。
---
# C++ TDDコマンド
このコマンドはCMake/CTestとGoogleTest/GoogleMockを使用したC++コードのテスト駆動開発方法論を強制します。
## このコマンドの動作
1. **インターフェース定義**: クラス/関数のシグネチャを先にスキャフォールド
2. **テストを書く**: 包括的なGoogleTestテストケースを作成（RED）
3. **テストを実行**: テストが正しい理由で失敗することを検証
4. **コードを実装**: テストを通す最小限のコードを書く（GREEN）
5. **リファクタリング**: テストをグリーンに保ちながら改善
6. **カバレッジをチェック**: 80%以上のカバレッジを確保
## 使用するタイミング
`/cpp-test`を使用するのは:
- 新しいC++の関数やクラスを実装する時
- 既存コードにテストカバレッジを追加する時
- バグを修正する時（失敗するテストを最初に書く）
- 重要なビジネスロジックを構築する時
- C++でTDDワークフローを学ぶ時
## TDDサイクル
```
RED → 失敗するGoogleTestテストを書く
GREEN → テストを通す最小限のコードを実装
REFACTOR → コードを改善、テストはグリーンのまま
REPEAT → 次のテストケースへ
```
## テストパターン
### 基本テスト
```cpp
TEST(SuiteName, TestName) {
EXPECT_EQ(add(2, 3), 5);
EXPECT_NE(result, nullptr);
EXPECT_TRUE(is_valid);
EXPECT_THROW(func(), std::invalid_argument);
}
```
### フィクスチャ
```cpp
class DatabaseTest : public ::testing::Test {
protected:
void SetUp() override { db_ = create_test_db(); }
void TearDown() override { db_.reset(); }
std::unique_ptr<Database> db_;
};
TEST_F(DatabaseTest, InsertsRecord) {
db_->insert("key", "value");
EXPECT_EQ(db_->get("key"), "value");
}
```
### パラメータ化テスト
```cpp
class PrimeTest : public ::testing::TestWithParam<std::pair<int, bool>> {};
TEST_P(PrimeTest, ChecksPrimality) {
auto [input, expected] = GetParam();
EXPECT_EQ(is_prime(input), expected);
}
INSTANTIATE_TEST_SUITE_P(Primes, PrimeTest, ::testing::Values(
std::make_pair(2, true),
std::make_pair(4, false),
std::make_pair(7, true)
));
```
## カバレッジコマンド
```bash
# カバレッジ付きビルド
cmake -DCMAKE_CXX_FLAGS="--coverage" -DCMAKE_EXE_LINKER_FLAGS="--coverage" -B build
# テスト実行
cmake --build build && ctest --test-dir build
# カバレッジレポート生成
lcov --capture --directory build --output-file coverage.info
lcov --remove coverage.info '/usr/*' --output-file coverage.info
genhtml coverage.info --output-directory coverage_html
```
## カバレッジ目標
| コードの種類 | 目標 |
|-------------|------|
| 重要なビジネスロジック | 100% |
| パブリックAPI | 90%以上 |
| 一般コード | 80%以上 |
| 生成コード | 除外 |
## TDDベストプラクティス
**すべきこと:**
- 実装の前にテストを先に書く
- 各変更後にテストを実行
- 適切な場合は`ASSERT_*`（停止）より`EXPECT_*`（続行）を使用
- 実装の詳細ではなく動作をテスト
- エッジケースを含める（空、null、最大値、境界条件）
**すべきでないこと:**
- テストの前に実装を書く
- RED段階をスキップ
- プライベートメソッドを直接テスト（パブリックAPIを通じてテスト）
- テストで`sleep`を使用
- フレイキーなテストを無視
## 関連コマンド
- `/cpp-build` — ビルドエラーを修正
- `/cpp-review` — 実装後にコードをレビュー
- `verification-loop`スキル — 完全な検証ループを実行
## 関連
- スキル: `skills/cpp-testing/`
- スキル: `skills/tdd-workflow/`

93
docs/ja-JP/commands/ecc-guide.md Normal file
View File

@@ -0,0 +1,93 @@
---
description: ECCの現在のエージェント、スキル、コマンド、フック、インストールプロファイル、ドキュメントをライブリポジトリサーフェスからナビゲートします。
---
# /ecc-guide
このコマンドをEverything Claude Codeの会話型マップとして使用します。完全なREADMEや古いカタログ数をダンプすることなく、タスクに適したECCサーフェスをユーザーが発見するのを支援します。
## 使い方
```text
/ecc-guide
/ecc-guide setup
/ecc-guide skills
/ecc-guide commands
/ecc-guide hooks
/ecc-guide install
/ecc-guide find: <クエリ>
/ecc-guide <機能名またはファイル名>
```
## 動作ルール
1. チェックアウトが利用可能な場合は、回答前に現在のリポジトリファイルを読む。
2. ハードコードされたカウントよりも現在のファイルシステム/カタログデータを優先する。
3. 最初の回答は短く、その後具体的なドリルダウンパスを提示する。
4. 長いセクションをコピーする代わりに、標準ファイルへのリンクをユーザーに提示する。
5. 存在しないコマンド、スキル、エージェント、インストールプロファイルを作り出さない。
## 検査対象
以下のファイルを標準マップとして使用:
- `README.md` — インストールパス、リセット/アンインストールガイダンス、高レベルの位置づけ
- `AGENTS.md` — コントリビューターとプロジェクト構造のガイダンス
- `agent.yaml` — エクスポートされたエージェントとコマンドサーフェス
- `commands/` — メンテナンスされたスラッシュコマンドシム
- `skills/*/SKILL.md` — 再利用可能なスキルワークフロー
- `agents/*.md` — 委任されたエージェントの役割
- `hooks/README.md`と`hooks/hooks.json` — フックの動作
- `manifests/install-*.json` — 選択的インストールモジュール、コンポーネント、プロファイル
- `scripts/ci/catalog.js --json` — ECC内で実行時のライブカタログカウント
## レスポンスパターン
### 引数なし
コンパクトなメニューを提示:
- セットアップとインストール
- スキルの選択
- コマンド互換性シム
- エージェントと委任
- フックと安全性
- インストールのトラブルシューティング
- 特定の機能の検索
次に何をしたいか尋ねる。
### トピック検索
`skills`、`commands`、`hooks`、`install`、`agents`などのトピックの場合:
1. 現在のサーフェスを3-6箇条書きでサマリー。
2. 標準ディレクトリ/ファイルを指す。
3. 状態を検証できるコマンドを1-2つ提案。
4. ユーザーが要求しない限り、網羅的なリストを避ける。
### 検索モード
`find: <クエリ>`の場合:
1. `rg`で関連ファイルを検索。
2. 結果をサーフェスごとにグループ化: スキル、コマンド、エージェント、ルール、ドキュメント、フック。
3. 最も強いマッチをファイルパス付きで最初に返す。
4. 各マッチの次のアクションを推奨。
### 機能検索
特定の機能名の場合:
1. まず正確なパスをチェック: `skills/<name>/SKILL.md`、`commands/<name>.md`、`agents/<name>.md`。
2. 正確な検索が失敗した場合、`rg`で検索。
3. 機能の動作、使用タイミング、標準ファイルを説明。
4. 混乱を減らす場合にのみ隣接機能に言及。
## 関連コマンド
- `/project-init` — スタック対応のECCオンボーディング
- `/harness-audit` — 決定論的リポジトリ準備度スコアリング
- `/skill-health` — スキル品質チェック
- `/skill-create` — ローカルgit履歴からの新しいスキル抽出
- `/security-scan` — Claude/OpenCode設定のセキュリティレビュー

39
docs/ja-JP/commands/fastapi-review.md Normal file
View File

@@ -0,0 +1,39 @@
---
description: FastAPIアプリケーションのアーキテクチャ、async正確性、依存性注入、Pydanticスキーマ、セキュリティ、パフォーマンス、テスト可能性をレビューします。
---
# FastAPIレビュー
`fastapi-reviewer`エージェントを呼び出して、焦点を絞ったFastAPIレビューを実行します。
## 使い方
```text
/fastapi-review [ファイルまたはディレクトリ]
```
## レビュー領域
- アプリファクトリ、ルーター境界、ミドルウェア、例外ハンドラ。
- Pydanticのリクエストとレスポンススキーマの分離。
- データベースセッション、認証、ページネーション、設定の依存性注入。
- 非同期データベースと外部HTTPパターン。
- CORS、認証、レート制限、ロギング、シークレット処理。
- OpenAPIメタデータとドキュメント化されたレスポンスモデル。
- テストクライアントセットアップと依存関係のオーバーライド。
## 期待される出力
```text
[SEVERITY] 問題の短いタイトル
File: path/to/file.py:42
Issue: 何が問題でなぜ重要か。
Fix: 実施すべき具体的な変更。
```
## 関連
- エージェント: `fastapi-reviewer`
- スキル: `fastapi-patterns`
- コマンド: `/python-review`
- スキル: `security-scan`

49
docs/ja-JP/commands/feature-dev.md Normal file
View File

@@ -0,0 +1,49 @@
---
description: コードベースの理解とアーキテクチャに焦点を当てたガイド付き機能開発
---
既存コードの理解を新しいコードの作成より重視する、構造化された機能開発ワークフロー。
## フェーズ
### 1. ディスカバリー
- 機能リクエストを注意深く読む
- 要件、制約、受け入れ基準を特定する
- リクエストが曖昧な場合は明確化の質問をする
### 2. コードベース探索
- `code-explorer`を使用して関連する既存コードを分析する
- 実行パスとアーキテクチャレイヤーを追跡する
- 統合ポイントと規約を理解する
### 3. 明確化の質問
- 探索からの所見を提示する
- ターゲットを絞った設計とエッジケースの質問をする
- 続行する前にユーザーのレスポンスを待つ
### 4. アーキテクチャ設計
- `code-architect`を使用して機能を設計する
- 実装のブループリントを提供する
- 実装前に承認を待つ
### 5. 実装
- 承認された設計に従って機能を実装する
- 適切な場合はTDDを優先する
- コミットを小さく焦点を絞ったものにする
### 6. 品質レビュー
- `code-reviewer`を使用して実装をレビューする
- CRITICALおよび重要な問題に対処する
- テストカバレッジを検証する
### 7. サマリー
- 構築したものをサマリーする
- フォローアップ項目や制限を一覧する
- テスト手順を提供する

79
docs/ja-JP/commands/flutter-build.md Normal file
View File

@@ -0,0 +1,79 @@
---
description: Dartアナライザーエラーとflutterビルドの障害をインクリメンタルに修正します。最小限の外科的修正のためにdart-build-resolverエージェントを呼び出します。
---
# Flutterビルドと修正
このコマンドは**dart-build-resolver**エージェントを呼び出し、Dart/Flutterビルドエラーを最小限の変更でインクリメンタルに修正します。
## このコマンドの動作
1. **診断を実行**: `flutter analyze`、`flutter pub get`を実行
2. **エラーを解析**: ファイルごとにグループ化し、重大度でソート
3. **インクリメンタルに修正**: 一度に1つのエラー
4. **各修正を検証**: 各変更後に分析を再実行
5. **サマリーを報告**: 修正されたものと残りを表示
## 使用するタイミング
`/flutter-build`を使用するのは:
- `flutter analyze`がエラーを報告する場合
- いずれかのプラットフォームで`flutter build`が失敗する場合
- `dart pub get` / `flutter pub get`がバージョン競合で失敗する場合
- `build_runner`がコード生成に失敗する場合
- ビルドを壊す変更をプルした後
## 実行される診断コマンド
```bash
# 分析
flutter analyze 2>&1
# 依存関係
flutter pub get 2>&1
# コード生成（プロジェクトがbuild_runnerを使用する場合）
dart run build_runner build --delete-conflicting-outputs 2>&1
# プラットフォームビルド
flutter build apk 2>&1
flutter build web 2>&1
```
## 一般的に修正されるエラー
| エラー | 典型的な修正 |
|--------|------------|
| `A value of type 'X?' can't be assigned to 'X'` | `?? default`またはnullガードを追加 |
| `The name 'X' isn't defined` | importを追加またはタイプミスを修正 |
| `Non-nullable instance field must be initialized` | 初期化子または`late`を追加 |
| `Version solving failed` | pubspec.yamlのバージョン制約を調整 |
| `Missing concrete implementation of 'X'` | 欠落したインターフェースメソッドを実装 |
| `build_runner: Part of X expected` | 古い`.g.dart`を削除して再ビルド |
## 修正戦略
1. **分析エラーを最初に** — コードがエラーフリーでなければならない
2. **警告のトリアージを次に** — ランタイムバグを引き起こす可能性のある警告を修正
3. **pub競合を3番目に** — 依存関係の解決を修正
4. **一度に1つの修正** — 各変更を検証
5. **最小限の変更** — リファクタリングせず、修正のみ
## 停止条件
エージェントは以下の場合に停止して報告する:
- 3回の試行後も同じエラーが持続
- 修正がより多くのエラーを導入
- アーキテクチャ変更が必要
- パッケージアップグレード競合にユーザー判断が必要
## 関連コマンド
- `/flutter-test` — ビルド成功後にテストを実行
- `/flutter-review` — コード品質をレビュー
- `verification-loop`スキル — 完全な検証ループ
## 関連
- エージェント: `agents/dart-build-resolver.md`
- スキル: `skills/flutter-dart-code-review/`

116
docs/ja-JP/commands/flutter-review.md Normal file
View File

@@ -0,0 +1,116 @@
---
description: Flutter/Dartコードのイディオムパターン、ウィジェットのベストプラクティス、状態管理、パフォーマンス、アクセシビリティ、セキュリティをレビューします。flutter-reviewerエージェントを呼び出します。
---
# Flutterコードレビュー
このコマンドは**flutter-reviewer**エージェントを呼び出し、Flutter/Dartコードの変更をレビューします。
## このコマンドの動作
1. **コンテキストを収集**: `git diff --staged`と`git diff`をレビュー
2. **プロジェクトを調査**: `pubspec.yaml`、`analysis_options.yaml`、状態管理ソリューションを確認
3. **セキュリティ事前スキャン**: ハードコードされたシークレットと重大なセキュリティ問題を確認
4. **フルレビュー**: 完全なレビューチェックリストを適用
5. **所見を報告**: 重大度別にグループ化された問題を修正ガイダンス付きで出力
## 前提条件
`/flutter-review`を実行する前に、以下を確認してください:
1. **ビルドが通る** — まず`/flutter-build`を実行。壊れたコードのレビューは不完全です
2. **テストが通る** — `/flutter-test`を実行してリグレッションがないことを確認
3. **マージコンフリクトがない** — すべてのコンフリクトを解決し、diffが意図的な変更のみを反映するようにする
4. **`flutter analyze`がクリーン** — レビュー前にアナライザーの警告を修正
## 使用するタイミング
`/flutter-review`を使用するのは:
- Flutter/Dartの変更を含むPRを提出する前（ビルドとテストが通った後）
- 新機能を実装した後に問題を早期に発見するため
- 他の人のFlutterコードをレビューする時
- ウィジェット、状態管理コンポーネント、またはサービスクラスを監査する時
- プロダクションリリースの前
## レビュー領域
| 領域 | 重大度 |
|------|--------|
| ハードコードされたシークレット、平文HTTP | CRITICAL |
| アーキテクチャ違反、状態管理アンチパターン | CRITICAL |
| ウィジェットの再ビルド問題、リソースリーク | HIGH |
| `dispose()`の欠落、await後の`BuildContext` | HIGH |
| Dartのnullセーフティ、エラー/ローディング状態の欠落 | HIGH |
| Const伝搬、ウィジェットのコンポジション | HIGH |
| パフォーマンス: `build()`内の高コストな処理 | HIGH |
| アクセシビリティ、セマンティックラベル | MEDIUM |
| 状態遷移のテスト欠落 | HIGH |
| ハードコードされた文字列（l10n） | MEDIUM |
| Pub依存関係の衛生管理 | LOW |
## セッション例
````text
User: /flutter-review
Agent:
# Flutterコードレビュー
## コンテキスト
変更されたファイル:
- lib/features/auth/presentation/login_page.dart
- lib/features/auth/data/auth_repository_impl.dart
状態管理: Riverpod（pubspec.yamlから検出）
アーキテクチャ: feature-first
## セキュリティ事前スキャン
✓ ハードコードされたシークレットは検出されませんでした
✓ 平文HTTPコールはありません
## レビュー所見
[HIGH] 非同期ギャップ後にmountedチェックなしでBuildContextを使用
File: lib/features/auth/presentation/login_page.dart:67
Issue: `context.go('/home')`が`await auth.login(...)`の後に`mounted`チェックなしで呼び出されている。
Fix: await後のナビゲーション前に`if (!context.mounted) return;`を追加（Flutter 3.7+）。
[HIGH] AsyncValueのエラー状態が未処理
File: lib/features/auth/presentation/login_page.dart:42
Issue: `ref.watch(authProvider)`がloading/dataでswitchしているが、`error`ブランチがない。
Fix: switch式または`when()`コールにerrorケースを追加してユーザー向けエラーメッセージを表示。
[MEDIUM] ハードコードされた文字列がローカライズされていない
File: lib/features/auth/presentation/login_page.dart:89
Issue: `Text('Login')` — ユーザーに表示される文字列がローカライゼーションシステムを使用していない。
Fix: プロジェクトのl10nアクセサを使用: `Text(context.l10n.loginButton)`。
## レビューサマリー
| 重大度 | 件数 | ステータス |
|--------|------|-----------|
| CRITICAL | 0 | pass |
| HIGH | 2 | block |
| MEDIUM | 1 | info |
| LOW | 0 | note |
判定: BLOCK — HIGH問題はマージ前に修正が必要です。
````
## 承認基準
- **承認**: CRITICALまたはHIGHの問題がない
- **ブロック**: CRITICALまたはHIGHの問題はマージ前に修正が必要
## 関連コマンド
- `/flutter-build` — まずビルドエラーを修正
- `/flutter-test` — レビュー前にテストを実行
- `/code-review` — 一般的なコードレビュー（言語非依存）
## 関連
- エージェント: `agents/flutter-reviewer.md`
- スキル: `skills/flutter-dart-code-review/`
- ルール: `rules/dart/`

144
docs/ja-JP/commands/flutter-test.md Normal file
View File

@@ -0,0 +1,144 @@
---
description: Flutter/Dartテストを実行し、失敗を報告し、テスト問題をインクリメンタルに修正します。ユニット、ウィジェット、ゴールデン、統合テストをカバーします。
---
# Flutterテスト
このコマンドはFlutterテストスイートを実行し、結果を報告します。失敗が発生した場合、問題を診断しインクリメンタルに修正します。
## このコマンドの動作
1. **テスト実行**: `flutter test`を実行（または変更されたファイルにスコープを限定）
2. **失敗を解析**: タイプと原因別に失敗するテストを特定
3. **インクリメンタルに修正**: 可能な場合は一度に1つの失敗
4. **検証**: 各修正後に再実行
5. **報告**: カバレッジサマリーと残りの失敗を表示
## 使用するタイミング
`/flutter-test`を使用するのは:
- 機能を実装した後に何も壊れていないことを確認するため
- `/flutter-build`実行後にテストが通ることを確認するため
- 新しいコードのテストカバレッジを確認するため
- 特定のテストファイルが失敗している時
- PRを提出する前
## 実行されるコマンド
```bash
# すべてのテストを実行
flutter test 2>&1
# カバレッジ付きで実行
flutter test --coverage 2>&1
# 特定のテストファイルを実行
flutter test test/unit/domain/usecases/get_user_test.dart 2>&1
# 名前パターンに一致するテストを実行
flutter test --name "CartBloc" 2>&1
# 統合テストを実行（デバイス/エミュレーターが必要）
flutter test integration_test/ 2>&1
# 意図的なビジュアル変更時にゴールデンファイルを更新
flutter test --update-goldens 2>&1
```
## セッション例
````text
User: /flutter-test
Agent:
# Flutterテスト実行
## テスト実行
```
$ flutter test
00:05 +42 -2: Some tests failed.
FAILED: test/unit/data/user_repository_test.dart
UserRepository getById
returns null when user not found
Expected: null
Actual: User(id: 'test-id', name: 'Test User')
FAILED: test/widget/cart_page_test.dart
CartPage
shows empty state when cart is empty
Expected: exactly one widget with text 'Your cart is empty'
Found: no widget with text 'Your cart is empty'
```
## 修正 1: リポジトリテスト
File: test/unit/data/user_repository_test.dart
失敗: `getById`が欠落IDに対してnullを返すべきところでユーザーを返す
根本原因: テストセットアップがID 'test-id' のユーザーを追加するが、'missing-id' でクエリしている。
修正: 'missing-id' でクエリするようテストを更新 — セットアップは正しく、クエリが間違っていた。
```
$ flutter test test/unit/data/user_repository_test.dart
1 test passed.
```
## 修正 2: ウィジェットテスト
File: test/widget/cart_page_test.dart
失敗: 空状態のテキストウィジェットが見つからない
根本原因: 空状態メッセージがウィジェット内で 'Your cart is empty' から 'Cart is empty' に変更されていた。
修正: 現在のウィジェットのコピーに合わせてテスト文字列を更新。
```
$ flutter test test/widget/cart_page_test.dart
1 test passed.
```
## 最終実行
```
$ flutter test --coverage
All 44 tests passed.
Coverage: 84.2% (target: 80%)
```
## サマリー
| メトリクス | 値 |
|-----------|-----|
| 総テスト数 | 44 |
| 成功 | 44 |
| 失敗 | 0 |
| カバレッジ | 84.2% |
テストステータス: PASS ✓
````
## 一般的なテスト失敗
| 失敗 | 典型的な修正 |
|------|-------------|
| `Expected: <X> Actual: <Y>` | アサーションを更新するか実装を修正 |
| `Widget not found` | ファインダーセレクタを修正するかウィジェット名変更後にテストを更新 |
| `Golden file not found` | `flutter test --update-goldens`を実行して生成 |
| `Golden mismatch` | 差分を検査し、変更が意図的なら`--update-goldens`を実行 |
| `MissingPluginException` | テストセットアップでプラットフォームチャネルをモック |
| `LateInitializationError` | `setUp()`で`late`フィールドを初期化 |
| `pumpAndSettle timed out` | 明示的な`pump(Duration)`コールに置き換え |
## 関連コマンド
- `/flutter-build` — テスト実行前にビルドエラーを修正
- `/flutter-review` — テスト通過後にコードをレビュー
- `tdd-workflow`スキル — テスト駆動開発ワークフロー
## 関連
- エージェント: `agents/flutter-reviewer.md`
- エージェント: `agents/dart-build-resolver.md`
- スキル: `skills/flutter-dart-code-review/`
- ルール: `rules/dart/testing.md`

103
docs/ja-JP/commands/gan-build.md Normal file
View File

@@ -0,0 +1,103 @@
---
description: 実装タスクに対して、制限付きイテレーションとスコアリングによるジェネレーター/エバリュエータービルドループを実行します。
---
$ARGUMENTSから以下を解析:
1. `brief` — 何をビルドするかのユーザーの一行説明
2. `--max-iterations N` — （オプション、デフォルト15）ジェネレーター-エバリュエーターサイクルの最大回数
3. `--pass-threshold N` — （オプション、デフォルト7.0）合格するための重み付きスコア
4. `--skip-planner` — （オプション）プランナーをスキップし、spec.mdが既に存在すると想定
5. `--eval-mode MODE` — （オプション、デフォルト"playwright"）次のいずれか: playwright, screenshot, code-only
## GANスタイルハーネスビルド
このコマンドは、Anthropicの2026年3月のハーネス設計論文に触発された3エージェントビルドループをオーケストレーションします。
### フェーズ 0: セットアップ
1. プロジェクトルートに`gan-harness/`ディレクトリを作成
2. サブディレクトリを作成: `gan-harness/feedback/`、`gan-harness/screenshots/`
3. gitが未初期化なら初期化
4. 開始時刻と設定をログ
### フェーズ 1: プランニング（プランナーエージェント）
`--skip-planner`が設定されていない場合:
1. ユーザーのブリーフでTaskツール経由で`gan-planner`エージェントを起動
2. `gan-harness/spec.md`と`gan-harness/eval-rubric.md`の生成を待機
3. 仕様のサマリーをユーザーに表示
4. フェーズ 2に進む
### フェーズ 2: ジェネレーター-エバリュエーターループ
```
iteration = 1
while iteration <= max_iterations:
# 生成
Taskツール経由でgan-generatorエージェントを起動:
- spec.mdを読む
- iteration > 1の場合: feedback/feedback-{iteration-1}.mdを読む
- アプリケーションをビルド/改善
- devサーバーが実行中であることを確認
- 変更をコミット
# ジェネレーターの完了を待機
# 評価
Taskツール経由でgan-evaluatorエージェントを起動:
- eval-rubric.mdとspec.mdを読む
- ライブアプリケーションをテスト（モード: playwright/screenshot/code-only）
- ルーブリックに対してスコアリング
- feedback/feedback-{iteration}.mdにフィードバックを書き込み
# エバリュエーターの完了を待機
# スコアチェック
feedback/feedback-{iteration}.mdを読む
重み付き合計スコアを抽出
if score >= pass_threshold:
"イテレーション {iteration} でスコア {score} で合格" をログ
中断
if iteration >= 3 and 直近2イテレーションでスコアが改善していない:
"プラトー検出 — 早期停止" をログ
中断
iteration += 1
```
### フェーズ 3: サマリー
1. すべてのフィードバックファイルを読む
2. 最終スコアとイテレーション履歴を表示
3. スコア推移を表示: `iteration 1: 4.2 → iteration 2: 5.8 → ... → iteration N: 7.5`
4. 最終評価からの残りの問題を一覧
5. 合計時間と推定コストを報告
### 出力
```markdown
## GANハーネスビルドレポート
**ブリーフ:** [元のプロンプト]
**結果:** PASS/FAIL
**イテレーション:** N / max
**最終スコア:** X.X / 10
### スコア推移
| Iter | Design | Originality | Craft | Functionality | Total |
|------|--------|-------------|-------|---------------|-------|
| 1 | ... | ... | ... | ... | X.X |
| 2 | ... | ... | ... | ... | X.X |
| N | ... | ... | ... | ... | X.X |
### 残りの問題
- [最終評価からの問題]
### 作成されたファイル
- gan-harness/spec.md
- gan-harness/eval-rubric.md
- gan-harness/feedback/feedback-001.md ～ feedback-NNN.md
- gan-harness/generator-state.md
- gan-harness/build-report.md
```
完全なレポートを`gan-harness/build-report.md`に書き込みます。

39
docs/ja-JP/commands/gan-design.md Normal file
View File

@@ -0,0 +1,39 @@
---
description: フロントエンドまたはビジュアル作業に対して、制限付きイテレーションとスコアリングによるジェネレーター/エバリュエーターデザインループを実行します。
---
$ARGUMENTSから以下を解析:
1. `brief` — 作成するデザインのユーザーの説明
2. `--max-iterations N` — （オプション、デフォルト10）デザイン-評価サイクルの最大回数
3. `--pass-threshold N` — （オプション、デフォルト7.5）合格するための重み付きスコア（デザイン向けにデフォルトが高い）
## GANスタイルデザインハーネス
フロントエンドのデザイン品質に特化した2エージェントループ（ジェネレーター + エバリュエーター）。プランナーなし — ブリーフが仕様そのものです。
これはAnthropicがフロントエンドデザイン実験で使用したのと同じモードで、CSSパースペクティブとドアウェイナビゲーションによる3Dオランダ美術館のようなクリエイティブなブレイクスルーが見られました。
### セットアップ
1. `gan-harness/`ディレクトリを作成
2. ブリーフを直接`gan-harness/spec.md`として書き込み
3. Design QualityとOriginalityに追加の重みを付けたデザイン特化の`gan-harness/eval-rubric.md`を書き込み
### デザイン特化の評価ルーブリック
```markdown
### Design Quality（重み: 0.35）
### Originality（重み: 0.30）
### Craft（重み: 0.25）
### Functionality（重み: 0.10）
```
注: Originalityの重みが高め（0.30 vs 0.20）で、クリエイティブなブレイクスルーを促進します。Functionalityの重みが低いのは、デザインモードがビジュアル品質に焦点を当てるためです。
### ループ
`/project:gan-build`のフェーズ 2と同じですが、以下が異なります:
- プランナーをスキップ
- デザイン特化のルーブリックを使用
- ジェネレータープロンプトが機能の完全性よりビジュアル品質を強調
- エバリュエータープロンプトが「すべての機能が動くか？」より「デザイン賞を受賞できるか？」を強調
### gan-buildとの主な違い
ジェネレーターには次のように指示されます:「あなたの最優先目標はビジュアルの卓越性です。機能的だが見た目の悪いアプリよりも、見事だが半完成のアプリが勝ります。クリエイティブな飛躍を追求してください — 型破りなレイアウト、カスタムアニメーション、独特なカラーワーク。」

70
docs/ja-JP/commands/gradle-build.md Normal file
View File

@@ -0,0 +1,70 @@
---
description: AndroidおよびKMPプロジェクトのGradleビルドエラーを修正します
---
# Gradleビルド修正
AndroidおよびKotlin Multiplatformプロジェクトのgradleビルドおよびコンパイルエラーをインクリメンタルに修正します。
## ステップ 1: ビルド設定の検出
プロジェクトタイプを特定し、適切なビルドを実行:
| インジケーター | ビルドコマンド |
|--------------|--------------|
| `build.gradle.kts` + `composeApp/`（KMP） | `./gradlew composeApp:compileKotlinMetadata 2>&1` |
| `build.gradle.kts` + `app/`（Android） | `./gradlew app:compileDebugKotlin 2>&1` |
| モジュール付き`settings.gradle.kts` | `./gradlew assemble 2>&1` |
| Detekt設定済み | `./gradlew detekt 2>&1` |
`gradle.properties`と`local.properties`の設定も確認します。
## ステップ 2: エラーの解析とグループ化
1. ビルドコマンドを実行し出力をキャプチャ
2. Kotlinコンパイルエラーとgradle設定エラーを分離
3. モジュールとファイルパスでグループ化
4. ソート: 設定エラーを最初に、次に依存関係順でコンパイルエラー
## ステップ 3: 修正ループ
各エラーに対して:
1. **ファイルを読む** — エラー行周辺の完全なコンテキスト
2. **診断** — 一般的なカテゴリ:
- importの欠落または未解決の参照
- 型の不一致または非互換な型
- `build.gradle.kts`内の依存関係の欠落
- Expect/actualの不一致（KMP）
- Composeコンパイラエラー
3. **最小限の修正** — エラーを解決する最小の変更
4. **ビルドを再実行** — 修正を検証し新しいエラーを確認
5. **続行** — 次のエラーへ
## ステップ 4: ガードレール
以下の場合はユーザーに停止して確認:
- 修正が解決するより多くのエラーを導入
- 3回の試行後も同じエラーが持続
- エラーが新しい依存関係の追加やモジュール構造の変更を必要とする
- Gradle sync自体が失敗（設定フェーズエラー）
- エラーが生成コード内にある（Room、SQLDelight、KSP）
## ステップ 5: サマリー
報告内容:
- 修正されたエラー（モジュール、ファイル、説明）
- 残りのエラー
- 導入された新しいエラー（ゼロであるべき）
- 推奨される次のステップ
## 一般的なGradle/KMP修正
| エラー | 修正 |
|--------|------|
| `commonMain`内の未解決の参照 | 依存関係が`commonMain.dependencies {}`にあるか確認 |
| actualなしのExpect宣言 | 各プラットフォームソースセットに`actual`実装を追加 |
| Composeコンパイラバージョンの不一致 | `libs.versions.toml`でKotlinとComposeコンパイラバージョンを揃える |
| 重複クラス | `./gradlew dependencies`で競合する依存関係を確認 |
| KSPエラー | `./gradlew kspCommonMainKotlinMetadata`を実行して再生成 |
| 設定キャッシュの問題 | シリアライズ不可能なタスク入力を確認 |

77
docs/ja-JP/commands/harness-audit.md Normal file
View File

@@ -0,0 +1,77 @@
---
description: 決定論的なリポジトリハーネス監査を実行し、優先順位付きスコアカードを返します。
---
# ハーネス監査コマンド
決定論的なリポジトリハーネス監査を実行し、優先順位付きスコアカードを返します。
## 使い方
`/harness-audit [scope] [--format text|json] [--root path]`
- `scope`（オプション）: `repo`（デフォルト）、`hooks`、`skills`、`commands`、`agents`
- `--format`: 出力スタイル（`text`がデフォルト、自動化には`json`）
- `--root`: 現在の作業ディレクトリの代わりに特定のパスを監査
## 決定論的エンジン
常に実行:
```bash
node scripts/harness-audit.js <scope> --format <text|json> [--root <path>]
```
このスクリプトがスコアリングとチェックの信頼できるソースです。追加のディメンションやアドホックなポイントを作り出さないでください。
ルーブリックバージョン: `2026-03-30`。
スクリプトは7つの固定カテゴリ（各`0-10`正規化）を計算:
1. ツールカバレッジ
2. コンテキスト効率
3. 品質ゲート
4. メモリ永続性
5. 評価カバレッジ
6. セキュリティガードレール
7. コスト効率
スコアは明示的なファイル/ルールチェックから導出され、同じコミットに対して再現可能です。
スクリプトはデフォルトで現在の作業ディレクトリを監査し、対象がECCリポジトリ自体か、ECCを使用するコンシューマプロジェクトかを自動検出します。
## 出力契約
返却内容:
1. `overall_score` / `max_score`（`repo`の場合70、スコープ付き監査ではより小さい）
2. カテゴリスコアと具体的な所見
3. 正確なファイルパス付きの失敗チェック
4. 決定論的出力からのトップ3アクション（`top_actions`）
5. 次に適用すべき推奨ECCスキル
## チェックリスト
- スクリプト出力を直接使用。手動で再スコアリングしない。
- `--format json`が要求された場合、スクリプトJSONをそのまま返す。
- テキストが要求された場合、失敗チェックとトップアクションをサマリー。
- `checks[]`と`top_actions[]`からの正確なファイルパスを含める。
## 結果の例
```text
Harness Audit (repo): 66/70
- Tool Coverage: 10/10 (10/10 pts)
- Context Efficiency: 9/10 (9/10 pts)
- Quality Gates: 10/10 (10/10 pts)
Top 3 Actions:
1) [Security Guardrails] hooks/hooks.jsonにプロンプト/ツールプリフライトセキュリティガードを追加。(hooks/hooks.json)
2) [Tool Coverage] commands/harness-audit.mdと.opencode/commands/harness-audit.mdを同期。(.opencode/commands/harness-audit.md)
3) [Eval Coverage] scripts/hooks/lib全体の自動テストカバレッジを増加。(tests/)
```
## 引数
$ARGUMENTS:
- `repo|hooks|skills|commands|agents`（オプションのスコープ）
- `--format text|json`（オプションの出力形式）

14
docs/ja-JP/commands/hookify-configure.md Normal file
View File

@@ -0,0 +1,14 @@
---
description: hookifyルールをインタラクティブに有効化または無効化します
---
既存のhookifyルールをインタラクティブに有効化または無効化します。
## ステップ
1. すべての`.claude/hookify.*.local.md`ファイルを検索
2. 各ルールの現在の状態を読み取り
3. 現在の有効/無効ステータス付きでリストを提示
4. どのルールを切り替えるか質問
5. 選択されたルールファイルの`enabled:`フィールドを更新
6. 変更を確認

46
docs/ja-JP/commands/hookify-help.md Normal file
View File

@@ -0,0 +1,46 @@
---
description: hookifyシステムのヘルプを取得します
---
hookifyの包括的なドキュメントを表示します。
## フックシステムの概要
Hookifyは、望ましくない動作を防ぐために、Claude Codeのフックシステムと統合するルールファイルを作成します。
### イベントタイプ
- `bash`: Bashツール使用時にトリガーし、コマンドパターンにマッチ
- `file`: Write/Editツール使用時にトリガーし、ファイルパスにマッチ
- `stop`: セッション終了時にトリガー
- `prompt`: ユーザーメッセージ送信時にトリガーし、入力パターンにマッチ
- `all`: すべてのイベントでトリガー
### ルールファイル形式
ファイルは`.claude/hookify.{name}.local.md`として保存:
```yaml
---
name: descriptive-name
enabled: true
event: bash|file|stop|prompt|all
action: block|warn
pattern: "マッチする正規表現パターン"
---
ルールがトリガーされた時に表示されるメッセージ。
複数行をサポートします。
```
### コマンド
- `/hookify [説明]` 新しいルールを作成し、説明がない場合は会話を自動分析
- `/hookify-list` 設定済みルールを一覧表示
- `/hookify-configure` ルールのオン/オフを切り替え
### パターンのヒント
- 正規表現構文を使用
- `bash`の場合、完全なコマンド文字列に対してマッチ
- `file`の場合、ファイルパスに対してマッチ
- デプロイ前にパターンをテスト

21
docs/ja-JP/commands/hookify-list.md Normal file
View File

@@ -0,0 +1,21 @@
---
description: 設定済みのすべてのhookifyルールを一覧表示します
---
すべてのhookifyルールを検索し、フォーマットされたテーブルで表示します。
## ステップ
1. すべての`.claude/hookify.*.local.md`ファイルを検索
2. 各ファイルのフロントマターを読み取り:
- `name`
- `enabled`
- `event`
- `action`
- `pattern`
3. テーブルとして表示:
| ルール | 有効 | イベント | パターン | ファイル |
|--------|------|---------|---------|---------|
4. ルール数を表示し、`/hookify-configure`で後から状態を変更できることを通知。

50
docs/ja-JP/commands/hookify.md Normal file
View File

@@ -0,0 +1,50 @@
---
description: 会話分析または明示的な指示から、望ましくない動作を防ぐフックを作成します
---
会話パターンの分析またはユーザーの明示的な指示により、望ましくないClaude Codeの動作を防ぐフックルールを作成します。
## 使い方
`/hookify [防止したい動作の説明]`
引数が提供されない場合、現在の会話を分析して防止すべき動作を検出します。
## ワークフロー
### ステップ 1: 動作情報の収集
- 引数あり: ユーザーの望ましくない動作の説明を解析
- 引数なし: `conversation-analyzer`エージェントを使用して以下を検出:
- 明示的な修正
- 繰り返されるミスへのフラストレーション反応
- 取り消された変更
- 繰り返される類似の問題
### ステップ 2: 所見の提示
ユーザーに以下を表示:
- 動作の説明
- 提案されるイベントタイプ
- 提案されるパターンまたはマッチャー
- 提案されるアクション
### ステップ 3: ルールファイルの生成
承認された各ルールに対して、`.claude/hookify.{name}.local.md`にファイルを作成:
```yaml
---
name: rule-name
enabled: true
event: bash|file|stop|prompt|all
action: block|warn
pattern: "regex pattern"
---
ルールがトリガーされた時に表示されるメッセージ。
```
### ステップ 4: 確認
作成されたルールと、`/hookify-list`および`/hookify-configure`での管理方法を報告します。

106
docs/ja-JP/commands/jira.md Normal file
View File

@@ -0,0 +1,106 @@
---
description: Jiraチケットを取得し、要件を分析し、ステータスを更新し、コメントを追加します。jira-integrationスキルとMCPまたはREST APIを使用します。
---
# Jiraコマンド
ワークフローから直接Jiraチケットと対話 — チケットの取得、要件の分析、コメントの追加、ステータスの遷移。
## 使い方
```
/jira get <TICKET-KEY> # チケットを取得して分析
/jira comment <TICKET-KEY> # 進捗コメントを追加
/jira transition <TICKET-KEY> # チケットステータスを変更
/jira search <JQL> # JQLでイシューを検索
```
## このコマンドの動作
1. **取得と分析** — Jiraチケットを取得し、要件、受け入れ基準、テストシナリオ、依存関係を抽出
2. **コメント** — チケットに構造化された進捗更新を追加
3. **遷移** — ワークフローステート間でチケットを移動（To Do → In Progress → Done）
4. **検索** — JQLクエリを使用してイシューを検索
## 動作方法
### `/jira get <TICKET-KEY>`
1. Jiraからチケットを取得（MCP `jira_get_issue`またはREST API経由）
2. すべてのフィールドを抽出: サマリー、説明、受け入れ基準、優先度、ラベル、リンクされたイシュー
3. オプションで追加コンテキスト用にコメントを取得
4. 構造化された分析を出力:
```
Ticket: PROJ-1234
Summary: [タイトル]
Status: [ステータス]
Priority: [優先度]
Type: [Story/Bug/Task]
Requirements:
1. [抽出された要件]
2. [抽出された要件]
Acceptance Criteria:
- [ ] [チケットからの基準]
Test Scenarios:
- Happy Path: [説明]
- Error Case: [説明]
- Edge Case: [説明]
Dependencies:
- [リンクされたイシュー、API、サービス]
Recommended Next Steps:
- /plan で実装計画を作成
- `tdd-workflow` スキルでテストファーストで実装
```
### `/jira comment <TICKET-KEY>`
1. 現在のセッションの進捗をサマリー（何をビルド、テスト、コミットしたか）
2. 構造化されたコメントとしてフォーマット
3. Jiraチケットに投稿
### `/jira transition <TICKET-KEY>`
1. チケットの利用可能な遷移を取得
2. ユーザーにオプションを表示
3. 選択された遷移を実行
### `/jira search <JQL>`
1. Jiraに対してJQLクエリを実行
2. マッチするイシューのサマリーテーブルを返す
## 前提条件
このコマンドにはJiraの認証情報が必要です。以下のいずれかを選択:
**オプション A — MCPサーバー（推奨）:**
`mcpServers`設定に`jira`を追加（テンプレートは`mcp-configs/mcp-servers.json`を参照）。
**オプション B — 環境変数:**
```bash
export JIRA_URL="https://yourorg.atlassian.net"
export JIRA_EMAIL="your.email@example.com"
export JIRA_API_TOKEN="your-api-token"
```
認証情報が見つからない場合は、停止してユーザーにセットアップを案内します。
## 他のコマンドとの統合
チケットの分析後:
- `/plan`を使用して要件から実装計画を作成
- `tdd-workflow`スキルでテスト駆動開発で実装
- 実装後に`/code-review`を使用
- `/jira comment`で進捗をチケットに投稿
- 作業完了時に`/jira transition`でチケットを移動
## 関連
- **スキル:** `skills/jira-integration/`
- **MCP設定:** `mcp-configs/mcp-servers.json` → `jira`

174
docs/ja-JP/commands/kotlin-build.md Normal file
View File

@@ -0,0 +1,174 @@
---
description: Kotlin/Gradleビルドエラー、コンパイラ警告、依存関係の問題をインクリメンタルに修正します。最小限の外科的修正のためにkotlin-build-resolverエージェントを呼び出します。
---
# Kotlinビルドと修正
このコマンドは**kotlin-build-resolver**エージェントを呼び出し、Kotlinビルドエラーを最小限の変更でインクリメンタルに修正します。
## このコマンドの動作
1. **診断を実行**: `./gradlew build`、`detekt`、`ktlintCheck`を実行
2. **エラーを解析**: ファイルごとにグループ化し、重大度でソート
3. **インクリメンタルに修正**: 一度に1つのエラー
4. **各修正を検証**: 各変更後にビルドを再実行
5. **サマリーを報告**: 修正されたものと残りを表示
## 使用するタイミング
`/kotlin-build`を使用するのは:
- `./gradlew build`がエラーで失敗する場合
- Kotlinコンパイラがエラーを報告する場合
- `./gradlew detekt`が違反を報告する場合
- Gradle依存関係の解決が失敗する場合
- ビルドを壊す変更をプルした後
## 実行される診断コマンド
```bash
# プライマリビルドチェック
./gradlew build 2>&1
# 静的解析
./gradlew detekt 2>&1 || echo "detekt not configured"
./gradlew ktlintCheck 2>&1 || echo "ktlint not configured"
# 依存関係の問題
./gradlew dependencies --configuration runtimeClasspath 2>&1 | head -100
# キャッシュや依存関係メタデータが疑わしい場合のオプションの深いリフレッシュ
./gradlew build --refresh-dependencies
```
## セッション例
````text
User: /kotlin-build
Agent:
# Kotlinビルド解決
## 初期診断
```bash
$ ./gradlew build
e: src/main/kotlin/com/example/service/UserService.kt:25:15 Unresolved reference: UserRepository
e: src/main/kotlin/com/example/routes/UserRoutes.kt:42:9 Type mismatch: inferred type is String but Int was expected
e: src/main/kotlin/com/example/routes/UserRoutes.kt:58:5 'when' expression must be exhaustive
```
検出されたエラー: 3
## 修正 1: 未解決の参照
File: src/main/kotlin/com/example/service/UserService.kt:25
Error: Unresolved reference: UserRepository
Cause: importの欠落
```kotlin
// importを追加
import com.example.repository.UserRepository
```
```bash
$ ./gradlew build
# 残りエラー: 2
```
## 修正 2: 型の不一致
File: src/main/kotlin/com/example/routes/UserRoutes.kt:42
Error: Type mismatch: inferred type is String but Int was expected
```kotlin
// 変更前
val count = call.parameters["count"]
// 変更後
val count = call.parameters["count"]?.toIntOrNull()
?: return@get call.respond(HttpStatusCode.BadRequest, "Invalid count")
```
```bash
$ ./gradlew build
# 残りエラー: 1
```
## 修正 3: 非網羅的なWhen
File: src/main/kotlin/com/example/routes/UserRoutes.kt:58
Error: 'when' expression must be exhaustive
```kotlin
// 欠落ブランチを追加
when (user.role) {
Role.ADMIN -> handleAdmin(user)
Role.USER -> handleUser(user)
Role.MODERATOR -> handleModerator(user) // 追加
}
```
```bash
$ ./gradlew build
# ビルド成功！
```
## 最終検証
```bash
$ ./gradlew detekt
# 問題なし
$ ./gradlew test
# 全テスト通過
```
## サマリー
| メトリクス | 件数 |
|-----------|------|
| 修正されたビルドエラー | 3 |
| 修正されたDetekt問題 | 0 |
| 変更されたファイル | 2 |
| 残りの問題 | 0 |
ビルドステータス: PASS: SUCCESS
````
## 一般的に修正されるエラー
| エラー | 典型的な修正 |
|--------|-------------|
| `Unresolved reference: X` | importまたは依存関係を追加 |
| `Type mismatch` | 型変換または代入を修正 |
| `'when' must be exhaustive` | 欠落したsealedクラスのブランチを追加 |
| `Suspend function can only be called from coroutine` | `suspend`修飾子を追加 |
| `Smart cast impossible` | ローカル`val`または`let`を使用 |
| `None of the following candidates is applicable` | 引数の型を修正 |
| `Could not resolve dependency` | バージョンを修正またはリポジトリを追加 |
## 修正戦略
1. **ビルドエラーを最初に** — コードがコンパイルされなければならない
2. **Detekt違反を次に** — コード品質の問題を修正
3. **ktlint警告を3番目に** — フォーマットを修正
4. **一度に1つの修正** — 各変更を検証
5. **最小限の変更** — リファクタリングせず、修正のみ
## 停止条件
エージェントは以下の場合に停止して報告する:
- 3回の試行後も同じエラーが持続
- 修正がより多くのエラーを導入
- アーキテクチャ変更が必要
- 外部依存関係が不足
## 関連コマンド
- `/kotlin-test` — ビルド成功後にテストを実行
- `/kotlin-review` — コード品質をレビュー
- `verification-loop`スキル — 完全な検証ループ
## 関連
- エージェント: `agents/kotlin-build-resolver.md`
- スキル: `skills/kotlin-patterns/`

140
docs/ja-JP/commands/kotlin-review.md Normal file
View File

@@ -0,0 +1,140 @@
---
description: Kotlinコードのイディオムパターン、nullセーフティ、コルーチンの安全性、セキュリティに関する包括的なコードレビュー。kotlin-reviewerエージェントを呼び出します。
---
# Kotlinコードレビュー
このコマンドは**kotlin-reviewer**エージェントを呼び出し、Kotlin固有の包括的なコードレビューを行います。
## このコマンドの動作
1. **Kotlinの変更を特定**: `git diff`で変更された`.kt`と`.kts`ファイルを検出
2. **ビルドと静的解析を実行**: `./gradlew build`、`detekt`、`ktlintCheck`を実行
3. **セキュリティスキャン**: SQLインジェクション、コマンドインジェクション、ハードコードされたシークレットを確認
4. **Nullセーフティレビュー**: `!!`の使用、プラットフォーム型の処理、安全でないキャストを分析
5. **コルーチンレビュー**: 構造化された並行性、ディスパッチャーの使用、キャンセレーションを確認
6. **レポートを生成**: 重大度別に問題を分類
## 使用するタイミング
`/kotlin-review`を使用するのは:
- Kotlinコードを書いたり変更した後
- Kotlinの変更をコミットする前
- Kotlinコードを含むプルリクエストをレビューする時
- 新しいKotlinコードベースにオンボーディングする時
- イディオマティックなKotlinパターンを学ぶ時
## レビューカテゴリ
### CRITICAL（修正必須）
- SQL/コマンドインジェクション脆弱性
- 正当化なしの強制アンラップ`!!`
- プラットフォーム型のnullセーフティ違反
- GlobalScopeの使用（構造化された並行性の違反）
- ハードコードされた認証情報
- 安全でないデシリアライゼーション
### HIGH（修正すべき）
- イミュータブルで十分な場合のミュータブルな状態
- コルーチンコンテキスト内でのブロッキングコール
- 長いループでのキャンセレーションチェックの欠落
- sealed型に対する非網羅的な`when`
- 大きな関数（50行超）
- 深いネスト（4レベル超）
### MEDIUM（検討すべき）
- 非イディオマティックなKotlin（Javaスタイルのパターン）
- トレイリングカンマの欠落
- スコープ関数の誤用やネスト
- 大きなコレクションチェーンでのsequenceの欠落
- 冗長な明示的型
## 実行される自動チェック
```bash
# ビルドチェック
./gradlew build
# 静的解析
./gradlew detekt
# フォーマットチェック
./gradlew ktlintCheck
# テスト
./gradlew test
```
## 使用例
````text
User: /kotlin-review
Agent:
# Kotlinコードレビューレポート
## レビュー対象ファイル
- src/main/kotlin/com/example/service/UserService.kt（変更）
- src/main/kotlin/com/example/routes/UserRoutes.kt（変更）
## 静的解析結果
✓ ビルド: 成功
✓ detekt: 問題なし
WARNING: ktlint: フォーマット警告2件
## 検出された問題
[CRITICAL] 強制アンラップNullセーフティ
File: src/main/kotlin/com/example/service/UserService.kt:28
Issue: nullableなリポジトリ結果に!!を使用
```kotlin
val user = repository.findById(id)!! // NPEリスク
```
Fix: セーフコールとエラーハンドリングを使用
```kotlin
val user = repository.findById(id)
?: throw UserNotFoundException("User $id not found")
```
[HIGH] GlobalScopeの使用
File: src/main/kotlin/com/example/routes/UserRoutes.kt:45
Issue: GlobalScopeの使用は構造化された並行性を壊す
```kotlin
GlobalScope.launch {
notificationService.sendWelcome(user)
}
```
Fix: コールのコルーチンスコープを使用
```kotlin
launch {
notificationService.sendWelcome(user)
}
```
## サマリー
- CRITICAL: 1
- HIGH: 1
- MEDIUM: 0
推奨: FAIL: CRITICALの問題が修正されるまでマージをブロック
````
## 承認基準
| ステータス | 条件 |
|-----------|------|
| PASS: 承認 | CRITICALまたはHIGHの問題がない |
| WARNING: 警告 | MEDIUMの問題のみ（注意してマージ） |
| FAIL: ブロック | CRITICALまたはHIGHの問題が検出 |
## 他のコマンドとの統合
- まず`/kotlin-test`を使用してテストが通ることを確認
- ビルドエラーが発生した場合は`/kotlin-build`を使用
- コミット前に`/kotlin-review`を使用
- Kotlin固有でない懸念には`/code-review`を使用
## 関連
- エージェント: `agents/kotlin-reviewer.md`
- スキル: `skills/kotlin-patterns/`、`skills/kotlin-testing/`

312
docs/ja-JP/commands/kotlin-test.md Normal file
View File

@@ -0,0 +1,312 @@
---
description: KotlinのTDDワークフローを強制します。最初にKotestテストを書き、その後実装します。Koverで80%以上のカバレッジを検証します。
---
# Kotlin TDDコマンド
このコマンドはKotest、MockK、Koverを使用したKotlinコードのテスト駆動開発方法論を強制します。
## このコマンドの動作
1. **型/インターフェースを定義**: 関数のシグネチャを先にスキャフォールド
2. **Kotestテストを書く**: 包括的なテストスペックを作成（RED）
3. **テストを実行**: テストが正しい理由で失敗することを検証
4. **コードを実装**: テストを通す最小限のコードを書く（GREEN）
5. **リファクタリング**: テストをグリーンに保ちながら改善
6. **カバレッジをチェック**: Koverで80%以上のカバレッジを確保
## 使用するタイミング
`/kotlin-test`を使用するのは:
- 新しいKotlinの関数やクラスを実装する時
- 既存のKotlinコードにテストカバレッジを追加する時
- バグを修正する時（失敗するテストを最初に書く）
- 重要なビジネスロジックを構築する時
- KotlinでTDDワークフローを学ぶ時
## TDDサイクル
```
RED -> 失敗するKotestテストを書く
GREEN -> テストを通す最小限のコードを実装
REFACTOR -> コードを改善、テストはグリーンのまま
REPEAT -> 次のテストケースへ
```
## セッション例
````text
User: /kotlin-test ユーザー登録リクエストをバリデートする関数が必要です
Agent:
# TDDセッション: 登録バリデーター
## ステップ 1: インターフェース定義
```kotlin
// validator/RegistrationValidator.kt
package com.example.validator
data class RegistrationRequest(
val name: String,
val email: String,
val password: String,
)
sealed class ValidationResult {
data object Valid : ValidationResult()
data class Invalid(val errors: List<String>) : ValidationResult()
}
fun validateRegistration(request: RegistrationRequest): ValidationResult {
TODO("not implemented")
}
```
## ステップ 2: Kotestテストを書く（RED）
```kotlin
// validator/RegistrationValidatorTest.kt
package com.example.validator
import io.kotest.core.spec.style.FunSpec
import io.kotest.matchers.shouldBe
import io.kotest.matchers.types.shouldBeInstanceOf
class RegistrationValidatorTest : FunSpec({
test("valid registration returns Valid") {
val request = RegistrationRequest(
name = "Alice",
email = "alice@example.com",
password = "SecureP@ss1",
)
val result = validateRegistration(request)
result.shouldBeInstanceOf<ValidationResult.Valid>()
}
test("blank name returns Invalid") {
val request = RegistrationRequest(
name = "",
email = "alice@example.com",
password = "SecureP@ss1",
)
val result = validateRegistration(request)
val invalid = result.shouldBeInstanceOf<ValidationResult.Invalid>()
invalid.errors shouldBe listOf("Name is required")
}
test("invalid email returns Invalid") {
val request = RegistrationRequest(
name = "Alice",
email = "not-an-email",
password = "SecureP@ss1",
)
val result = validateRegistration(request)
val invalid = result.shouldBeInstanceOf<ValidationResult.Invalid>()
invalid.errors shouldBe listOf("Invalid email format")
}
test("short password returns Invalid") {
val request = RegistrationRequest(
name = "Alice",
email = "alice@example.com",
password = "short",
)
val result = validateRegistration(request)
val invalid = result.shouldBeInstanceOf<ValidationResult.Invalid>()
invalid.errors shouldBe listOf("Password must be at least 8 characters")
}
test("multiple errors returns all errors") {
val request = RegistrationRequest(
name = "",
email = "bad",
password = "short",
)
val result = validateRegistration(request)
val invalid = result.shouldBeInstanceOf<ValidationResult.Invalid>()
invalid.errors.size shouldBe 3
}
})
```
## ステップ 3: テスト実行 - FAIL確認
```bash
$ ./gradlew test
RegistrationValidatorTest > valid registration returns Valid FAILED
kotlin.NotImplementedError: An operation is not implemented
FAILED (5 tests, 0 passed, 5 failed)
```
✓ テストが期待通りに失敗（NotImplementedError）。
## ステップ 4: 最小限のコードを実装（GREEN）
```kotlin
// validator/RegistrationValidator.kt
package com.example.validator
private val EMAIL_REGEX = Regex("^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$")
private const val MIN_PASSWORD_LENGTH = 8
fun validateRegistration(request: RegistrationRequest): ValidationResult {
val errors = buildList {
if (request.name.isBlank()) add("Name is required")
if (!EMAIL_REGEX.matches(request.email)) add("Invalid email format")
if (request.password.length < MIN_PASSWORD_LENGTH) add("Password must be at least $MIN_PASSWORD_LENGTH characters")
}
return if (errors.isEmpty()) ValidationResult.Valid
else ValidationResult.Invalid(errors)
}
```
## ステップ 5: テスト実行 - PASS確認
```bash
$ ./gradlew test
RegistrationValidatorTest > valid registration returns Valid PASSED
RegistrationValidatorTest > blank name returns Invalid PASSED
RegistrationValidatorTest > invalid email returns Invalid PASSED
RegistrationValidatorTest > short password returns Invalid PASSED
RegistrationValidatorTest > multiple errors returns all errors PASSED
PASSED (5 tests, 5 passed, 0 failed)
```
✓ 全テスト通過！
## ステップ 6: カバレッジチェック
```bash
$ ./gradlew koverHtmlReport
Coverage: 100.0% of statements
```
✓ カバレッジ: 100%
## TDD完了！
````
## テストパターン
### StringSpec（最もシンプル）
```kotlin
class CalculatorTest : StringSpec({
"add two positive numbers" {
Calculator.add(2, 3) shouldBe 5
}
})
```
### BehaviorSpec（BDD）
```kotlin
class OrderServiceTest : BehaviorSpec({
Given("a valid order") {
When("placed") {
Then("should be confirmed") { /* ... */ }
}
}
})
```
### データ駆動テスト
```kotlin
class ParserTest : FunSpec({
context("valid inputs") {
withData("2026-01-15", "2026-12-31", "2000-01-01") { input ->
parseDate(input).shouldNotBeNull()
}
}
})
```
### コルーチンテスト
```kotlin
class AsyncServiceTest : FunSpec({
test("concurrent fetch completes") {
runTest {
val result = service.fetchAll()
result.shouldNotBeEmpty()
}
}
})
```
## カバレッジコマンド
```bash
# カバレッジ付きでテスト実行
./gradlew koverHtmlReport
# カバレッジ閾値を検証
./gradlew koverVerify
# CI用XMLレポート
./gradlew koverXmlReport
# HTMLレポートを開く
open build/reports/kover/html/index.html
# 特定のテストクラスを実行
./gradlew test --tests "com.example.UserServiceTest"
# 詳細出力で実行
./gradlew test --info
```
## カバレッジ目標
| コードの種類 | 目標 |
|-------------|------|
| 重要なビジネスロジック | 100% |
| パブリックAPI | 90%以上 |
| 一般コード | 80%以上 |
| 生成コード | 除外 |
## TDDベストプラクティス
**すべきこと:**
- 実装の前にテストを先に書く
- 各変更後にテストを実行
- 表現力のあるアサーションにKotestマッチャーを使用
- サスペンド関数にはMockKの`coEvery`/`coVerify`を使用
- 実装の詳細ではなく動作をテスト
- エッジケースを含める（空、null、最大値）
**すべきでないこと:**
- テストの前に実装を書く
- RED段階をスキップ
- プライベート関数を直接テスト
- コルーチンテストで`Thread.sleep()`を使用
- フレイキーなテストを無視
## 関連コマンド
- `/kotlin-build` — ビルドエラーを修正
- `/kotlin-review` — 実装後にコードをレビュー
- `verification-loop`スキル — 完全な検証ループを実行
## 関連
- スキル: `skills/kotlin-testing/`
- スキル: `skills/tdd-workflow/`

116
docs/ja-JP/commands/learn-eval.md Normal file
View File

@@ -0,0 +1,116 @@
---
description: "セッションから再利用可能なパターンを抽出し、保存前に品質を自己評価し、適切な保存場所（グローバル vs プロジェクト）を決定します。"
---
# /learn-eval - 抽出、評価、そして保存
`/learn`を拡張し、スキルファイルを書く前に品質ゲート、保存場所の決定、ナレッジ配置の認識を追加します。
## 抽出対象
以下を探す:
1. **エラー解決パターン** — 根本原因 + 修正 + 再利用性
2. **デバッグテクニック** — 非自明なステップ、ツールの組み合わせ
3. **ワークアラウンド** — ライブラリの癖、APIの制限、バージョン固有の修正
4. **プロジェクト固有のパターン** — 規約、アーキテクチャの決定、統合パターン
## プロセス
1. セッションから抽出可能なパターンをレビュー
2. 最も価値の高い/再利用可能なインサイトを特定
3. **保存場所の決定:**
- 質問: 「このパターンは別のプロジェクトでも役立つか？」
- **グローバル** (`~/.claude/skills/learned/`): 2つ以上のプロジェクトで使える汎用パターン（bash互換性、LLM APIの動作、デバッグテクニックなど）
- **プロジェクト** (現在のプロジェクトの`.claude/skills/learned/`): プロジェクト固有のナレッジ（特定の設定ファイルの癖、プロジェクト固有のアーキテクチャ決定など）
- 迷ったらグローバルを選択（グローバル → プロジェクトへの移動はその逆より容易）
4. 以下の形式でスキルファイルのドラフトを作成:
```markdown
---
name: pattern-name
description: "130文字以内"
user-invocable: false
origin: auto-extracted
---
# [説明的なパターン名]
**抽出日:** [日付]
**コンテキスト:** [これが適用される場面の簡潔な説明]
## 問題
[このパターンが解決する問題 - 具体的に]
## 解決策
[パターン/テクニック/ワークアラウンド - コード例付き]
## 使用するタイミング
[トリガー条件]
```
5. **品質ゲート — チェックリスト + 総合判定**
### 5a. 必須チェックリスト（実際にファイルを読んで検証）
ドラフトを評価する前に、以下の**すべて**を実行:
- [ ] `~/.claude/skills/`および関連プロジェクトの`.claude/skills/`ファイルをキーワードでgrepし、内容の重複を確認
- [ ] MEMORY.md（プロジェクトとグローバル両方）の重複を確認
- [ ] 既存スキルへの追記で十分かを検討
- [ ] これが再利用可能なパターンであり、一回限りの修正でないことを確認
### 5b. 総合判定
チェックリスト結果とドラフト品質を統合し、以下の**いずれか1つ**を選択:
| 判定 | 意味 | 次のアクション |
|------|------|--------------|
| **Save** | ユニーク、具体的、適切にスコープされている | ステップ 6に進む |
| **Improve then Save** | 価値はあるが改善が必要 | 改善点をリスト → 修正 → 再評価（1回） |
| **Absorb into [X]** | 既存スキルに追記すべき | 対象スキルと追加内容を表示 → ステップ 6 |
| **Drop** | 些末、冗長、または抽象的すぎる | 理由を説明して終了 |
**ガイドライン指標**（判定を通知するが、スコアリングはしない）:
- **具体性と実行可能性**: すぐに使えるコード例やコマンドが含まれている
- **スコープの適合性**: 名前、トリガー条件、内容が整合し、単一のパターンに焦点を当てている
- **ユニーク性**: 既存スキルでカバーされていない価値を提供（チェックリスト結果から判断）
- **再利用性**: 将来のセッションで現実的なトリガーシナリオが存在
6. **判定別の確認フロー**
- **Improve then Save**: 必要な改善 + 修正ドラフト + 更新されたチェックリスト/判定を1回の再評価後に提示。修正後の判定が**Save**ならユーザー確認後に保存、それ以外は新しい判定に従う
- **Save**: 保存パス + チェックリスト結果 + 1行の判定理由 + 完全なドラフトを提示 → ユーザー確認後に保存
- **Absorb into [X]**: 対象パス + 追加内容（diff形式）+ チェックリスト結果 + 判定理由を提示 → ユーザー確認後に追記
- **Drop**: チェックリスト結果 + 理由のみを表示（確認不要）
7. 決定された場所に保存/追記
## ステップ 5の出力形式
```
### チェックリスト
- [x] skills/ grep: 重複なし（または: 重複検出 → 詳細）
- [x] MEMORY.md: 重複なし（または: 重複検出 → 詳細）
- [x] 既存スキル追記: 新規ファイルが適切（または: [X]に追記すべき）
- [x] 再利用性: 確認済み（または: 一回限り → Drop）
### 判定: Save / Improve then Save / Absorb into [X] / Drop
**理由:** （判定を説明する1-2文）
```
## 設計の根拠
このバージョンは、以前の5ディメンション数値スコアリングルーブリック（Specificity、Actionability、Scope Fit、Non-redundancy、Coverageを1-5でスコアリング）をチェックリストベースの総合判定システムに置き換えています。最新のフロンティアモデル（Opus 4.6+）は強力なコンテキスト判断能力を持っており、豊かな定性的シグナルを数値スコアに強制すると、ニュアンスが失われ、誤解を招く合計を生み出す可能性があります。総合的なアプローチにより、モデルがすべての要因を自然に重み付けし、明示的なチェックリストが重要なチェックのスキップを防ぎながら、より正確な保存/破棄の決定を生み出します。
## 注意事項
- 些末な修正を抽出しない（タイプミス、単純な構文エラー）
- 一回限りの問題を抽出しない（特定のAPI障害など）
- 将来のセッションで時間を節約するパターンに焦点を当てる
- スキルは焦点を絞る — 1スキル1パターン
- 判定がAbsorbの場合、新しいファイルを作成せず既存スキルに追記

36
docs/ja-JP/commands/loop-start.md Normal file
View File

@@ -0,0 +1,36 @@
---
description: 安全性デフォルトと明示的な停止条件を持つ、管理された自律ループパターンを開始します。
---
# ループ開始コマンド
安全性デフォルトを持つ管理された自律ループパターンを開始します。
## 使い方
`/loop-start [pattern] [--mode safe|fast]`
- `pattern`: `sequential`、`continuous-pr`、`rfc-dag`、`infinite`
- `--mode`:
- `safe`（デフォルト）: 厳格な品質ゲートとチェックポイント
- `fast`: スピード重視で削減されたゲート
## フロー
1. リポジトリの状態とブランチ戦略を確認。
2. ループパターンとモデルティア戦略を選択。
3. 選択されたモードに必要なフック/プロファイルを有効化。
4. ループ計画を作成し、`.claude/plans/`にランブックを書き込み。
5. ループの開始とモニタリングのためのコマンドを表示。
## 必須の安全チェック
- 最初のループイテレーション前にテストが通ることを検証。
- `ECC_HOOK_PROFILE`がグローバルに無効化されていないことを確認。
- ループに明示的な停止条件があることを確認。
## 引数
$ARGUMENTS:
- `<pattern>` オプション（`sequential|continuous-pr|rfc-dag|infinite`）
- `--mode safe|fast` オプション

58
docs/ja-JP/commands/loop-status.md Normal file
View File

@@ -0,0 +1,58 @@
---
description: アクティブなループの状態、進捗、障害シグナル、推奨される介入を検査します。
---
# ループステータスコマンド
アクティブなループの状態、進捗、障害シグナルを検査します。
このスラッシュコマンドは、現在のセッションがデキューした後にのみ実行できます。ウェッジしたセッションやシブリングセッションを検査する必要がある場合は、別のターミナルからパッケージ化されたCLIを実行してください:
```bash
npx --package ecc-universal ecc loop-status --json
```
CLIは`~/.claude/projects/**`配下のローカルClaudeトランスクリプトJSONLファイルをスキャンし、古い`ScheduleWakeup`コールやマッチする`tool_result`がない`Bash`ツールコールを報告します。
## 使い方
`/loop-status [--watch]`
## 報告内容
- アクティブなループパターン
- 現在のフェーズと最後の成功チェックポイント
- 失敗しているチェック（ある場合）
- 推定時間/コストのドリフト
- 推奨される介入（continue/pause/stop）
## クロスセッションCLI
- `ecc loop-status --json` 最近のローカルClaudeトランスクリプトの機械読み取り可能なステータスを出力。
- `ecc loop-status --home <dir>` 別のホームディレクトリをスキャン（別のローカルプロファイルやマウントされたワークスペースの検査時）。
- `ecc loop-status --transcript <session.jsonl>` 1つのトランスクリプトを直接検査。
- `ecc loop-status --bash-timeout-seconds 1800` 古いBashの閾値を調整。
- `ecc loop-status --exit-code` 古いループやツールシグナルが検出された場合に`2`で終了、トランスクリプトがスキャンできない場合は`1`で終了。
- `--exit-code`と`--watch`を併用する場合は`--watch-count`が必要（ウォッチドッグスクリプトがプロセス終了を永遠に待たないように）。
- `ecc loop-status --watch` 中断されるまでステータスを更新。
- `ecc loop-status --watch --watch-count 3 --exit-code` 限定回数更新し、確認された最高ステータスで終了。
- `ecc loop-status --watch --watch-count 3` スクリプトやハンドオフ用の限定ウォッチストリームを出力。
- `ecc loop-status --watch --write-dir ~/.claude/loops` シブリングターミナルやウォッチドッグスクリプト用に`index.json`とセッションごとのJSONスナップショットを維持。
## ウォッチモード
`--watch`が指定されている場合、定期的にステータスを更新します。`--json`併用時は、各更新が1行あたり1つのJSONオブジェクトとして出力され、別のターミナルやスクリプトがストリームを消費できます。
## スナップショットファイル
別のプロセスが現在のClaudeセッションの`/loop-status`デキューを待たずにループ状態を検査する必要がある場合は、`--write-dir <dir>`を使用します。CLIは以下を書き込みます:
- 検査されたセッションごとに1行の`index.json`。
- そのセッションの完全なステータスペイロードを含む`<session-id>.json`。
これらのファイルはローカルトランスクリプト分析のスナップショットです。Claude Codeランタイムのツールコールを制御したりタイムアウトさせたりするものではありません。
## 引数
$ARGUMENTS:
- `--watch` オプション

30
docs/ja-JP/commands/model-route.md Normal file
View File

@@ -0,0 +1,30 @@
---
description: 複雑さ、リスク、予算に基づいて、現在のタスクに最適なモデルティアを推奨します。
---
# モデルルーティングコマンド
複雑さと予算に基づいて、現在のタスクに最適なモデルティアを推奨します。
## 使い方
`/model-route [task-description] [--budget low|med|high]`
## ルーティングヒューリスティック
- `haiku`: 決定論的で低リスクな機械的変更
- `sonnet`: 実装とリファクタリングのデフォルト
- `opus`: アーキテクチャ、深いレビュー、曖昧な要件
## 必須出力
- 推奨モデル
- 信頼度レベル
- このモデルが適する理由
- 最初の試行が失敗した場合のフォールバックモデル
## 引数
$ARGUMENTS:
- `[task-description]` オプションのフリーテキスト
- `--budget low|med|high` オプション

160
docs/ja-JP/commands/plan-prd.md Normal file
View File

@@ -0,0 +1,160 @@
---
description: "リーンで問題起点のPRDを生成し、実装計画のために/planに引き渡します。"
argument-hint: "[製品/機能のアイデア]（空欄 = 質問から開始）"
---
# PRDコマンド
**プロダクト要件ドキュメント**を作成します — SDLCの要件フェーズのアーティファクトです。成功のために*何*が真でなければならないか、*なぜ*かを記録し、*どのように*の前で止まります。実装の分解は`/plan`に委任されます。
**入力**: `$ARGUMENTS`
## このコマンドのスコープ
| このコマンドがすること | このコマンドがしないこと |
|---|---|
| 問題とユーザーをフレーミング | アーキテクチャの設計 |
| 成功基準とスコープの記録 | ファイルの選択やパターンの記述 |
| 未解決の質問とリスクの一覧 | 実装タスクの列挙 |
| `.claude/prds/{name}.prd.md`の書き込み | 実装計画の作成 — それは`/plan` |
実装の詳細を書いていることに気づいたら、止めて削除してください。それは`/plan`に属します。
**アンチフラフルール**: 情報が不足している場合は`TBD — {方法}による検証が必要`と書く。もっともらしく聞こえる要件を作り出さないこと。
## ワークフロー
4つのフェーズ。各フェーズは単一のゲート — 質問し、ユーザーを待ち、次に進む。ネストしたループも並行リサーチの儀式もなし。
### フェーズ 1 — FRAME
`$ARGUMENTS`が空の場合、質問:
> 何をビルドしたいですか？1〜2文で。
提供された場合、1文で再述し質問:
> 理解しました: *{再述}*。正しいですか、調整すべきですか？
次にフレーミング質問を一度に提示:
> 1. **誰が**この問題を抱えていますか？（具体的な役割またはセグメント）
> 2. **何が**観察可能な痛みですか？（想定されるニーズではなく行動を記述）
> 3. **なぜ**既存のもので解決できないのですか？
> 4. **なぜ今？** — 何が変わってこれを行う価値があるのですか？
ユーザーを待つ。回答（または明示的な"skip"）なしに先に進まない。
### フェーズ 2 — GROUND
エビデンスを求める。これは最も短いフェーズであり、最も重要:
> この問題が実在し解決する価値があるというエビデンスは何ですか？（ユーザーの引用、サポートチケット、メトリクス、観察された行動、失敗したワークアラウンド — 具体的なもの何でも）
ユーザーにエビデンスがない場合、PRDのEvidenceセクションを`仮説 — {ユーザーリサーチ | アナリティクス | プロトタイプ}による検証が必要`と記録。これによりPRDの誠実さが保たれる。
### フェーズ 3 — DECIDE
スコープと仮説を一度に:
> 1. **仮説** — 完成させてください: *私たちは**{能力}**が**{ユーザー}**の**{問題を解決}**すると信じています。**{測定可能な成果}**が得られたら正しいとわかります。*
> 2. **MVP** — 仮説をテストするために必要な最小限は？
> 3. **スコープ外** — ユーザーが求めても明示的に**ビルドしない**ものは？
> 4. **未解決の質問** — アプローチを変える可能性のある不確実性は？
回答を待つ。
### フェーズ 4 — GENERATE & HAND OFF
必要に応じてディレクトリを作成し、PRDを書き、報告。
```bash
mkdir -p .claude/prds
```
**出力パス**: `.claude/prds/{kebab-case-name}.prd.md`
#### PRDテンプレート
```markdown
# {製品 / 機能名}
## Problem
{2〜3文: 誰が何の問題を抱えていて、未解決のコストは何か？}
## Evidence
- {ユーザーの引用、データポイント、または観察}
- {または: "仮説 — {方法}による検証が必要"}
## Users
- **Primary**: {役割、コンテキスト、ニーズのトリガー}
- **Not for**: {明示的に除外する対象}
## Hypothesis
私たちは**{能力}**が**{ユーザー}**の**{問題を解決}**すると信じています。
**{測定可能な成果}**が得られたら正しいとわかります。
## Success Metrics
| Metric | Target | How measured |
|---|---|---|
| {primary} | {number} | {method} |
## Scope
**MVP** — {仮説をテストするための最小限}
**Out of scope**
- {項目} — {延期する理由}
## Delivery Milestones
<!-- ビジネス成果であり、エンジニアリングタスクではない。/planが各マイルストーンを計画に変換。 -->
<!-- Status: pending | in-progress | complete -->
| # | Milestone | Outcome | Status | Plan |
|---|---|---|---|---|
| 1 | {name} | {ユーザーに見える変更} | pending | — |
| 2 | {name} | {ユーザーに見える変更} | pending | — |
## Open Questions
- [ ] {スコープやアプローチを変える可能性のある質問}
## Risks
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
---
*Status: DRAFT — 要件のみ。実装計画は/planで保留中。*
```
#### ユーザーへの報告
```
PRD created: .claude/prds/{name}.prd.md
Problem: {一行}
Hypothesis: {一行}
MVP: {一行}
Validation status:
Problem {validated | assumption}
Users {concrete | generic — refine}
Metrics {defined | TBD}
Open questions: {count}
Next step: /plan .claude/prds/{name}.prd.md
→ /plan が次の保留中のマイルストーンを選択し、実装計画を作成します。
```
## 統合
- `/plan <prd-path>` — PRDを消費し、次の保留中のマイルストーンの実装計画を作成。
- `tdd-workflow`スキル — テストファーストで計画を実装。
- `/pr` — PRDと計画を参照するPRを作成。
## 成功基準
- **PROBLEM_CLEAR**: 問題が具体的でエビデンスがある（または仮説としてフラグ付き）。
- **USER_CONCRETE**: プライマリユーザーが具体的な役割であり、"ユーザー"ではない。
- **HYPOTHESIS_TESTABLE**: 測定可能な成果が含まれている。
- **SCOPE_BOUNDED**: 明示的なMVPと明示的なスコープ外。
- **NO_IMPLEMENTATION_DETAIL**: ファイルパス、ライブラリ、タスクの分解が含まれていない — もし含まれていたら`/plan`ステップに移動。

200
docs/ja-JP/commands/plan.md Normal file
View File

@@ -0,0 +1,200 @@
---
description: 要件を再述し、リスクを評価し、段階的な実装計画を作成します。コードに触れる前にユーザーの確認を待ちます。
argument-hint: "[機能の説明 | path/to/*.prd.md]"
---
# Planコマンド
このコマンドはコードを書く前に包括的な実装計画を作成します。フリーフォームの要件またはPRDマークダウンファイルのいずれかを受け付けます。
デフォルトではインラインで実行します。デフォルトではTaskツールやサブエージェントを呼び出しません。これにより`/plan`はエージェントファイルなしでコマンドを出荷するプラグインインストールからも使用可能です。
## このコマンドの動作
1. **要件を再述** — 何を構築するかを明確化
2. **リスクを特定** — 潜在的な問題とブロッカーを表面化
3. **段階的計画を作成** — 実装をフェーズに分解
4. **確認を待つ** — 続行前にユーザーの承認を受けなければならない
## 使用するタイミング
`/plan`を使用するのは:
- 新機能を開始する時
- 重要なアーキテクチャ変更を行う時
- 複雑なリファクタリングに取り組む時
- 複数のファイル/コンポーネントが影響を受ける時
- 要件が不明確または曖昧な時
## 動作方法
アシスタントは以下を行います:
1. リクエストを**分析**し、明確な用語で要件を再述
2. リポジトリが利用可能な場合、関連するコードベースパターンに**計画を根拠付け**
3. 具体的で実行可能なステップを含む**フェーズに分解**
4. コンポーネント間の**依存関係を特定**
5. **リスク**と潜在的なブロッカーを評価
6. **複雑さを見積もり**（High/Medium/Low）
7. **計画を提示**し、明示的な確認を待つ
## 入力モード
| 入力 | モード | 動作 |
|------|--------|------|
| `path/to/name.prd.md` | PRDアーティファクトモード | PRDを読み、次の保留中のデリバリーマイルストーンまたは実装フェーズを選択し、`.claude/plans/{name}.plan.md`を書き込み |
| その他のマークダウンパス | リファレンスモード | ファイルをコンテキストとして読み、インライン計画を出力 |
| フリーフォームテキスト | 会話モード | インライン計画を出力 |
| 空の入力 | 明確化モード | 何を計画すべきかを質問 |
PRDアーティファクトモードでは、必要に応じて`.claude/plans/`を作成します。PRDに`Delivery Milestones`テーブルが含まれている場合、選択された行のみを`pending`から`in-progress`に更新し、その`Plan`セルに生成された計画パスを設定します。PRDがレガシーの`.claude/PRPs/prds/`形式で`Implementation Phases`を使用している場合、パスを移行せずに読み取ります。
## パターン根拠付け
計画を書く前に、実装がミラーすべき規約をコードベースから検索します。関連する各カテゴリについて、ファイル参照付きの最上位の例をキャプチャ:
| カテゴリ | キャプチャ対象 |
|---------|-------------|
| 命名 | 影響を受ける領域のファイル、関数、型、コマンド、またはスクリプトの命名 |
| エラーハンドリング | 失敗がどのように発生、返却、ログ、または優雅に処理されるか |
| ロギング | レベル、フォーマット、何がログされるか |
| データアクセス | リポジトリ、サービス、クエリ、またはファイルシステムパターン |
| テスト | テストファイルの場所、フレームワーク、フィクスチャ、アサーションスタイル |
類似コードが存在しない場合は、明示的にそう述べます。パターンを作り出さないでください。
## PRDアーティファクト出力
`.prd.md`ファイルで呼び出された場合、以下の構造で`.claude/plans/{kebab-case-name}.plan.md`に計画を書き込み:
````markdown
# Plan: {機能名}
**Source PRD**: {パス}
**Selected Milestone**: {マイルストーンまたはフェーズ名}
**Complexity**: {Small | Medium | Large}
## Summary
{2-3文}
## Patterns to Mirror
| Category | Source | Pattern |
|---|---|---|
| Naming | `path:line` | {短い説明} |
| Errors | `path:line` | {短い説明} |
| Tests | `path:line` | {短い説明} |
## Files to Change
| File | Action | Why |
|---|---|---|
| `path` | CREATE / UPDATE / DELETE | {理由} |
## Tasks
### Task 1: {名前}
- **Action**: {何をするか}
- **Mirror**: {従うパターン}
- **Validate**: {正確性を証明するコマンド}
## Validation
```bash
{プロジェクト固有の検証コマンド}
```
## Risks
| Risk | Likelihood | Mitigation |
|---|---|---|
## Acceptance
- [ ] すべてのタスク完了
- [ ] バリデーション通過
- [ ] パターンをミラー、再発明しない
````
アーティファクトを書いた後、パスを報告し、コードを書く前に確認を待ちます。
## 使用例
```
User: /plan マーケットが解決した時にリアルタイム通知を追加する必要があります
Assistant:
# 実装計画: リアルタイムマーケット解決通知
## 要件の再述
- ユーザーがウォッチしているマーケットが解決した時に通知を送信
- 複数の通知チャネル（アプリ内、メール、webhook）をサポート
- 通知が確実に配信されることを保証
- マーケットの結果とユーザーのポジション結果を含める
## 実装フェーズ
### フェーズ 1: データベーススキーマ
- 通知テーブルを追加（カラム: id, user_id, market_id, type, status, created_at）
- user_notification_preferencesテーブルをチャネル設定用に追加
- パフォーマンスのためにuser_idとmarket_idにインデックスを作成
### フェーズ 2: 通知サービス
- lib/notifications.tsに通知サービスを作成
- BullMQ/Redisを使用した通知キューを実装
- 配信失敗時のリトライロジックを追加
- 通知テンプレートを作成
### フェーズ 3: 統合ポイント
- マーケット解決ロジックにフック（ステータスが"resolved"に変更された時）
- マーケットにポジションを持つすべてのユーザーをクエリ
- 各ユーザーの通知をエンキュー
### フェーズ 4: フロントエンドコンポーネント
- ヘッダーにNotificationBellコンポーネントを作成
- NotificationListモーダルを追加
- Supabaseサブスクリプション経由のリアルタイム更新を実装
- 通知設定ページを追加
## 依存関係
- Redis（キュー用）
- メールサービス（SendGrid/Resend）
- Supabaseリアルタイムサブスクリプション
## リスク
- HIGH: メール配信性（SPF/DKIMが必要）
- MEDIUM: 1000人以上のユーザー/マーケットでのパフォーマンス
- MEDIUM: マーケットが頻繁に解決する場合の通知スパム
- LOW: リアルタイムサブスクリプションのオーバーヘッド
## 推定複雑さ: MEDIUM
- バックエンド: 4-6時間
- フロントエンド: 3-4時間
- テスト: 2-3時間
- 合計: 9-13時間
**確認待ち**: この計画で進めますか？（yes/no/modify）
```
## 重要な注意事項
**重要**: このコマンドは、ユーザーが"yes"や"proceed"などの明示的な肯定的回答で計画を確認するまで、コードを**一切書きません**。
変更を希望する場合は、以下のように回答してください:
- "modify: [変更内容]"
- "different approach: [代替案]"
- "skip phase 2 and do phase 3 first"
## 他のコマンドとの統合
計画後:
- `tdd-workflow`スキルでテスト駆動開発で実装
- ビルドエラーが発生した場合は`/build-fix`を使用
- 完成した実装をレビューするには`/code-review`を使用
- プルリクエストを作成するには`/pr`または`/prp-pr`を使用
> **要件が先に必要ですか？** `/plan-prd`を使用して`.claude/prds/{name}.prd.md`にリーンなPRDを作成。
>
> **レガシーPRPフローが必要ですか？** `/prp-plan`を使用して`.claude/PRPs/`アーティファクトによる詳細なPRP計画を作成。`/prp-implement`を使用してそれらの計画を厳密なバリデーションループで実行。
## オプショナルプランナーエージェント
ECCはエージェントファイルを含む手動インストール用の`planner`エージェントも提供しています。ローカルランタイムが既にそのサブエージェントを公開しており、ユーザーが明示的に計画の委任を要求した場合にのみ使用してください。
`planner`サブエージェントが利用できない場合は、"Agent type 'planner' not found"エラーを表示する代わりに、インラインで計画を続行してください。
手動インストールの場合、ソースファイルは以下にあります:
`agents/planner.md`

184
docs/ja-JP/commands/pr.md Normal file
View File

@@ -0,0 +1,184 @@
---
description: "現在のブランチからプッシュされていないコミットでGitHub PRを作成 — テンプレートの検出、変更の分析、プッシュ"
argument-hint: "[base-branch]（デフォルト: main）"
---
# プルリクエストの作成
**入力**: `$ARGUMENTS` — オプション。ベースブランチ名やフラグ（例: `--draft`）を含む場合があります。
**`$ARGUMENTS`のパース**:
- 認識されたフラグを抽出（`--draft`）
- 残りの非フラグテキストをベースブランチ名として扱う
- 指定がなければベースブランチのデフォルトは`main`
---
## フェーズ 1 — VALIDATE
前提条件をチェック:
```bash
git branch --show-current
git status --short
git log origin/<base>..HEAD --oneline
```
| チェック | 条件 | 失敗時のアクション |
|---|---|---|
| ベースブランチにいない | 現在のブランチ ≠ base | 停止: "まずフィーチャーブランチに切り替えてください。" |
| クリーンなワーキングディレクトリ | コミットされていない変更がない | 警告: "コミットされていない変更があります。コミットまたはスタッシュしてください。" |
| 先行コミットがある | `git log origin/<base>..HEAD`が空でない | 停止: "`<base>`より先行するコミットがありません。PRにする内容がありません。" |
| 既存のPRがない | `gh pr list --head <branch> --json number`が空 | 停止: "PRは既に存在: #<number>。`gh pr view <number> --web`で開いてください。" |
すべてのチェックが通れば続行。
---
## フェーズ 2 — DISCOVER
### PRテンプレート
PRテンプレートを順番に検索:
1. `.github/PULL_REQUEST_TEMPLATE/`ディレクトリ — 存在する場合、ファイルを一覧しユーザーに選択させる（またはdefault.mdを使用）
2. `.github/PULL_REQUEST_TEMPLATE.md`
3. `.github/pull_request_template.md`
4. `docs/pull_request_template.md`
見つかった場合、読み取ってPR本文の構造に使用。
### コミット分析
```bash
git log origin/<base>..HEAD --format="%h %s" --reverse
```
コミットを分析して以下を決定:
- **PRタイトル**: タイププレフィックス付きのconventional commitフォーマットを使用 — `feat: ...`、`fix: ...`など
- 複数のタイプがある場合、支配的なものを使用
- 単一コミットの場合、そのメッセージをそのまま使用
- **変更サマリー**: タイプ/領域別にコミットをグループ化
### ファイル分析
```bash
git diff origin/<base>..HEAD --stat
git diff origin/<base>..HEAD --name-only
```
変更ファイルをカテゴリ分類: ソース、テスト、ドキュメント、設定、マイグレーション。
### 計画アーティファクト
`/plan-prd`、`/plan`、またはレガシーPRPワークフローで作成された関連アーティファクトを確認:
- `.claude/prds/` — このPRがマイルストーンを実装するPRD
- `.claude/plans/` — このPRで実行された計画
- `.claude/PRPs/prds/` — レガシーPRP PRD
- `.claude/PRPs/plans/` — レガシーPRP実装計画
- `.claude/PRPs/reports/` — レガシーPRP実装レポート
存在する場合、PR本文で参照。
---
## フェーズ 3 — PUSH
```bash
git push -u origin HEAD
```
ダイバージェンスによりプッシュが失敗した場合:
```bash
git fetch origin
git rebase origin/<base>
git push -u origin HEAD
```
リベースコンフリクトが発生した場合、停止してユーザーに通知。
---
## フェーズ 4 — CREATE
### テンプレートあり
フェーズ 2でPRテンプレートが見つかった場合、コミットとファイル分析を使用して各セクションを記入。テンプレートのすべてのセクションを保持 — 該当しないセクションは削除せず"N/A"とする。
### テンプレートなし
このデフォルトフォーマットを使用:
```markdown
## Summary
<このPRが何をしてなぜかの1-2文の説明>
## Changes
<領域別にグループ化された変更の箇条書きリスト>
## Files Changed
<変更タイプ付きの変更ファイルのテーブルまたはリスト: Added/Modified/Deleted>
## Testing
<変更のテスト方法の説明、または"Needs testing">
## Related Issues
<Closes/Fixes/Relates to #Nでリンクされたイシュー、または"None">
```
### PRの作成
```bash
gh pr create \
--title "<PRタイトル>" \
--base <base-branch> \
--body "<PR本文>"
# $ARGUMENTSから--draftフラグがパースされた場合は--draftを追加
```
---
## フェーズ 5 — VERIFY
```bash
gh pr view --json number,url,title,state,baseRefName,headRefName,additions,deletions,changedFiles
gh pr checks --json name,status,conclusion 2>/dev/null || true
```
---
## フェーズ 6 — OUTPUT
ユーザーへの報告:
```
PR #<number>: <title>
URL: <url>
Branch: <head> → <base>
Changes: +<additions> -<deletions> across <changedFiles> files
CI Checks: <ステータスサマリー or "pending" or "none configured">
Artifacts referenced:
- <PR本文でリンクされたPRD/計画>
Next steps:
- gh pr view <number> --web → ブラウザで開く
- /code-review <number> → PRをレビュー
- gh pr merge <number> → 準備ができたらマージ
```
---
## エッジケース
- **`gh` CLIがない**: 停止: "GitHub CLI (`gh`) が必要です。インストール: <https://cli.github.com/>"
- **未認証**: 停止: "まず `gh auth login` を実行してください。"
- **フォースプッシュが必要**: リモートがダイバージしてリベースが行われた場合、`git push --force-with-lease`を使用（`--force`は使わない）。
- **複数のPRテンプレート**: `.github/PULL_REQUEST_TEMPLATE/`に複数のファイルがある場合、一覧してユーザーに選択させる。
- **大きなPR（20ファイル超）**: PRサイズについて警告。変更が論理的に分離可能なら分割を提案。

86
docs/ja-JP/commands/project-init.md Normal file
View File

@@ -0,0 +1,86 @@
---
description: プロジェクトのスタックを検出し、リポジトリのインストールマニフェストとスタックマッピングを使用してドライランECCオンボーディング計画を生成します。
---
# /project-init
現在のプロジェクト用の安全でレビュー可能なECCオンボーディング計画を作成します。このコマンドはドライランモードで開始し、明示的なユーザー承認後にのみファイルを書き込みます。
## 使い方
```text
/project-init
/project-init --dry-run
/project-init --target claude
/project-init --target cursor
/project-init --skills continuous-learning-v2,security-review
/project-init --config ecc-install.json
```
## 安全ルール
1. デフォルトはドライラン。ユーザーが具体的な計画を承認するまで、`CLAUDE.md`、設定ファイル、ルール、スキル、またはインストール状態を変更しない。
2. 既存のプロジェクトガイダンスを保持。`CLAUDE.md`、`.claude/settings.local.json`、`.cursor/`、`.codex/`、`.gemini/`、`.opencode/`、`.codebuddy/`、`.joycode/`、または`.qwen/`が既に存在する場合、内容を検査し上書きではなくマージ/追記計画を提案。
3. ECCのインストーラーとマニフェストツールを使用。インストールのショートカットとしてファイルを手動コピーしたり任意のリモートをクローンしない。
4. パーミッションを狭く保つ。生成された設定は検出されたビルド/テスト/リントツールに一致させ、広範なシェルアクセスを避ける。
5. 何かを適用する前に、正確に何が変わるかを報告。
## 検出入力
現在のプロジェクトルートを読み取り、以下からスタックシグナルを検出:
- パッケージマネージャーファイル: `package.json`、`package-lock.json`、`pnpm-lock.yaml`、`yarn.lock`、`bun.lockb`
- 言語マニフェスト: `pyproject.toml`、`requirements.txt`、`go.mod`、`Cargo.toml`、`pom.xml`、`build.gradle`、`build.gradle.kts`
- フレームワークファイル: `next.config.*`、`vite.config.*`、`tailwind.config.*`、`Dockerfile`、`docker-compose.yml`
- ECC設定: `ecc-install.json`
- オプションのスタックマップ: ECCリポジトリ内の`config/project-stack-mappings.json`
ECCチェックアウトが利用可能な場合、`config/project-stack-mappings.json`をスタックからルール/スキルへの参照として使用。ファイルが利用できない場合、インストール済みのECCマニフェストと明示的なユーザーの選択にフォールバック。
## 計画フロー
1. ターゲットハーネスを特定。ユーザーが`cursor`、`codex`、`gemini`、`opencode`、`codebuddy`、`joycode`、または`qwen`を要求しない限りデフォルトは`claude`。
2. プロジェクトファイルからスタックを検出し、各一致のエビデンスを表示。
3. 最小限の有用なECC計画を解決:
- プロジェクトに`ecc-install.json`がある: `node scripts/install-plan.js --config ecc-install.json --json`
- ユーザーがプロファイルを指定: `node scripts/install-plan.js --profile <profile> --target <target> --json`
- ユーザーがスキルを指定: `node scripts/install-plan.js --skills <skill-ids> --target <target> --json`
- 言語スタックのみ検出: それらの言語名でレガシー言語インストールのドライランを使用
4. 書き込み前にドライラン適用コマンドを実行:
```bash
node scripts/install-apply.js --target <target> --dry-run --json <language-or-profile-args>
```
5. 検出されたスタック、選択されたモジュール/コンポーネント/スキル、ターゲットパス、スキップされた未サポートモジュール、変更されるファイルをサマリー。
6. 非ドライランコマンドを適用する前に承認を求める。
## 出力契約
返却内容:
1. 検出されたスタックのエビデンス
2. 提案されるターゲットハーネス
3. 使用された正確なドライランコマンド
4. 承認後に実行する正確な適用コマンド
5. 作成または変更されるファイル/ディレクトリ
6. 既存ファイル、広範なパーミッション、欠落スクリプト、未サポートターゲットに関する警告
## CLAUDE.mdガイダンス
ユーザーが`CLAUDE.md`スターターを求める場合、インストーラー計画とは別に生成し最小限に保つ:
- ビルドコマンド（検出された場合）
- テストコマンド（検出された場合）
- リント/型チェックコマンド（検出された場合）
- 開発サーバーコマンド（検出された場合）
- 既存のパッケージスクリプトやマニフェストからのリポジトリ固有のメモ
diffを表示して承認を得ずに既存の`CLAUDE.md`を置換しないこと。
## 関連
- `config/project-stack-mappings.json` — スタックからサーフェスへのヒント
- `scripts/install-plan.js` — 決定論的な計画解決
- `scripts/install-apply.js` — ドライランと適用操作
- `/ecc-guide` — インストール前のインタラクティブな機能ディスカバリー

41
docs/ja-JP/commands/promote.md Normal file
View File

@@ -0,0 +1,41 @@
---
name: promote
description: プロジェクトスコープのインスティンクトをグローバルスコープにプロモート
command: true
---
# プロモートコマンド
continuous-learning-v2のインスティンクトをプロジェクトスコープからグローバルスコープにプロモートします。
## 実装
プラグインルートパスを使用してインスティンクトCLIを実行:
```bash
python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" promote [instinct-id] [--force] [--dry-run]
```
または`CLAUDE_PLUGIN_ROOT`が設定されていない場合（手動インストール）:
```bash
python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py promote [instinct-id] [--force] [--dry-run]
```
## 使い方
```bash
/promote # プロモーション候補を自動検出
/promote --dry-run # 自動プロモーション候補をプレビュー
/promote --force # プロンプトなしで全適格候補をプロモート
/promote grep-before-edit # 現在のプロジェクトから1つの特定インスティンクトをプロモート
```
## 動作内容
1. 現在のプロジェクトを検出
2. `instinct-id`が提供された場合、そのインスティンクトのみをプロモート（現在のプロジェクトに存在する場合）
3. それ以外の場合、以下の条件を満たすクロスプロジェクト候補を検出:
- 少なくとも2つのプロジェクトに存在
- 信頼度閾値を満たす
4. プロモートされたインスティンクトを`~/.claude/homunculus/instincts/personal/`に`scope: global`で書き込み

112
docs/ja-JP/commands/prp-commit.md Normal file
View File

@@ -0,0 +1,112 @@
---
description: "自然言語でファイルを指定するクイックコミット — 何をコミットするかを平易な言葉で記述"
argument-hint: "[ターゲットの説明]（空欄 = すべての変更）"
---
# スマートコミット
> PRPs-agentic-engのWirasmによる適応。PRPワークフローシリーズの一部。
**入力**: $ARGUMENTS
---
## フェーズ 1 — ASSESS
```bash
git status --short
```
出力が空の場合 → 停止: "コミットするものがありません。"
変更内容のサマリーをユーザーに表示（追加、変更、削除、未追跡）。
---
## フェーズ 2 — INTERPRET & STAGE
`$ARGUMENTS`を解釈してステージング対象を決定:
| 入力 | 解釈 | Gitコマンド |
|---|---|---|
| *（空 / 未入力）* | すべてをステージ | `git add -A` |
| `staged` | 既にステージ済みのものを使用 | *（git addなし）* |
| `*.ts`や`*.py`など | マッチするglobをステージ | `git add '*.ts'` |
| `except tests` | すべてステージ後、テストをアンステージ | `git add -A && git reset -- '**/*.test.*' '**/*.spec.*' '**/test_*' 2>/dev/null \|\| true` |
| `only new files` | 未追跡ファイルのみステージ | `git ls-files --others --exclude-standard \| grep . && git ls-files --others --exclude-standard \| xargs git add` |
| `the auth changes` | status/diffから解釈 — auth関連ファイルを検出 | `git add <matched files>` |
| 特定のファイル名 | それらのファイルをステージ | `git add <files>` |
自然言語入力（"the auth changes"など）の場合、`git status`出力と`git diff`を相互参照して関連ファイルを特定。どのファイルをなぜステージングするかをユーザーに表示。
```bash
git add <determined files>
```
ステージング後、検証:
```bash
git diff --cached --stat
```
ステージングされたものがなければ、停止: "説明に一致するファイルがありません。"
---
## フェーズ 3 — COMMIT
命令形で単一行のコミットメッセージを作成:
```
{type}: {description}
```
タイプ:
- `feat` — 新機能または能力
- `fix` — バグ修正
- `refactor` — 動作を変えないコード再構築
- `docs` — ドキュメント変更
- `test` — テストの追加または更新
- `chore` — ビルド、設定、依存関係
- `perf` — パフォーマンス改善
- `ci` — CI/CD変更
ルール:
- 命令形（"added feature"ではなく"add feature"）
- タイププレフィックスの後は小文字
- 末尾にピリオドなし
- 72文字以内
- HOWではなくWHATが変わったかを記述
```bash
git commit -m "{type}: {description}"
```
---
## フェーズ 4 — OUTPUT
ユーザーへの報告:
```
Committed: {hash_short}
Message: {type}: {description}
Files: {count} file(s) changed
Next steps:
- git push → リモートにプッシュ
- /prp-pr → プルリクエストを作成
- /code-review → プッシュ前にレビュー
```
---
## 例
| 入力 | 動作 |
|---|---|
| `/prp-commit` | すべてステージ、メッセージを自動生成 |
| `/prp-commit staged` | 既にステージ済みのもののみコミット |
| `/prp-commit *.ts` | すべてのTypeScriptファイルをステージしてコミット |
| `/prp-commit except tests` | テストファイル以外すべてをステージ |
| `/prp-commit the database migration` | statusからDBマイグレーションファイルを検出してステージ |
| `/prp-commit only new files` | 未追跡ファイルのみステージ |

385
docs/ja-JP/commands/prp-implement.md Normal file
View File

@@ -0,0 +1,385 @@
---
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`（または同等のファイル）で利用可能なスクリプトを確認します:
```bash
# Node.js プロジェクトの場合
cat package.json | grep -A 20 '"scripts"'
```
利用可能なコマンドを確認します: 型チェック、リント、テスト、ビルド。
---
## フェーズ 1 — 読み込み
計画ファイルを読み込みます:
```bash
cat "$ARGUMENTS"
```
計画から以下のセクションを抽出します:
- **概要** — 何を構築するか
- **ミラーするパターン** — 従うべきコード規約
- **変更対象ファイル** — 作成または変更するもの
- **ステップごとのタスク** — 実装の順序
- **バリデーションコマンド** — 正しさを検証する方法
- **受け入れ基準** — 完了の定義
ファイルが存在しないか、有効な計画でない場合:
```
Error: Plan file not found or invalid.
Run /prp-plan <feature-description> to create a plan first.
```
**チェックポイント**: 計画を読み込み完了。すべてのセクションを特定。タスクを抽出。
---
## フェーズ 2 — 準備
### Git の状態
```bash
git branch --show-current
git status --porcelain
```
### ブランチの判断
| 現在の状態 | アクション |
|---|---|
| フィーチャーブランチにいる | 現在のブランチを使用 |
| main にいて、ワーキングツリーがクリーン | フィーチャーブランチを作成: `git checkout -b feat/{plan-name}` |
| main にいて、ワーキングツリーがダーティ | **停止** — スタッシュまたはコミットを先に行うようユーザーに確認 |
| このフィーチャー用の Git ワークツリー内にいる | そのワークツリーを使用 |
### リモートとの同期
```bash
git pull --rebase origin $(git branch --show-current) 2>/dev/null || true
```
**チェックポイント**: 正しいブランチにいる。ワーキングツリー準備完了。リモート同期済み。
---
## フェーズ 3 — 実行
計画の各タスクを順番に処理します。
### タスクごとのループ
**ステップごとのタスク**の各タスクについて:
1. **MIRROR リファレンスを読む** — タスクの MIRROR フィールドで参照されているパターンファイルを開きます。コードを書く前に規約を理解します。
2. **実装する** — パターンに正確に従ってコードを書きます。GOTCHA 警告を適用します。指定された IMPORTS を使用します。
3. **即座にバリデーションする** — すべてのファイル変更後に:
```bash
# 型チェックを実行（プロジェクトに応じてコマンドを調整）
[type-check command from Phase 0]
```
型チェックが失敗した場合 → 次のファイルに進む前にエラーを修正します。
4. **進捗を追跡する** — ログ: `[done] Task N: [task name] — complete`
### 逸脱の処理
実装が計画から逸脱する必要がある場合:
- **何が**変わったかを記録
- **なぜ**変わったかを記録
- 修正されたアプローチで続行
- これらの逸脱はレポートに記録されます
**チェックポイント**: すべてのタスクを実行完了。逸脱を記録済み。
---
## フェーズ 4 — バリデーション
計画のすべてのバリデーションレベルを実行します。各レベルで問題を修正してから次に進みます。
### レベル 1: 静的解析
```bash
# 型チェック — エラーゼロが必須
[project type-check command]
# リント — 可能な場合は自動修正
[project lint command]
[project lint-fix command]
```
自動修正後もリントエラーが残る場合は、手動で修正します。
### レベル 2: ユニットテスト
すべての新しい関数にテストを書きます（計画のテスト戦略で指定されたとおり）。
```bash
[project test command for affected area]
```
- すべての関数に少なくとも1つのテストが必要
- 計画に記載されたエッジケースをカバー
- テストが失敗した場合 → 実装を修正します（テストが間違っている場合を除き、テストではなく実装を修正）
### レベル 3: ビルドチェック
```bash
[project build command]
```
ビルドはエラーゼロで成功する必要があります。
### レベル 4: 統合テスト（該当する場合）
```bash
# サーバーを起動し、テストを実行し、サーバーを停止
[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 — レポート
### 実装レポートの作成
```bash
mkdir -p .claude/PRPs/reports
```
レポートを `.claude/PRPs/reports/{plan-name}-report.md` に書き込みます:
```markdown
# 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 フェーズの一部だった場合:
1. フェーズのステータスを `in-progress` から `complete` に更新
2. レポートパスを参照として追加
### 計画のアーカイブ
```bash
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` で先に変更をレビューしてください。
```
---
## 失敗時の対処
### 型チェックの失敗
1. エラーメッセージを注意深く読む
2. ソースファイルの型エラーを修正
3. 型チェックを再実行
4. クリーンになってから次に進む
### テストの失敗
1. バグが実装にあるのかテストにあるのかを特定
2. 根本原因を修正（通常は実装側）
3. テストを再実行
4. グリーンになってから次に進む
### リントの失敗
1. まず自動修正を実行
2. エラーが残る場合は手動で修正
3. リントを再実行
4. クリーンになってから次に進む
### ビルドの失敗
1. 通常は型またはインポートの問題 — エラーメッセージを確認
2. 問題のあるファイルを修正
3. ビルドを再実行
4. 成功してから次に進む
### 統合テストの失敗
1. サーバーが正しく起動したか確認
2. エンドポイント/ルートが存在するか確認
3. リクエスト形式が期待どおりか確認
4. 修正して再実行
---
## 成功基準
- **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 にさらにフェーズがある場合）

502
docs/ja-JP/commands/prp-plan.md Normal file
View File

@@ -0,0 +1,502 @@
---
description: コードベース分析とパターン抽出を伴う包括的な機能実装計画を作成する
argument-hint: <機能の説明 | path/to/prd.md>
---
> PRPs-agentic-eng by Wirasm から適応。PRPワークフローシリーズの一部。
# PRP Plan
単一パスで機能を実装するために必要なすべてのコードベースパターン、規約、コンテキストを捉えた詳細で自己完結型の実装計画を作成します。
**基本理念**: 優れた計画には、追加の質問なしに実装するために必要なすべてが含まれています。すべてのパターン、すべての規約、すべての注意点が一度捕捉され、全体を通して参照されます。
**黄金ルール**: 実装中にコードベースを検索する必要がある場合、その知識を今すぐ計画に取り込んでください。
---
## フェーズ 0 — DETECT（検出）
`$ARGUMENTS` から入力タイプを判定します:
| 入力パターン | 検出 | アクション |
|---|---|---|
| `.prd.md` で終わるパス | PRDへのファイルパス | PRDを解析し、次の保留中のフェーズを見つける |
| "Implementation Phases" を含む `.md` へのパス | PRDに類似した文書 | フェーズを解析し、次の保留中を見つける |
| その他のファイルへのパス | 参照ファイル | コンテキストのためにファイルを読み、自由形式として扱う |
| 自由形式テキスト | 機能の説明 | フェーズ1に直接進む |
| 空白 / ブランク | 入力なし | ユーザーに計画する機能を尋ねる |
### PRD解析（入力がPRDの場合）
1. `cat "$PRD_PATH"` でPRDファイルを読み込む
2. **Implementation Phases** セクションを解析する
3. ステータスでフェーズを検索する:
- `pending`（保留中）のフェーズを探す
- 依存関係チェーンを確認する（あるフェーズは先行フェーズが `complete` であることに依存する場合がある）
- **次の適格な保留中フェーズ** を選択する
4. 選択したフェーズから以下を抽出する:
- フェーズ名と説明
- 受け入れ基準
- 先行フェーズへの依存関係
- スコープに関する注記や制約
5. フェーズの説明を計画する機能として使用する
保留中のフェーズが残っていない場合、すべてのフェーズが完了していることを報告します。
---
## フェーズ 1 — PARSE（解析）
機能要件を抽出し明確化します。
### 機能の理解
入力（PRDフェーズまたは自由形式の説明）から以下を特定します:
- **何を** 構築するのか（具体的な成果物）
- **なぜ** 重要なのか（ユーザー価値）
- **誰が** 使うのか（対象ユーザー/システム）
- **どこに** 位置するのか（コードベースのどの部分）
### ユーザーストーリー
以下の形式で記述します:
```
As a [ユーザーのタイプ],
I want [機能],
So that [メリット].
```
### 複雑さの評価
| レベル | 指標 | 典型的なスコープ |
|---|---|---|
| **Small** | 単一ファイル、独立した変更、新しい依存関係なし | 1-3ファイル、100行未満 |
| **Medium** | 複数ファイル、既存パターンに従う、軽微な新概念 | 3-10ファイル、100-500行 |
| **Large** | 横断的関心事、新しいパターン、外部統合 | 10+ファイル、500+行 |
| **XL** | アーキテクチャ変更、新サブシステム、マイグレーションが必要 | 20+ファイル、分割を検討 |
### 曖昧さゲート
以下のいずれかが不明確な場合、**続行する前にユーザーに確認してください**:
- コアの成果物が曖昧
- 成功基準が未定義
- 複数の有効な解釈が存在する
- 技術的アプローチに大きな未知数がある
推測しないでください。質問してください。仮定に基づいて構築された計画は実装時に失敗します。
---
## フェーズ 2 — EXPLORE（探索）
深いコードベースインテリジェンスを収集します。以下の各カテゴリについてコードベースを直接検索します。
### コードベース検索（8カテゴリ）
各カテゴリについて、grep、find、ファイル読み込みを使用して検索します:
1. **類似の実装** — 計画している機能に似た既存の機能を見つけます。類似のパターン、エンドポイント、コンポーネント、またはモジュールを探します。
2. **命名規約** — コードベースの関連エリアでファイル、関数、変数、クラス、エクスポートがどのように命名されているかを特定します。
3. **エラーハンドリング** — 類似のコードパスでエラーがどのようにキャッチ、伝播、ログ記録、ユーザーへの返却されるかを見つけます。
4. **ログパターン** — 何がログに記録され、どのレベルで、どの形式で記録されるかを特定します。
5. **型定義** — 関連する型、インターフェース、スキーマ、およびそれらの構成方法を見つけます。
6. **テストパターン** — 類似の機能がどのようにテストされているかを見つけます。テストファイルの場所、命名、セットアップ/ティアダウンパターン、アサーションスタイルに注目します。
7. **設定** — 関連する設定ファイル、環境変数、フィーチャーフラグを見つけます。
8. **依存関係** — 類似の機能で使用されているパッケージ、インポート、内部モジュールを特定します。
### コードベース分析（5つのトレース）
関連ファイルを読み込んでトレースします:
1. **エントリポイント** — リクエスト/アクションはどのようにシステムに入り、変更対象のエリアに到達するか？
2. **データフロー** — データは関連するコードパスをどのように流れるか？
3. **状態変更** — どの状態が変更され、どこで変更されるか？
4. **コントラクト** — どのインターフェース、API、プロトコルを遵守する必要があるか？
5. **パターン** — どのアーキテクチャパターンが使用されているか（リポジトリ、サービス、コントローラーなど）？
### 統合ディスカバリーテーブル
発見事項を単一のリファレンスにまとめます:
| カテゴリ | ファイル:行 | パターン | 主要スニペット |
|---|---|---|---|
| 命名 | `src/services/userService.ts:1-5` | キャメルケースのサービス、パスカルケースの型 | `export class UserService` |
| エラー | `src/middleware/errorHandler.ts:10-25` | カスタム AppError クラス | `throw new AppError(...)` |
| ... | ... | ... | ... |
---
## フェーズ 3 — RESEARCH（調査）
機能が外部ライブラリ、API、または馴染みのない技術を含む場合:
1. 公式ドキュメントをウェブで検索する
2. 使用例とベストプラクティスを見つける
3. バージョン固有の注意点を特定する
各発見事項を以下の形式で記述します:
```
KEY_INSIGHT: [学んだこと]
APPLIES_TO: [計画のどの部分に影響するか]
GOTCHA: [警告やバージョン固有の問題]
```
機能がよく理解された内部パターンのみを使用する場合、このフェーズをスキップし、「外部調査不要 — 機能は確立された内部パターンを使用」と記載します。
---
## フェーズ 4 — DESIGN（設計）
### UX変換（該当する場合）
変更前後のユーザー体験を文書化します:
**変更前:**
```
┌─────────────────────────────┐
│ [現在のユーザー体験] │
│ 現在のフローを示す、 │
│ ユーザーが見る/行うこと │
└─────────────────────────────┘
```
**変更後:**
```
┌─────────────────────────────┐
│ [新しいユーザー体験] │
│ 改善されたフローを示す、 │
│ ユーザーにとって何が変わるか│
└─────────────────────────────┘
```
### インタラクションの変更
| タッチポイント | 変更前 | 変更後 | 備考 |
|---|---|---|---|
| ... | ... | ... | ... |
機能が純粋にバックエンド/内部的でUXの変更がない場合、「内部変更 — ユーザー向けのUX変換なし」と記載します。
---
## フェーズ 5 — ARCHITECT（アーキテクチャ設計）
### 戦略的設計
実装アプローチを定義します:
- **アプローチ**: ハイレベルな戦略（例: 「既存のリポジトリパターンに従って新しいサービスレイヤーを追加」）
- **検討した代替案**: 他にどのようなアプローチが評価され、なぜ却下されたか
- **スコープ**: 構築する内容の具体的な境界
- **構築しないもの**: スコープ外であることの明示的なリスト（実装中のスコープクリープを防止）
---
## フェーズ 6 — GENERATE（生成）
以下のテンプレートを使用して完全な計画文書を作成します。`.claude/PRPs/plans/{kebab-case-feature-name}.plan.md` に保存します。
ディレクトリが存在しない場合は作成します:
```bash
mkdir -p .claude/PRPs/plans
```
### 計画テンプレート
````markdown
# Plan: [機能名]
## 概要
[2-3文の概要]
## ユーザーストーリー
As a [ユーザー], I want [機能], so that [メリット].
## 問題 → 解決策
[現在の状態] → [望ましい状態]
## メタデータ
- **複雑さ**: [Small | Medium | Large | XL]
- **ソースPRD**: [パスまたは "N/A"]
- **PRDフェーズ**: [フェーズ名または "N/A"]
- **推定ファイル数**: [数]
---
## UXデザイン
### 変更前
[ASCIIダイアグラムまたは "N/A — 内部変更"]
### 変更後
[ASCIIダイアグラムまたは "N/A — 内部変更"]
### インタラクションの変更
| タッチポイント | 変更前 | 変更後 | 備考 |
|---|---|---|---|
---
## 必読ファイル
実装前に必ず読むべきファイル:
| 優先度 | ファイル | 行 | 理由 |
|---|---|---|---|
| P0（重要） | `path/to/file` | 1-50 | 従うべきコアパターン |
| P1（重要） | `path/to/file` | 10-30 | 関連する型 |
| P2（参考） | `path/to/file` | all | 類似の実装 |
## 外部ドキュメント
| トピック | ソース | 主な要点 |
|---|---|---|
| ... | ... | ... |
---
## 模倣すべきパターン
コードベースで発見されたコードパターン。これらに正確に従ってください。
### NAMING_CONVENTION
// SOURCE: [file:lines]
[命名パターンを示す実際のコードスニペット]
### ERROR_HANDLING
// SOURCE: [file:lines]
[エラーハンドリングを示す実際のコードスニペット]
### LOGGING_PATTERN
// SOURCE: [file:lines]
[ログを示す実際のコードスニペット]
### REPOSITORY_PATTERN
// SOURCE: [file:lines]
[データアクセスを示す実際のコードスニペット]
### SERVICE_PATTERN
// SOURCE: [file:lines]
[サービスレイヤーを示す実際のコードスニペット]
### TEST_STRUCTURE
// SOURCE: [file:lines]
[テストセットアップを示す実際のコードスニペット]
---
## 変更対象ファイル
| ファイル | アクション | 根拠 |
|---|---|---|
| `path/to/file.ts` | CREATE | 機能用の新しいサービス |
| `path/to/existing.ts` | UPDATE | 新しいメソッドの追加 |
## 構築しないもの
- [スコープ外の明示的な項目1]
- [スコープ外の明示的な項目2]
---
## ステップバイステップのタスク
### タスク 1: [名前]
- **ACTION**: [何をするか]
- **IMPLEMENT**: [記述する具体的なコード/ロジック]
- **MIRROR**: [模倣すべきパターンセクションから従うパターン]
- **IMPORTS**: [必要なインポート]
- **GOTCHA**: [回避すべき既知の落とし穴]
- **VALIDATE**: [このタスクが正しいことを検証する方法]
### タスク 2: [名前]
- **ACTION**: ...
- **IMPLEMENT**: ...
- **MIRROR**: ...
- **IMPORTS**: ...
- **GOTCHA**: ...
- **VALIDATE**: ...
[すべてのタスクについて続行...]
---
## テスト戦略
### ユニットテスト
| テスト | 入力 | 期待される出力 | エッジケース？ |
|---|---|---|---|
| ... | ... | ... | ... |
### エッジケースチェックリスト
- [ ] 空の入力
- [ ] 最大サイズの入力
- [ ] 無効な型
- [ ] 並行アクセス
- [ ] ネットワーク障害（該当する場合）
- [ ] 権限拒否
---
## 検証コマンド
### 静的解析
```bash
# 型チェッカーを実行
[プロジェクト固有の型チェックコマンド]
```
EXPECT: 型エラーゼロ
### ユニットテスト
```bash
# 影響を受けるエリアのテストを実行
[プロジェクト固有のテストコマンド]
```
EXPECT: すべてのテストが合格
### フルテストスイート
```bash
# 完全なテストスイートを実行
[プロジェクト固有のフルテストコマンド]
```
EXPECT: リグレッションなし
### データベース検証（該当する場合）
```bash
# スキーマ/マイグレーションを検証
[プロジェクト固有のDBコマンド]
```
EXPECT: スキーマが最新
### ブラウザ検証（該当する場合）
```bash
# 開発サーバーを起動して検証
[プロジェクト固有の開発サーバーコマンド]
```
EXPECT: 機能が設計通りに動作
### 手動検証
- [ ] [ステップバイステップの手動検証チェックリスト]
---
## 受け入れ基準
- [ ] すべてのタスクが完了
- [ ] すべての検証コマンドが合格
- [ ] テストが作成され合格
- [ ] 型エラーなし
- [ ] リントエラーなし
- [ ] UXデザインと一致（該当する場合）
## 完了チェックリスト
- [ ] コードが発見されたパターンに従っている
- [ ] エラーハンドリングがコードベースのスタイルに一致
- [ ] ログがコードベースの規約に従っている
- [ ] テストがテストパターンに従っている
- [ ] ハードコードされた値がない
- [ ] ドキュメントが更新されている（必要な場合）
- [ ] 不要なスコープの追加がない
- [ ] 自己完結型 — 実装中に質問不要
## リスク
| リスク | 可能性 | 影響 | 軽減策 |
|---|---|---|---|
| ... | ... | ... | ... |
## 備考
[追加のコンテキスト、決定事項、または所見]
```
---
## 出力
### 計画の保存
生成した計画を以下に書き込みます:
```
.claude/PRPs/plans/{kebab-case-feature-name}.plan.md
```
### PRDの更新（入力がPRDの場合）
この計画がPRDフェーズから生成された場合:
1. フェーズのステータスを `pending` から `in-progress` に更新する
2. フェーズに計画ファイルのパスを参照として追加する
### ユーザーへの報告
```
## 計画作成完了
- **ファイル**: .claude/PRPs/plans/{kebab-case-feature-name}.plan.md
- **ソースPRD**: [パスまたは "N/A"]
- **フェーズ**: [フェーズ名または "standalone"]
- **複雑さ**: [レベル]
- **スコープ**: [Nファイル、Mタスク]
- **主要パターン**: [発見された上位3つのパターン]
- **外部調査**: [調査したトピックまたは "不要"]
- **リスク**: [最大のリスクまたは "特定なし"]
- **信頼度スコア**: [1-10] — 単一パス実装の成功見込み
> 次のステップ: `/prp-implement .claude/PRPs/plans/{name}.plan.md` を実行してこの計画を実行します。
```
---
## 検証
最終化する前に、以下のチェックリストに照らして計画を検証します:
### コンテキストの完全性
- [ ] すべての関連ファイルが発見され文書化されている
- [ ] 命名規約が例とともに捕捉されている
- [ ] エラーハンドリングパターンが文書化されている
- [ ] テストパターンが特定されている
- [ ] 依存関係がリスト化されている
### 実装準備状況
- [ ] すべてのタスクにACTION、IMPLEMENT、MIRROR、VALIDATEがある
- [ ] 追加のコードベース検索を必要とするタスクがない
- [ ] インポートパスが指定されている
- [ ] 該当箇所にGOTCHAが文書化されている
### パターンの忠実性
- [ ] コードスニペットは実際のコードベースの例である（作り上げたものではない）
- [ ] SOURCE参照が実際のファイルと行番号を指している
- [ ] パターンが命名、エラー、ログ、データアクセス、テストをカバーしている
- [ ] 新しいコードが既存のコードと区別がつかない
### 検証カバレッジ
- [ ] 静的解析コマンドが指定されている
- [ ] テストコマンドが指定されている
- [ ] ビルド検証が含まれている
### UXの明確性
- [ ] 変更前/変更後の状態が文書化されている（またはN/Aとマークされている）
- [ ] インタラクションの変更がリスト化されている
- [ ] UXのエッジケースが特定されている
### 事前知識不要テスト
このコードベースに馴染みのない開発者が、この計画のみを使用して、コードベースを検索したり質問したりすることなく機能を実装できる必要があります。できない場合は、不足しているコンテキストを追加してください。
---
## 次のステップ
- `/prp-implement <plan-path>` を実行してこの計画を実行する
- `/plan` を実行してアーティファクトなしの簡易な対話型計画を行う
- `/prp-prd` を実行してスコープが不明確な場合にまずPRDを作成する
````

184
docs/ja-JP/commands/prp-pr.md Normal file
View File

@@ -0,0 +1,184 @@
---
description: "現在のブランチからプッシュされていないコミットでGitHub PRを作成 — テンプレートの検出、変更の分析、プッシュ"
argument-hint: "[base-branch]（デフォルト: main）"
---
# プルリクエストの作成
> PRPs-agentic-engのWirasmによる適応。PRPワークフローシリーズの一部。
**入力**: `$ARGUMENTS` — オプション。ベースブランチ名やフラグ（例: `--draft`）を含む場合があります。
**`$ARGUMENTS`のパース**:
- 認識されたフラグを抽出（`--draft`）
- 残りの非フラグテキストをベースブランチ名として扱う
- 指定がなければベースブランチのデフォルトは`main`
---
## フェーズ 1 — VALIDATE
前提条件をチェック:
```bash
git branch --show-current
git status --short
git log origin/<base>..HEAD --oneline
```
| チェック | 条件 | 失敗時のアクション |
|---|---|---|
| ベースブランチにいない | 現在のブランチ ≠ base | 停止: "まずフィーチャーブランチに切り替えてください。" |
| クリーンなワーキングディレクトリ | コミットされていない変更がない | 警告: "コミットされていない変更があります。コミットまたはスタッシュしてください。`/prp-commit`でコミットしてください。" |
| 先行コミットがある | `git log origin/<base>..HEAD`が空でない | 停止: "`<base>`より先行するコミットがありません。PRにする内容がありません。" |
| 既存のPRがない | `gh pr list --head <branch> --json number`が空 | 停止: "PRは既に存在: #<number>。`gh pr view <number> --web`で開いてください。" |
すべてのチェックが通れば続行。
---
## フェーズ 2 — DISCOVER
### PRテンプレート
PRテンプレートを順番に検索:
1. `.github/PULL_REQUEST_TEMPLATE/`ディレクトリ — 存在する場合、ファイルを一覧しユーザーに選択させる（またはdefault.mdを使用）
2. `.github/PULL_REQUEST_TEMPLATE.md`
3. `.github/pull_request_template.md`
4. `docs/pull_request_template.md`
見つかった場合、読み取ってPR本文の構造に使用。
### コミット分析
```bash
git log origin/<base>..HEAD --format="%h %s" --reverse
```
コミットを分析して以下を決定:
- **PRタイトル**: タイププレフィックス付きのconventional commitフォーマットを使用 — `feat: ...`、`fix: ...`など
- 複数のタイプがある場合、支配的なものを使用
- 単一コミットの場合、そのメッセージをそのまま使用
- **変更サマリー**: タイプ/領域別にコミットをグループ化
### ファイル分析
```bash
git diff origin/<base>..HEAD --stat
git diff origin/<base>..HEAD --name-only
```
変更ファイルをカテゴリ分類: ソース、テスト、ドキュメント、設定、マイグレーション。
### PRPアーティファクト
関連するPRPアーティファクトを確認:
- `.claude/PRPs/reports/` — 実装レポート
- `.claude/PRPs/plans/` — 実行された計画
- `.claude/PRPs/prds/` — 関連PRD
存在する場合、PR本文で参照。
---
## フェーズ 3 — PUSH
```bash
git push -u origin HEAD
```
ダイバージェンスによりプッシュが失敗した場合:
```bash
git fetch origin
git rebase origin/<base>
git push -u origin HEAD
```
リベースコンフリクトが発生した場合、停止してユーザーに通知。
---
## フェーズ 4 — CREATE
### テンプレートあり
フェーズ 2でPRテンプレートが見つかった場合、コミットとファイル分析を使用して各セクションを記入。テンプレートのすべてのセクションを保持 — 該当しないセクションは削除せず"N/A"とする。
### テンプレートなし
このデフォルトフォーマットを使用:
```markdown
## Summary
<このPRが何をしてなぜかの1-2文の説明>
## Changes
<領域別にグループ化された変更の箇条書きリスト>
## Files Changed
<変更タイプ付きの変更ファイルのテーブルまたはリスト: Added/Modified/Deleted>
## Testing
<変更のテスト方法の説明、または"Needs testing">
## Related Issues
<Closes/Fixes/Relates to #Nでリンクされたイシュー、または"None">
```
### PRの作成
```bash
gh pr create \
--title "<PRタイトル>" \
--base <base-branch> \
--body "<PR本文>"
# $ARGUMENTSから--draftフラグがパースされた場合は--draftを追加
```
---
## フェーズ 5 — VERIFY
```bash
gh pr view --json number,url,title,state,baseRefName,headRefName,additions,deletions,changedFiles
gh pr checks --json name,status,conclusion 2>/dev/null || true
```
---
## フェーズ 6 — OUTPUT
ユーザーへの報告:
```
PR #<number>: <title>
URL: <url>
Branch: <head> → <base>
Changes: +<additions> -<deletions> across <changedFiles> files
CI Checks: <ステータスサマリー or "pending" or "none configured">
Artifacts referenced:
- <PR本文でリンクされたPRPレポート/計画>
Next steps:
- gh pr view <number> --web → ブラウザで開く
- /code-review <number> → PRをレビュー
- gh pr merge <number> → 準備ができたらマージ
```
---
## エッジケース
- **`gh` CLIがない**: 停止: "GitHub CLI (`gh`) が必要です。インストール: <https://cli.github.com/>"
- **未認証**: 停止: "まず `gh auth login` を実行してください。"
- **フォースプッシュが必要**: リモートがダイバージしてリベースが行われた場合、`git push --force-with-lease`を使用（`--force`は使わない）。
- **複数のPRテンプレート**: `.github/PULL_REQUEST_TEMPLATE/`に複数のファイルがある場合、一覧してユーザーに選択させる。
- **大きなPR（20ファイル超）**: PRサイズについて警告。変更が論理的に分離可能なら分割を提案。

447
docs/ja-JP/commands/prp-prd.md Normal file
View File

@@ -0,0 +1,447 @@
---
description: "対話型PRDジェネレーター - 問題起点・仮説駆動のプロダクト仕様書を対話的な質疑応答で作成"
argument-hint: "[機能/プロダクトのアイデア] (空白 = 質問から開始)"
---
# プロダクト要件定義書ジェネレーター
> PRPs-agentic-eng（Wirasm作）から適応。PRPワークフローシリーズの一部。
**入力**: $ARGUMENTS
---
## あなたの役割
あなたは鋭いプロダクトマネージャーであり：
- ソリューションではなく、問題から始める
- 構築する前にエビデンスを要求する
- 仕様ではなく、仮説で考える
- 想定する前に明確化のための質問をする
- 不確実性を正直に認める
**アンチパターン**: セクションを空虚な内容で埋めないこと。情報が不足している場合は、もっともらしい要件を捏造するのではなく「TBD - 調査が必要」と記載する。
---
## プロセス概要
```
質問セット1 → グラウンディング → 質問セット2 → リサーチ → 質問セット3 → 生成
```
各質問セットは前の回答をもとに構築される。グラウンディングフェーズでは前提条件を検証する。
---
## フェーズ1: 開始 - 核心的な問題
**入力が提供されていない場合**、以下を質問する：
> **何を構築したいですか？**
> プロダクト、機能、またはケイパビリティを数文で説明してください。
**入力が提供されている場合**、理解を言い換えて確認する：
> 以下を構築したいと理解しました: {言い換えた理解内容}
> これで正しいですか？それとも理解を修正すべきですか？
**ゲート**: ユーザーの応答を待ってから次に進む。
---
## フェーズ2: 基礎 - 問題の発見
以下の質問をする（全てを一度に提示し、ユーザーはまとめて回答可能）：
> **基礎的な質問：**
>
> 1. **誰が** この問題を抱えていますか？「ユーザー」だけでなく、どのような人物/役割か具体的に。
>
> 2. **何の** 問題に直面していますか？想定されるニーズではなく、観察可能なペインを説明してください。
>
> 3. **なぜ** 今日それを解決できないのですか？どのような代替手段が存在し、なぜそれらが不十分なのですか？
>
> 4. **なぜ今なのですか？** 何が変わって、これを構築する価値が生まれたのですか？
>
> 5. **どうやって** 解決できたと判断しますか？成功とはどのような状態ですか？
**ゲート**: ユーザーの応答を待ってから次に進む。
---
## フェーズ3: グラウンディング - 市場とコンテキストのリサーチ
基礎的な回答を得た後、リサーチを実施する：
**市場コンテキストのリサーチ：**
1. 市場における類似のプロダクト/機能を見つける
2. 競合がこの問題をどう解決しているか特定する
3. 一般的なパターンとアンチパターンを記録する
4. この分野における最近のトレンドや変化を確認する
直接リンク、主要なインサイト、利用可能な情報のギャップを含めて調査結果をまとめる。
**コードベースが存在する場合、並行して探索する：**
1. プロダクト/機能のアイデアに関連する既存の機能を見つける
2. 活用できるパターンを特定する
3. 技術的な制約や機会を記録する
ファイルの場所、コードパターン、観察された慣例を記録する。
**ユーザーへの調査結果の要約：**
> **判明したこと：**
> - {市場のインサイト1}
> - {競合のアプローチ}
> - {コードベースからの関連パターン（該当する場合）}
>
> これによって考えが変わったり、洗練されたりしますか？
**ゲート**: ユーザー入力のための短い一時停止（「続行」または調整が可能）。
---
## フェーズ4: 深掘り - ビジョンとユーザー
基礎 + リサーチに基づいて質問する：
> **ビジョンとユーザー：**
>
> 1. **ビジョン**: これが大成功した場合の理想的な最終状態を一文で述べてください。
>
> 2. **プライマリユーザー**: 最も重要なユーザーを説明してください - その役割、状況、ニーズを引き起こすトリガー。
>
> 3. **ジョブ・トゥ・ビー・ダン**: これを完成させてください：「[状況]のとき、[動機]したい。それにより[成果]を達成できる。」
>
> 4. **非ターゲットユーザー**: 明示的にターゲットでないのは誰ですか？無視すべきは誰ですか？
>
> 5. **制約**: どのような制限がありますか？（時間、予算、技術、規制）
**ゲート**: ユーザーの応答を待ってから次に進む。
---
## フェーズ5: グラウンディング - 技術的実現可能性
**コードベースが存在する場合、2つの並行調査を実施する：**
調査1 - 実現可能性の探索：
1. 活用可能な既存インフラストラクチャを特定する
2. 既に実装されている類似パターンを見つける
3. 統合ポイントと依存関係をマッピングする
4. 関連する設定と型定義を見つける
ファイルの場所、コードパターン、観察された慣例を記録する。
調査2 - 制約の分析：
1. 既存の関連機能がエンドツーエンドでどのように実装されているかを追跡する
2. 潜在的な統合ポイントを通じたデータフローをマッピングする
3. アーキテクチャパターンと境界を特定する
4. 類似機能に基づいて複雑さを見積もる
正確なファイル:行番号の参照とともに存在するものを文書化する。提案は不要。
**コードベースがない場合、技術的アプローチをリサーチする：**
1. 他者が使用した技術的アプローチを見つける
2. 一般的な実装パターンを特定する
3. 既知の技術的課題と落とし穴を記録する
引用とギャップ分析を含めて調査結果をまとめる。
**ユーザーへの要約：**
> **技術的コンテキスト：**
> - 実現可能性: {高/中/低} 理由: {理由}
> - 活用可能: {既存のパターン/インフラストラクチャ}
> - 主要な技術リスク: {主な懸念事項}
>
> 知っておくべき技術的制約はありますか？
**ゲート**: ユーザー入力のための短い一時停止。
---
## フェーズ6: 決定 - スコープとアプローチ
最終的な明確化の質問をする：
> **スコープとアプローチ：**
>
> 1. **MVP定義**: これが機能するかテストするための絶対的な最小限は何ですか？
>
> 2. **必須 vs あると良い**: v1に必ず含まれるべき2-3項目は何ですか？何が待てますか？
>
> 3. **主要仮説**: これを完成させてください：「我々は[機能]が[ユーザー]の[問題を解決する]と信じている。[測定可能な成果]が得られた時、我々の仮説が正しかったと判る。」
>
> 4. **スコープ外**: 明示的に構築しないものは何ですか（ユーザーが要求しても）？
>
> 5. **未解決の質問**: アプローチを変える可能性のある不確実性は何ですか？
**ゲート**: ユーザーの応答を待ってから生成する。
---
## フェーズ7: 生成 - PRDの作成
**出力パス**: `.claude/PRPs/prds/{ケバブケース名}.prd.md`
必要に応じてディレクトリを作成する: `mkdir -p .claude/PRPs/prds`
### PRDテンプレート
```markdown
# {プロダクト/機能名}
## 問題の記述
{2-3文: 誰がどのような問題を抱えていて、解決しないことのコストは何か？}
## エビデンス
- {この問題が存在することを証明するユーザーの引用、データポイント、または観察}
- {もう1つのエビデンス}
- {ない場合: 「仮定 - [方法]による検証が必要」}
## 提案するソリューション
{1段落: 何を構築するのか、なぜ代替案ではなくこのアプローチなのか}
## 主要仮説
我々は{機能}が{ユーザー}の{問題を解決する}と信じている。
{測定可能な成果}が得られた時、我々の仮説が正しかったと判る。
## 構築しないもの
- {スコープ外の項目1} - {理由}
- {スコープ外の項目2} - {理由}
## 成功指標
| 指標 | 目標 | 測定方法 |
|------|------|----------|
| {主要指標} | {具体的な数値} | {方法} |
| {副次指標} | {具体的な数値} | {方法} |
## 未解決の質問
- [ ] {未解決の質問1}
- [ ] {未解決の質問2}
---
## ユーザーとコンテキスト
**プライマリユーザー**
- **誰**: {具体的な説明}
- **現在の行動**: {現在行っていること}
- **トリガー**: {ニーズを引き起こす瞬間}
- **成功状態**: {「完了」がどのような状態か}
**ジョブ・トゥ・ビー・ダン**
{状況}のとき、{動機}したい。それにより{成果}を達成できる。
**非ターゲットユーザー**
{誰がターゲットでないか、その理由}
---
## ソリューション詳細
### コアケイパビリティ (MoSCoW)
| 優先度 | ケイパビリティ | 根拠 |
|--------|---------------|------|
| Must | {機能} | {なぜ必須か} |
| Must | {機能} | {なぜ必須か} |
| Should | {機能} | {なぜ重要だがブロッカーではないか} |
| Could | {機能} | {あると良い} |
| Won't | {機能} | {明示的に延期する理由} |
### MVPスコープ
{仮説を検証するための最小限は何か}
### ユーザーフロー
{クリティカルパス - 価値への最短経路}
---
## 技術的アプローチ
**実現可能性**: {高/中/低}
**アーキテクチャノート**
- {主要な技術的決定とその理由}
- {依存関係または統合ポイント}
**技術的リスク**
| リスク | 可能性 | 軽減策 |
|--------|--------|--------|
| {リスク} | {高/中/低} | {対処方法} |
---
## 実装フェーズ
<!--
STATUS: pending | in-progress | complete
PARALLEL: 同時実行可能なフェーズ（例: "with 3" または "-"）
DEPENDS: 先に完了すべきフェーズ（例: "1, 2" または "-"）
PRP: 生成された計画ファイルへのリンク（作成後）
-->
| # | フェーズ | 説明 | ステータス | 並行 | 依存 | PRP計画 |
|---|---------|------|----------|------|------|---------|
| 1 | {フェーズ名} | {このフェーズが提供するもの} | pending | - | - | - |
| 2 | {フェーズ名} | {このフェーズが提供するもの} | pending | - | 1 | - |
| 3 | {フェーズ名} | {このフェーズが提供するもの} | pending | with 4 | 2 | - |
| 4 | {フェーズ名} | {このフェーズが提供するもの} | pending | with 3 | 2 | - |
| 5 | {フェーズ名} | {このフェーズが提供するもの} | pending | - | 3, 4 | - |
### フェーズ詳細
**フェーズ1: {名前}**
- **目標**: {達成しようとしていること}
- **スコープ**: {限定された成果物}
- **成功シグナル**: {完了したと判断する方法}
**フェーズ2: {名前}**
- **目標**: {達成しようとしていること}
- **スコープ**: {限定された成果物}
- **成功シグナル**: {完了したと判断する方法}
{各フェーズについて続ける...}
### 並行処理ノート
{どのフェーズが並行実行可能か、その理由を説明する}
---
## 決定ログ
| 決定事項 | 選択 | 代替案 | 根拠 |
|----------|------|--------|------|
| {決定事項} | {選択} | {検討したオプション} | {この選択の理由} |
---
## リサーチサマリー
**市場コンテキスト**
{市場リサーチからの主要な発見}
**技術的コンテキスト**
{技術的探索からの主要な発見}
---
*生成日時: {timestamp}*
*ステータス: ドラフト - 検証が必要*
```
---
## フェーズ8: 出力 - サマリー
生成後に以下を報告する：
```markdown
## PRD作成完了
**ファイル**: `.claude/PRPs/prds/{name}.prd.md`
### サマリー
**問題**: {一行}
**ソリューション**: {一行}
**主要指標**: {主要な成功指標}
### 検証ステータス
| セクション | ステータス |
|-----------|-----------|
| 問題の記述 | {検証済み/仮定} |
| ユーザーリサーチ | {完了/必要} |
| 技術的実現可能性 | {評価済み/TBD} |
| 成功指標 | {定義済み/要改善} |
### 未解決の質問 ({count})
{回答が必要な未解決の質問を一覧表示する}
### 推奨する次のステップ
{以下のいずれか: ユーザーリサーチ、技術スパイク、プロトタイプ、ステークホルダーレビューなど}
### 実装フェーズ
| # | フェーズ | ステータス | 並行可能 |
|---|---------|----------|---------|
{PRDからのフェーズ一覧}
### 実装を開始するには
実行: `/prp-plan .claude/PRPs/prds/{name}.prd.md`
これにより自動的に次の保留中のフェーズが選択され、実装計画が作成されます。
```
---
## 質問フローのサマリー
```
┌─────────────────────────────────────────────────────────┐
│ 開始: 「何を構築したいですか？」 │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 基礎: 誰が、何を、なぜ、なぜ今、どう測定するか │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ グラウンディング: 市場リサーチ、競合分析 │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 深掘り: ビジョン、プライマリユーザー、JTBD、制約 │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ グラウンディング: 技術的実現可能性、コードベース探索 │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 決定: MVP、必須事項、仮説、スコープ外 │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 生成: PRDを .claude/PRPs/prds/ に出力 │
└─────────────────────────────────────────────────────────┘
```
---
## ECCとの連携
PRD生成後：
- `/prp-plan` を使用してPRDのフェーズから実装計画を作成する
- `/plan` を使用してPRD構造なしのシンプルな計画を作成する
- `/save-session` を使用してセッション間でPRDコンテキストを保持する
## 成功基準
- **PROBLEM_VALIDATED**: 問題が具体的でエビデンスに基づいている（または仮定として明記されている）
- **USER_DEFINED**: プライマリユーザーが具体的であり、汎用的でない
- **HYPOTHESIS_CLEAR**: 測定可能な成果を伴うテスト可能な仮説
- **SCOPE_BOUNDED**: 明確な必須事項と明示的なスコープ外
- **QUESTIONS_ACKNOWLEDGED**: 不確実性が隠されずにリストアップされている
- **ACTIONABLE**: 懐疑的な人でも、なぜこれを構築する価値があるか理解できる

31
docs/ja-JP/commands/prune.md Normal file
View File

@@ -0,0 +1,31 @@
---
name: prune
description: プロモートされなかった30日以上経過の保留中インスティンクトを削除
command: true
---
# 保留中インスティンクトの整理
自動生成されたがレビューまたはプロモートされなかった期限切れの保留中インスティンクトを削除します。
## 実装
プラグインルートパスを使用してインスティンクトCLIを実行:
```bash
python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" prune
```
または`CLAUDE_PLUGIN_ROOT`が設定されていない場合（手動インストール）:
```bash
python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py prune
```
## 使い方
```
/prune # 30日以上のインスティンクトを削除
/prune --max-age 60 # カスタム経過閾値（日数）
/prune --dry-run # 削除せずにプレビュー
```

33
docs/ja-JP/commands/quality-gate.md Normal file
View File

@@ -0,0 +1,33 @@
---
description: ファイルまたはプロジェクトスコープでECC品質パイプラインを実行し、修正手順を報告します。
---
# 品質ゲートコマンド
ファイルまたはプロジェクトスコープに対してECC品質パイプラインをオンデマンドで実行します。
## 使い方
`/quality-gate [path|.] [--fix] [--strict]`
- デフォルトターゲット: 現在のディレクトリ（`.`）
- `--fix`: 設定されている箇所で自動フォーマット/修正を許可
- `--strict`: サポートされている箇所で警告時にも失敗
## パイプライン
1. ターゲットの言語/ツールを検出。
2. フォーマッターチェックを実行。
3. リント/型チェックを利用可能な場合に実行。
4. 簡潔な修正リストを出力。
## 注意事項
このコマンドはフックの動作をミラーしますが、オペレーターが呼び出すものです。
## 引数
$ARGUMENTS:
- `[path|.]` オプションのターゲットパス
- `--fix` オプション
- `--strict` オプション

156
docs/ja-JP/commands/resume-session.md Normal file
View File

@@ -0,0 +1,156 @@
---
description: ~/.claude/session-data/ から最新のセッションファイルを読み込み、前回のセッションが終了した時点の完全なコンテキストを使って作業を再開します。
---
# セッション再開コマンド
最後に保存されたセッション状態を読み込み、作業を開始する前に完全に状況を把握します。
このコマンドは `/save-session` の対になるものです。
## 使用するタイミング
- 前日の作業を引き継いで新しいセッションを開始するとき
- コンテキストの上限に達して新しいセッションを開始した後
- 別のソースからセッションファイルを受け渡されたとき（ファイルパスを指定するだけです）
- セッションファイルがあり、Claude に作業を続行する前に完全に内容を把握させたいとき
## 使い方
```
/resume-session # ~/.claude/session-data/ の最新ファイルを読み込む
/resume-session 2024-01-15 # その日付の最新セッションを読み込む
/resume-session ~/.claude/session-data/2024-01-15-abc123de-session.tmp # 現在の短縮IDセッションファイルを読み込む
/resume-session ~/.claude/sessions/2024-01-15-session.tmp # レガシー形式の特定ファイルを読み込む
```
## プロセス
### ステップ 1: セッションファイルを見つける
引数が指定されていない場合:
1. `~/.claude/session-data/` を確認する
2. 最も新しく更新された `*-session.tmp` ファイルを選択する
3. フォルダが存在しないか、一致するファイルがない場合、ユーザーに以下を通知する:
```
No session files found in ~/.claude/session-data/
Run /save-session at the end of a session to create one.
```
その後停止する。
引数が指定されている場合:
- 日付形式（`YYYY-MM-DD`）の場合、まず `~/.claude/session-data/` を検索し、次にレガシーの
`~/.claude/sessions/` を検索して、`YYYY-MM-DD-session.tmp`（レガシー形式）または
`YYYY-MM-DD-<shortid>-session.tmp`（現在の形式）に一致するファイルを探し、
その日付で最も新しく更新されたものを読み込む
- ファイルパスの場合、そのファイルを直接読み取る
- 見つからない場合、明確に報告して停止する
### ステップ 2: セッションファイル全体を読み取る
ファイル全体を読み取る。まだ要約はしない。
### ステップ 3: 理解を確認する
以下の正確な形式で構造化されたブリーフィングを返答する:
```
SESSION LOADED: [ファイルへの実際の解決済みパス]
════════════════════════════════════════════════
PROJECT: [ファイルに記載されたプロジェクト名 / トピック]
WHAT WE'RE BUILDING:
[自分の言葉で2〜3文の要約]
CURRENT STATE:
PASS: Working: [数] 件確認済み
In Progress: [進行中のファイル一覧]
Not Started: [計画済みだが未着手の一覧]
WHAT NOT TO RETRY:
[失敗したアプローチとその理由をすべて列挙 -- これは非常に重要]
OPEN QUESTIONS / BLOCKERS:
[ブロッカーや未回答の質問を列挙]
NEXT STEP:
[ファイルに定義されている場合は正確な次のステップ]
[定義されていない場合: "No next step defined -- recommend reviewing 'What Has NOT Been Tried Yet' together before starting"]
════════════════════════════════════════════════
Ready to continue. What would you like to do?
```
### ステップ 4: ユーザーを待つ
自動的に作業を開始しない。ファイルに触れない。ユーザーの指示を待つ。
次のステップがセッションファイルに明確に定義されており、ユーザーが「続けて」「はい」などと言った場合、その正確な次のステップを実行する。
次のステップが定義されていない場合、どこから始めるかをユーザーに尋ね、必要に応じて「まだ試していないこと」セクションからアプローチを提案する。
---
## エッジケース
**同じ日付に複数のセッションがある場合** (`2024-01-15-session.tmp`, `2024-01-15-abc123de-session.tmp`):
レガシーのID無し形式か現在の短縮ID形式かに関係なく、その日付で最も新しく更新された一致ファイルを読み込む。
**セッションファイルが存在しないファイルを参照している場合:**
ブリーフィング中にこれを注記する -- "WARNING: `path/to/file.ts` referenced in session but not found on disk."
**セッションファイルが7日以上前のものである場合:**
間隔を注記する -- "WARNING: This session is from N days ago (threshold: 7 days). Things may have changed." -- その後通常通り進める。
**ユーザーがファイルパスを直接指定した場合（例: チームメイトから転送された場合）:**
それを読み取り、同じブリーフィングプロセスに従う -- ソースに関係なく形式は同じ。
**セッションファイルが空または不正な形式の場合:**
報告する: "Session file found but appears empty or unreadable. You may need to create a new one with /save-session."
---
## 出力例
```
SESSION LOADED: /Users/you/.claude/session-data/2024-01-15-abc123de-session.tmp
════════════════════════════════════════════════
PROJECT: my-app — JWT Authentication
WHAT WE'RE BUILDING:
User authentication with JWT tokens stored in httpOnly cookies.
Register and login endpoints are partially done. Route protection
via middleware hasn't been started yet.
CURRENT STATE:
PASS: Working: 3 items (register endpoint, JWT generation, password hashing)
In Progress: app/api/auth/login/route.ts (token works, cookie not set yet)
Not Started: middleware.ts, app/login/page.tsx
WHAT NOT TO RETRY:
FAIL: Next-Auth — conflicts with custom Prisma adapter, threw adapter error on every request
FAIL: localStorage for JWT — causes SSR hydration mismatch, incompatible with Next.js
OPEN QUESTIONS / BLOCKERS:
- Does cookies().set() work inside a Route Handler or only Server Actions?
NEXT STEP:
In app/api/auth/login/route.ts — set the JWT as an httpOnly cookie using
cookies().set('token', jwt, { httpOnly: true, secure: true, sameSite: 'strict' })
then test with Postman for a Set-Cookie header in the response.
════════════════════════════════════════════════
Ready to continue. What would you like to do?
```
---
## 注意事項
- セッションファイルを読み込む際に変更しない -- 読み取り専用の履歴記録である
- ブリーフィングの形式は固定 -- セクションが空であっても省略しない
- 「再試行してはいけないこと」は常に表示する。たとえ「なし」であっても -- 見落とすには重要すぎる
- 再開後、ユーザーは新しいセッションの終了時に `/save-session` を再度実行して、新しい日付のファイルを作成したい場合がある

37
docs/ja-JP/commands/review-pr.md Normal file
View File

@@ -0,0 +1,37 @@
---
description: 特化エージェントを使用した包括的なPRレビュー
---
プルリクエストの包括的なマルチパースペクティブレビューを実行します。
## 使い方
`/review-pr [PR番号またはURL] [--focus=comments|tests|errors|types|code|simplify]`
PRが指定されていない場合、現在のブランチのPRをレビューします。focusが指定されていない場合、フルレビュースタックを実行します。
## ステップ
1. PRを特定:
- `gh pr view`を使用してPRの詳細、変更ファイル、diffを取得
2. プロジェクトガイダンスを検索:
- `CLAUDE.md`、リント設定、TypeScript設定、リポジトリ規約を探す
3. 特化レビューエージェントを実行:
- `code-reviewer`
- `comment-analyzer`
- `pr-test-analyzer`
- `silent-failure-hunter`
- `type-design-analyzer`
- `code-simplifier`
4. 結果を集約:
- 重複する所見を排除
- 重大度でランク付け
5. 重大度別にグループ化して所見を報告
## 信頼度ルール
信頼度80以上の問題のみ報告:
- Critical: バグ、セキュリティ、データ損失
- Important: テストの欠落、品質問題、スタイル違反
- Advisory: 明示的に要求された場合のみ提案

187
docs/ja-JP/commands/rust-build.md Normal file
View File

@@ -0,0 +1,187 @@
---
description: Rustビルドエラー、ボローチェッカーの問題、依存関係の問題をインクリメンタルに修正します。最小限の外科的修正のためにrust-build-resolverエージェントを呼び出します。
---
# Rustビルドと修正
このコマンドは**rust-build-resolver**エージェントを呼び出し、Rustビルドエラーを最小限の変更でインクリメンタルに修正します。
## このコマンドの動作
1. **診断を実行**: `cargo check`、`cargo clippy`、`cargo fmt --check`を実行
2. **エラーを解析**: エラーコードと影響を受けるファイルを特定
3. **インクリメンタルに修正**: 一度に1つのエラー
4. **各修正を検証**: 各変更後に`cargo check`を再実行
5. **サマリーを報告**: 修正されたものと残りを表示
## 使用するタイミング
`/rust-build`を使用するのは:
- `cargo build`または`cargo check`がエラーで失敗する場合
- `cargo clippy`が警告を報告する場合
- ボローチェッカーやライフタイムエラーがコンパイルをブロックする場合
- Cargo依存関係の解決が失敗する場合
- ビルドを壊す変更をプルした後
## 実行される診断コマンド
```bash
# プライマリビルドチェック
cargo check 2>&1
# リントと提案
cargo clippy -- -D warnings 2>&1
# フォーマットチェック
cargo fmt --check 2>&1
# 依存関係の問題
cargo tree --duplicates
# セキュリティ監査（利用可能な場合）
if command -v cargo-audit >/dev/null; then cargo audit; else echo "cargo-audit not installed"; fi
```
## セッション例
````text
User: /rust-build
Agent:
# Rustビルド解決
## 初期診断
```bash
$ cargo check
error[E0502]: cannot borrow `map` as mutable because it is also borrowed as immutable
--> src/service/cache.rs:25:5
error[E0308]: mismatched types
--> src/handler/api.rs:42:12
error[E0425]: cannot find value `db` in this scope
--> src/handler/api.rs:58:9
```
検出されたエラー: 3
## 修正 1: ボローチェッカーエラー
File: src/service/cache.rs:25
Error: E0502 — イミュータブルとしてもボローされているため、`map`をミュータブルとしてボローできない
Cause: ミュータブルなinsert中にイミュータブルなボローがまだアクティブ
```rust
// 変更: ミュータブルアクセス前にイミュータブルなボローを終了するよう再構築
if !map.contains_key("key") {
map.insert("key".into(), default);
}
```
```bash
$ cargo check
# 残りエラー: 2
```
## 修正 2: 型の不一致
File: src/handler/api.rs:42
Error: E0308 — mismatched types: expected `usize`, found `&str`
```rust
// 変更前
let count = params.get("count");
// 変更後
let count: usize = params.get("count")
.and_then(|s| s.parse().ok())
.unwrap_or(0);
```
```bash
$ cargo check
# 残りエラー: 1
```
## 修正 3: 未解決の名前
File: src/handler/api.rs:58
Error: E0425 — cannot find value `db` in this scope
Cause: importの欠落
```rust
// 追加
use crate::db;
```
```bash
$ cargo check
# ビルド成功！
```
## 最終検証
```bash
$ cargo clippy -- -D warnings
# 警告なし
$ cargo test
running 6 tests
test service::cache::tests::test_insert ... ok
test service::cache::tests::test_get ... ok
test handler::api::tests::test_parse_count ... ok
test handler::api::tests::test_missing_count ... ok
test handler::api::tests::test_db_import ... ok
test handler::api::tests::test_response ... ok
test result: ok. 6 passed; 0 failed; 0 ignored
```
## サマリー
| メトリクス | 件数 |
|-----------|------|
| 修正されたビルドエラー | 3 |
| 修正されたClippy警告 | 0 |
| 変更されたファイル | 2 |
| 残りの問題 | 0 |
ビルドステータス: SUCCESS
````
## 一般的に修正されるエラー
| エラー | 典型的な修正 |
|--------|-------------|
| `cannot borrow as mutable` | イミュータブルなボローを先に終了するよう再構築。cloneは正当化された場合のみ |
| `does not live long enough` | 所有型を使用またはライフタイム注釈を追加 |
| `cannot move out of` | 所有権を取るよう再構築。cloneは最後の手段としてのみ |
| `mismatched types` | `.into()`、`as`、または明示的な変換を追加 |
| `trait X not implemented` | `#[derive(Trait)]`を追加または手動で実装 |
| `unresolved import` | Cargo.tomlに追加または`use`パスを修正 |
| `cannot find value` | importを追加またはパスを修正 |
## 修正戦略
1. **ビルドエラーを最初に** — コードがコンパイルされなければならない
2. **Clippy警告を次に** — 疑わしい構造を修正
3. **フォーマットを3番目に** — `cargo fmt`準拠
4. **一度に1つの修正** — 各変更を検証
5. **最小限の変更** — リファクタリングせず、修正のみ
## 停止条件
エージェントは以下の場合に停止して報告する:
- 3回の試行後も同じエラーが持続
- 修正がより多くのエラーを導入
- アーキテクチャ変更が必要
- ボローチェッカーエラーがデータ所有権の再設計を必要とする
## 関連コマンド
- `/rust-test` — ビルド成功後にテストを実行
- `/rust-review` — コード品質をレビュー
- `verification-loop`スキル — 完全な検証ループ
## 関連
- エージェント: `agents/rust-build-resolver.md`
- スキル: `skills/rust-patterns/`

142
docs/ja-JP/commands/rust-review.md Normal file
View File

@@ -0,0 +1,142 @@
---
description: Rustコードの所有権、ライフタイム、エラーハンドリング、unsafeの使用、イディオマティックパターンに関する包括的なコードレビュー。rust-reviewerエージェントを呼び出します。
---
# Rustコードレビュー
このコマンドは**rust-reviewer**エージェントを呼び出し、Rust固有の包括的なコードレビューを行います。
## このコマンドの動作
1. **自動チェックを検証**: `cargo check`、`cargo clippy -- -D warnings`、`cargo fmt --check`、`cargo test`を実行 — いずれか失敗したら停止
2. **Rustの変更を特定**: `git diff HEAD~1`（PRの場合は`git diff main...HEAD`）で変更された`.rs`ファイルを検出
3. **セキュリティ監査を実行**: 利用可能な場合`cargo audit`を実行
4. **セキュリティスキャン**: unsafe使用、コマンドインジェクション、ハードコードされたシークレットを確認
5. **所有権レビュー**: 不要なclone、ライフタイムの問題、ボローイングパターンを分析
6. **レポートを生成**: 重大度別に問題を分類
## 使用するタイミング
`/rust-review`を使用するのは:
- Rustコードを書いたり変更した後
- Rustの変更をコミットする前
- Rustコードを含むプルリクエストをレビューする時
- 新しいRustコードベースにオンボーディングする時
- イディオマティックなRustパターンを学ぶ時
## レビューカテゴリ
### CRITICAL（修正必須）
- プロダクションコードパスでの未チェック`unwrap()`/`expect()`
- 不変条件を文書化する`// SAFETY:`コメントなしの`unsafe`
- クエリでの文字列補間によるSQLインジェクション
- `std::process::Command`での未検証入力によるコマンドインジェクション
- ハードコードされた認証情報
- rawポインタ経由のuse-after-free
### HIGH（修正すべき）
- ボローチェッカーを満たすための不要な`.clone()`
- `&str`や`impl AsRef<str>`で十分な場合の`String`パラメータ
- asyncコンテキストでのブロッキング（`std::thread::sleep`、`std::fs`）
- 共有型での`Send`/`Sync`バウンドの欠落
- ビジネスクリティカルなenumでのワイルドカード`_ =>`マッチ
- 大きな関数（50行超）
### MEDIUM（検討すべき）
- ホットパスでの不要なアロケーション
- サイズが既知の場合の`with_capacity`の欠落
- 正当化なしの抑制されたclippy警告
- `///`ドキュメントなしのパブリックAPI
- 値を無視することがバグになりやすい非`must_use`戻り値型での`#[must_use]`の検討
## 実行される自動チェック
```bash
# ビルドゲート（レビュー前に通る必要あり）
cargo check
# リントと提案
cargo clippy -- -D warnings
# フォーマット
cargo fmt --check
# テスト
cargo test
# セキュリティ監査（利用可能な場合）
if command -v cargo-audit >/dev/null; then cargo audit; else echo "cargo-audit not installed"; fi
```
## 使用例
````text
User: /rust-review
Agent:
# Rustコードレビューレポート
## レビュー対象ファイル
- src/service/user.rs（変更）
- src/handler/api.rs（変更）
## 静的解析結果
- ビルド: 成功
- Clippy: 警告なし
- フォーマット: 通過
- テスト: 全通過
## 検出された問題
[CRITICAL] プロダクションパスでの未チェックunwrap
File: src/service/user.rs:28
Issue: データベースクエリ結果に`.unwrap()`を使用
```rust
let user = db.find_by_id(id).unwrap(); // ユーザーが見つからない場合にパニック
```
Fix: コンテキスト付きでエラーを伝搬
```rust
let user = db.find_by_id(id)
.context("failed to fetch user")?;
```
[HIGH] 不要なClone
File: src/handler/api.rs:45
Issue: ボローチェッカーを満たすためにStringをクローン
```rust
let name = user.name.clone();
process(&user, &name);
```
Fix: cloneを回避するよう再構築
```rust
let result = process_name(&user.name);
use_user(&user, result);
```
## サマリー
- CRITICAL: 1
- HIGH: 1
- MEDIUM: 0
推奨: CRITICALの問題が修正されるまでマージをブロック
````
## 承認基準
| ステータス | 条件 |
|-----------|------|
| 承認 | CRITICALまたはHIGHの問題がない |
| 警告 | MEDIUMの問題のみ（注意してマージ） |
| ブロック | CRITICALまたはHIGHの問題が検出 |
## 他のコマンドとの統合
- まず`/rust-test`を使用してテストが通ることを確認
- ビルドエラーが発生した場合は`/rust-build`を使用
- コミット前に`/rust-review`を使用
- Rust固有でない懸念には`/code-review`を使用
## 関連
- エージェント: `agents/rust-reviewer.md`
- スキル: `skills/rust-patterns/`、`skills/rust-testing/`

308
docs/ja-JP/commands/rust-test.md Normal file
View File

@@ -0,0 +1,308 @@
---
description: RustにおけるTDDワークフローを強制します。テストを先に書き、その後に実装します。cargo-llvm-covで80%以上のカバレッジを検証します。
---
# Rust TDD コマンド
このコマンドは、`#[test]`、rstest、proptest、mockall を使用した Rust コードのテスト駆動開発手法を強制します。
## このコマンドの機能
1. **型/トレイトの定義**: `todo!()` で関数シグネチャをスキャフォールドする
2. **テストの作成**: 包括的なテストモジュールを作成する（RED）
3. **テストの実行**: テストが正しい理由で失敗することを確認する
4. **コードの実装**: テストを通過する最小限のコードを書く（GREEN）
5. **リファクタリング**: テストをグリーンに保ちながら改善する
6. **カバレッジの確認**: cargo-llvm-cov で80%以上のカバレッジを確保する
## 使用するタイミング
以下の場合に `/rust-test` を使用してください：
- 新しい Rust の関数、メソッド、トレイトを実装する場合
- 既存の Rust コードにテストカバレッジを追加する場合
- バグを修正する場合（先に失敗するテストを書く）
- 重要なビジネスロジックを構築する場合
- Rust での TDD ワークフローを学習する場合
## TDD サイクル
```
RED -> 先に失敗するテストを書く
GREEN -> テストを通過する最小限のコードを実装する
REFACTOR -> コードを改善し、テストはグリーンを維持する
REPEAT -> 次のテストケースへ
```
## セッション例
````text
User: /rust-test ユーザー登録を検証する関数が必要です
エージェント:
# TDD セッション: 登録バリデーター
## ステップ 1: インターフェースの定義
```rust
// src/validator.rs
pub struct RegistrationRequest {
pub name: String,
pub email: String,
pub password: String,
}
pub enum ValidationResult {
Valid,
Invalid(Vec<String>),
}
pub fn validate_registration(request: &RegistrationRequest) -> ValidationResult {
todo!()
}
```
## ステップ 2: テストの作成（RED）
```rust
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn valid_registration_returns_valid() {
let request = RegistrationRequest {
name: "Alice".into(),
email: "alice@example.com".into(),
password: "SecureP@ss1".into(),
};
assert!(matches!(validate_registration(&request), ValidationResult::Valid));
}
#[test]
fn blank_name_returns_invalid() {
let request = RegistrationRequest {
name: "".into(),
email: "alice@example.com".into(),
password: "SecureP@ss1".into(),
};
match validate_registration(&request) {
ValidationResult::Invalid(errors) => {
assert!(errors.contains(&"Name is required".to_string()));
}
ValidationResult::Valid => panic!("expected Invalid"),
}
}
#[test]
fn invalid_email_returns_invalid() {
let request = RegistrationRequest {
name: "Alice".into(),
email: "not-an-email".into(),
password: "SecureP@ss1".into(),
};
assert!(matches!(
validate_registration(&request),
ValidationResult::Invalid(_)
));
}
#[test]
fn short_password_returns_invalid() {
let request = RegistrationRequest {
name: "Alice".into(),
email: "alice@example.com".into(),
password: "short".into(),
};
assert!(matches!(
validate_registration(&request),
ValidationResult::Invalid(_)
));
}
}
```
## ステップ 3: テストの実行 — 失敗を確認
```bash
$ cargo test
running 4 tests
test tests::valid_registration_returns_valid ... FAILED (not yet implemented)
test tests::blank_name_returns_invalid ... FAILED
test tests::invalid_email_returns_invalid ... FAILED
test tests::short_password_returns_invalid ... FAILED
```
テストは想定通り失敗しました（todo! パニック）。
## ステップ 4: 最小限のコードを実装（GREEN）
```rust
pub fn validate_registration(request: &RegistrationRequest) -> ValidationResult {
let mut errors = Vec::new();
if request.name.trim().is_empty() {
errors.push("Name is required".into());
}
if !request.email.contains('@') {
errors.push("Invalid email format".into());
}
if request.password.len() < 8 {
errors.push("Password must be at least 8 characters".into());
}
if errors.is_empty() {
ValidationResult::Valid
} else {
ValidationResult::Invalid(errors)
}
}
```
## ステップ 5: テストの実行 — 成功を確認
```bash
$ cargo test
running 4 tests
test tests::valid_registration_returns_valid ... ok
test tests::blank_name_returns_invalid ... ok
test tests::invalid_email_returns_invalid ... ok
test tests::short_password_returns_invalid ... ok
test result: ok. 4 passed; 0 failed
```
すべてのテストが成功しました！
## ステップ 6: カバレッジの確認
```bash
$ cargo llvm-cov
Coverage: 100.0% of lines
```
カバレッジ: 100%
## TDD 完了！
````
## テストパターン
### ユニットテスト
```rust
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn adds_two_numbers() {
assert_eq!(add(2, 3), 5);
}
#[test]
fn handles_error() -> Result<(), Box<dyn std::error::Error>> {
let result = parse_config(r#"port = 8080"#)?;
assert_eq!(result.port, 8080);
Ok(())
}
}
```
### rstest によるパラメータ化テスト
```rust
use rstest::{rstest, fixture};
#[rstest]
#[case("hello", 5)]
#[case("", 0)]
#[case("rust", 4)]
fn test_string_length(#[case] input: &str, #[case] expected: usize) {
assert_eq!(input.len(), expected);
}
```
### 非同期テスト
```rust
#[tokio::test]
async fn fetches_data_successfully() {
let client = TestClient::new().await;
let result = client.get("/data").await;
assert!(result.is_ok());
}
```
### プロパティベーステスト
```rust
use proptest::prelude::*;
proptest! {
#[test]
fn encode_decode_roundtrip(input in ".*") {
let encoded = encode(&input);
let decoded = decode(&encoded).unwrap();
assert_eq!(input, decoded);
}
}
```
## カバレッジコマンド
```bash
# サマリーレポート
cargo llvm-cov
# HTMLレポート
cargo llvm-cov --html
# しきい値を下回った場合に失敗
cargo llvm-cov --fail-under-lines 80
# 特定のテストを実行
cargo test test_name
# 出力付きで実行
cargo test -- --nocapture
# 最初の失敗で停止しない
cargo test --no-fail-fast
```
## カバレッジ目標
| コードの種類 | 目標 |
|-----------|--------|
| 重要なビジネスロジック | 100% |
| パブリック API | 90%以上 |
| 一般的なコード | 80%以上 |
| 生成コード / FFI バインディング | 除外 |
## TDD ベストプラクティス
**すべきこと:**
- 実装の前にまずテストを書く
- 変更のたびにテストを実行する
- より良いエラーメッセージのために `assert!` よりも `assert_eq!` を使用する
- よりクリーンな出力のために `Result` を返すテストで `?` を使用する
- 実装ではなく振る舞いをテストする
- エッジケースを含める（空、境界値、エラーパス）
**すべきでないこと:**
- テストの前に実装を書く
- RED フェーズをスキップする
- `Result::is_err()` で対応できる場合に `#[should_panic]` を使用する
- テストで `sleep()` を使用する — チャネルまたは `tokio::time::pause()` を使用する
- すべてをモック化する — 可能な場合は統合テストを優先する
## 関連コマンド
- `/rust-build` - ビルドエラーの修正
- `/rust-review` - 実装後のコードレビュー
- `verification-loop` スキル - 完全な検証ループの実行
## 関連
- スキル: `skills/rust-testing/`
- スキル: `skills/rust-patterns/`

175
docs/ja-JP/commands/santa-loop.md Normal file
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]
```
## 注意事項
- レビュアー A（Claude 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後にのみ発生します — ループ中には決して行われません。

276
docs/ja-JP/commands/save-session.md Normal file
View File

@@ -0,0 +1,276 @@
---
description: 現在のセッション状態を日付付きファイルとして ~/.claude/session-data/ に保存し、完全なコンテキストを持った状態で将来のセッションで作業を再開できるようにします。
---
# セッション保存コマンド
このセッションで起こったすべてのこと（何を構築したか、何がうまくいったか、何が失敗したか、何が残っているか）をキャプチャし、日付付きファイルに書き込みます。これにより、次のセッションはこのセッションが中断した場所から正確に再開できます。
## 使用するタイミング
- Claude Codeを閉じる前の作業セッションの終了時
- コンテキスト制限に達する前（まずこれを実行し、その後新しいセッションを開始する）
- 記憶しておきたい複雑な問題を解決した後
- 将来のセッションにコンテキストを引き継ぐ必要がある任意のタイミング
## プロセス
### ステップ1: コンテキストの収集
ファイルを書き込む前に、以下を収集します：
- このセッション中に変更されたすべてのファイルを確認する（git diffを使用するか、会話から思い出す）
- 議論した内容、試みた内容、決定した内容を振り返る
- 発生したエラーとその解決方法（または未解決の場合はその旨）を記録する
- 関連がある場合、現在のテスト/ビルドの状態を確認する
### ステップ2: セッションフォルダが存在しない場合は作成する
ユーザーのClaudeホームディレクトリに正規のセッションフォルダを作成します：
```bash
mkdir -p ~/.claude/session-data
```
### ステップ3: セッションファイルを書き込む
`~/.claude/session-data/YYYY-MM-DD-<short-id>-session.tmp` を作成します。今日の実際の日付と、`session-manager.js` の `SESSION_FILENAME_REGEX` が適用するルールを満たすshort-idを使用します：
- 互換性のある文字: 英字 `a-z` / `A-Z`、数字 `0-9`、ハイフン `-`、アンダースコア `_`
- 互換性のある最小長: 1文字
- 新規ファイルの推奨スタイル: 小文字、数字、ハイフンで8文字以上（衝突を避けるため）
有効な例: `abc123de`、`a1b2c3d4`、`frontend-worktree-1`、`ChezMoi_2`
新規ファイルでは避けるべき例: `A`、`test_id1`、`ABC123de`
完全な有効ファイル名の例: `2024-01-15-abc123de-session.tmp`
レガシーファイル名 `YYYY-MM-DD-session.tmp` も引き続き有効ですが、新しいセッションファイルは同日の衝突を避けるためshort-id形式を推奨します。
### ステップ4: 以下のすべてのセクションをファイルに記入する
すべてのセクションを正直に記入してください。セクションをスキップしないでください。セクションに本当に内容がない場合は「Nothing yet」または「N/A」と記入してください。不完全なファイルは、正直な空のセクションよりも悪い結果をもたらします。
### ステップ5: ファイルをユーザーに表示する
書き込み後、完全な内容を表示し、以下のように尋ねます：
```
セッションを [セッションファイルへの実際の解決パス] に保存しました。
内容は正確ですか？閉じる前に修正や追加はありますか？
```
確認を待ちます。要求があれば編集します。
---
## セッションファイルの形式
```markdown
# セッション: YYYY-MM-DD
**開始:** [わかる場合はおおよその時刻]
**最終更新:** [現在の時刻]
**プロジェクト:** [プロジェクト名またはパス]
**トピック:** [このセッションの内容を一行で要約]
---
## 構築しているもの
[機能、バグ修正、またはタスクを説明する1〜3段落。このセッションの記憶がゼロの人でも
目標を理解できる十分なコンテキストを含めてください。
含めるべき内容: 何をするのか、なぜ必要なのか、大きなシステムにどのように適合するのか。]
---
## うまくいったこと（証拠付き）
[動作が確認されたものだけをリストしてください。各項目について、なぜ動作すると
わかるのかを含めてください — テストが通った、ブラウザで動作した、Postmanが200を返した、など。
証拠がない場合は、代わりに「まだ試していないこと」に移動してください。]
- **[動作するもの]** — 確認方法: [具体的な証拠]
- **[動作するもの]** — 確認方法: [具体的な証拠]
確認済みの動作がまだない場合: 「確認済みの動作はまだありません — すべてのアプローチが進行中またはテスト未実施です。」
---
## うまくいかなかったこと（理由付き）
[これは最も重要なセクションです。試みて失敗したすべてのアプローチをリストしてください。
各失敗について正確な理由を記入し、次のセッションが同じことを再試行しないようにしてください。
具体的に: 「YのためにXエラーが発生した」は有用です。「動かなかった」は有用ではありません。]
- **[試みたアプローチ]** — 失敗理由: [正確な理由 / エラーメッセージ]
- **[試みたアプローチ]** — 失敗理由: [正確な理由 / エラーメッセージ]
失敗がない場合: 「失敗したアプローチはまだありません。」
---
## まだ試していないこと
[有望に見えるがまだ試みていないアプローチ。会話の中で出たアイデア。
検討する価値のある代替ソリューション。次のセッションが何を試すべきか
正確にわかるよう、十分に具体的に記述してください。]
- [アプローチ / アイデア]
- [アプローチ / アイデア]
キューに入っているものがない場合: 「特定の未試行アプローチは特定されていません。」
---
## ファイルの現在の状態
[このセッションで触れたすべてのファイル。各ファイルの状態を正確に記述してください。]
| ファイル | ステータス | メモ |
| ----------------- | -------------- | -------------------------- |
| `path/to/file.ts` | PASS: 完了 | [何をするか] |
| `path/to/file.ts` | 進行中 | [完了部分、残り部分] |
| `path/to/file.ts` | FAIL: 壊れている | [何が問題か] |
| `path/to/file.ts` | 未着手 | [計画済みだが未着手] |
ファイルが触れられていない場合: 「このセッションではファイルの変更はありません。」
---
## 決定事項
[アーキテクチャの選択、受け入れたトレードオフ、選択したアプローチとその理由。
これにより、次のセッションが既に決定された事項を蒸し返すのを防ぎます。]
- **[決定]** — 理由: [代替案よりもこれを選んだ理由]
重要な決定がない場合: 「このセッションでは大きな決定はありませんでした。」
---
## ブロッカーと未解決の質問
[次のセッションで対処または調査する必要がある未解決の事項。
出てきたが回答されなかった質問。待機中の外部依存関係。]
- [ブロッカー / 未解決の質問]
ない場合: 「アクティブなブロッカーはありません。」
---
## 正確な次のステップ
[わかっている場合: 再開時に行うべき最も重要な単一のこと。
開始場所について考える必要がないほど正確に記述してください。]
[わかっていない場合: 「次のステップは未定です — 方向性を決める前に
『まだ試していないこと』と『ブロッカー』セクションを確認してください。」]
---
## 環境とセットアップに関するメモ
[関連がある場合のみ記入 — プロジェクトの実行に必要なコマンド、
必要な環境変数、実行中である必要があるサービスなど。標準的なセットアップの場合はスキップ。]
[ない場合: このセクション全体を省略してください。]
```
---
## 出力例
```markdown
# セッション: 2024-01-15
**開始:** 約14時
**最終更新:** 17:30
**プロジェクト:** my-app
**トピック:** httpOnlyクッキーによるJWT認証の構築
---
## 構築しているもの
Next.jsアプリのユーザー認証システム。ユーザーはメールアドレスとパスワードで登録し、
httpOnlyクッキー（localStorageではなく）に保存されたJWTを受け取り、保護されたルートは
ミドルウェアを通じて有効なトークンを確認します。目標は、トークンをJavaScriptに
公開することなく、ブラウザのリフレッシュ間でセッションの永続性を実現することです。
---
## うまくいったこと（証拠付き）
- **`/api/auth/register` エンドポイント** — 確認方法: Postman POSTがユーザーオブジェクト付きの200を返し、
Supabaseダッシュボードで行が確認でき、bcryptハッシュが正しく保存されている
- **`lib/auth.ts` でのJWT生成** — 確認方法: ユニットテストが通る
（`npm test -- auth.test.ts`）、jwt.ioでデコードしたトークンが正しいペイロードを表示
- **パスワードハッシュ化** — 確認方法: テストで `bcrypt.compare()` がtrueを返す
---
## うまくいかなかったこと（理由付き）
- **Next-Authライブラリ** — 失敗理由: カスタムPrismaアダプターと競合し、
すべてのリクエストで「Cannot use adapter with credentials provider in this configuration」をスロー。
デバッグする価値なし — 我々のセットアップには意見が強すぎる。
- **localStorageへのJWT保存** — 失敗理由: SSRレンダリングはlocalStorageが利用可能になる前に行われ、
すべてのページ読み込みでReactのハイドレーション不一致エラーが発生。
このアプローチはNext.jsのSSRと根本的に互換性がない。
---
## まだ試していないこと
- ログインルートのレスポンスでJWTをhttpOnlyクッキーとして保存する（最も可能性の高いソリューション）
- `next/headers` の `cookies()` を使用してサーバーコンポーネントでトークンを読み取る
- クッキーの存在を確認してルートを保護するmiddleware.tsを書く
---
## ファイルの現在の状態
| ファイル | ステータス | メモ |
| -------------------------------- | -------------- | ----------------------------------------------- |
| `app/api/auth/register/route.ts` | PASS: 完了 | 動作確認済み、テスト済み |
| `app/api/auth/login/route.ts` | 進行中 | トークンは生成されるがクッキーの設定はまだ |
| `lib/auth.ts` | PASS: 完了 | JWTヘルパー、すべてテスト済み |
| `middleware.ts` | 未着手 | ルート保護、クッキー読み取りロジックが先に必要 |
| `app/login/page.tsx` | 未着手 | UIは未着手 |
---
## 決定事項
- **localStorageよりhttpOnlyクッキー** — 理由: XSSトークン盗難を防ぎ、SSRで動作する
- **Next-Authよりカスタム認証** — 理由: Next-AuthがPrismaセットアップと競合し、闘う価値がない
---
## ブロッカーと未解決の質問
- `cookies().set()` はRoute Handler内で動作するのか、それともServer Actions内でのみか？確認が必要。
---
## 正確な次のステップ
`app/api/auth/login/route.ts` で、JWTを生成した後、
`cookies().set('token', jwt, { httpOnly: true, secure: true, sameSite: 'strict' })` を使用して
httpOnlyクッキーとして設定する。
その後Postmanでテスト — レスポンスに `Set-Cookie` ヘッダーが含まれるはず。
```
---
## 注意事項
- 各セッションには独自のファイルが割り当てられます — 以前のセッションのファイルに追記しないでください
- 「うまくいかなかったこと」セクションが最も重要です — このセクションがないと、将来のセッションは失敗したアプローチを盲目的に再試行します
- ユーザーがセッション途中（終了時ではなく）での保存を求めた場合、現時点でわかっていることを保存し、進行中の項目を明確にマークしてください
- このファイルは次のセッションの開始時に `/resume-session` を通じてClaudeに読み込まれることを目的としています
- 正規のグローバルセッションストアを使用してください: `~/.claude/session-data/`
- 新しいセッションファイルにはshort-idファイル名形式（`YYYY-MM-DD-<short-id>-session.tmp`）を推奨します

92
docs/ja-JP/commands/security-scan.md Normal file
View File

@@ -0,0 +1,92 @@
---
description: エージェント、フック、MCP、パーミッション、シークレットのサーフェスに対してAgentShieldを実行します。
agent: everything-claude-code:security-reviewer
subtask: true
---
# セキュリティスキャンコマンド
現在のプロジェクトまたはターゲットパスに対してAgentShieldを実行し、所見を優先順位付きの修正計画に変換します。
## 使い方
`/security-scan [path] [--format text|json|markdown|html] [--min-severity low|medium|high|critical] [--fix]`
- `path`（オプション）: デフォルトは現在のプロジェクト。`.claude/`パス、リポジトリルート、またはチェックインされたテンプレートディレクトリを使用。
- `--format`: 出力形式。CIには`json`、引き継ぎには`markdown`、スタンドアロンレビューレポートには`html`。
- `--min-severity`: 低優先度の所見をフィルタ。
- `--fix`: 安全かつ自動修正可能と明示的にマークされたAgentShieldの修正のみを適用。
## 決定論的エンジン
パッケージ化されたスキャナーを優先:
```bash
npx ecc-agentshield scan --path "${TARGET_PATH:-.}" --format text
```
ローカルAgentShield開発の場合、AgentShieldチェックアウトから実行:
```bash
npm run scan -- --path "${TARGET_PATH:-.}" --format text
```
所見を作り出さないこと。AgentShieldの出力を信頼できるソースとして使用し、スキャナーの事実とフォローアップの判断を分離。
## レビューチェックリスト
1. まずアクティブなランタイムの所見を特定:
- ハードコードされたシークレット
- 広範なパーミッション
- 実行可能なフック
- シェル、ファイルシステム、リモートトランスポート、またはピン留めされていない`npx`を持つMCPサーバー
- 防御なしで信頼できないコンテンツを処理するエージェントプロンプト
2. 低信頼度のインベントリを分離:
- ドキュメントの例
- テンプレートの例
- プラグインマニフェスト
- プロジェクトローカルのオプション設定
3. criticalまたはhighの各所見について返却:
- ファイルパス
- 重大度
- ランタイム信頼度
- 重要な理由
- 正確な修正方法
- 自動修正が安全かどうか
4. `--fix`が要求された場合、修正を適用する前に計画された編集を述べる。
5. 修正後にスキャンを再実行し、前後のスコアを報告。
## 出力契約
返却内容:
1. セキュリティグレードとスコア。
2. 重大度とランタイム信頼度別の件数。
3. 正確なパス付きのcritical/highの所見。
4. 低信頼度の所見は別グループ。
5. 修正順序。
6. 実行されたコマンドとスキャンがローカル、CI、npxバックのいずれか。
## CIパターン
強制ゲートのためにGitHub ActionsでAgentShieldを使用:
```yaml
- uses: affaan-m/agentshield@v1
with:
path: "."
min-severity: "medium"
fail-on-findings: true
```
## リンク
- スキル: `skills/security-scan/SKILL.md`
- エージェント: `agents/security-reviewer.md`
- スキャナー: <https://github.com/affaan-m/agentshield>
## 引数
$ARGUMENTS:
- オプションのターゲットパス
- オプションのAgentShieldフラグ

54
docs/ja-JP/commands/skill-health.md Normal file
View File

@@ -0,0 +1,54 @@
---
name: skill-health
description: チャートとアナリティクス付きのスキルポートフォリオヘルスダッシュボードを表示
command: true
---
# スキルヘルスダッシュボード
ポートフォリオ内のすべてのスキルについて、成功率スパークライン、失敗パターンのクラスタリング、保留中の修正案、バージョン履歴を含む包括的なヘルスダッシュボードを表示します。
## 実装
ダッシュボードモードでスキルヘルスCLIを実行:
```bash
ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplaces','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplaces','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();console.log(r)")}"
node "$ECC_ROOT/scripts/skills-health.js" --dashboard
```
特定のパネルのみ:
```bash
ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplaces','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplaces','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();console.log(r)")}"
node "$ECC_ROOT/scripts/skills-health.js" --dashboard --panel failures
```
機械読み取り可能な出力:
```bash
ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplaces','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplaces','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();console.log(r)")}"
node "$ECC_ROOT/scripts/skills-health.js" --dashboard --json
```
## 使い方
```
/skill-health # フルダッシュボードビュー
/skill-health --panel failures # 失敗クラスタリングパネルのみ
/skill-health --json # 機械読み取り可能なJSON出力
```
## 動作内容
1. --dashboardフラグでskills-health.jsスクリプトを実行
2. ユーザーに出力を表示
3. 低下しているスキルがある場合、ハイライトして/evolveの実行を提案
4. 保留中の修正案がある場合、レビューを提案
## パネル
- **成功率（30日）** — スキルごとの日次成功率を表示するスパークラインチャート
- **失敗パターン** — 水平バーチャート付きのクラスタ化された失敗理由
- **保留中の修正案** — レビュー待ちの修正提案
- **バージョン履歴** — スキルごとのバージョンスナップショットのタイムライン