winter-super-cli 2026.5.32 → 2026.6.5

package/resources/local/ecc/docs/ja-JP/commands/santa-loop.md

@@ -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後にのみ発生します — ループ中には決して行われません。

package/resources/local/ecc/docs/ja-JP/commands/save-session.md

@@ -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`）を推奨します

package/resources/local/ecc/docs/ja-JP/commands/security-scan.md

@@ -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フラグ