| name | fix-with-verify |
| description | バグ修正→コンパイル確認→回帰テスト→失敗時 revert の安全修正パイプライン。修正が新たなバグを生まないことを機械的に保証する。USE WHEN 単発バグ修正、影響範囲が見えにくい変更、リファクタの安全確認。SKIP 大規模機能追加は impl-orchestrator、セキュリティ Finding 一括修正は robust-fix、仕様整合性回復は spec-fix を使うこと。 |
| argument-hint | [issue-description or file:line] |
| allowed-tools | Read, Write, Edit, MultiEdit, Bash, Grep, Glob |
修正 → 検証パイプライン
Step 1: ベースライン記録
- 修正対象ファイルの現在の状態を
git diff で確認
- 既存テストを実行してベースライン記録（言語を自動検出）:
| 言語 | コマンド |
|---|
| Rust | cargo test -p <crate> 2>&1 | tail -20 |
| Python | pytest <テストファイル> 2>&1 | tail -20 |
| Go | go test ./<パッケージ>/... 2>&1 | tail -20 |
| Node | npm test 2>&1 | tail -20 |
- 失敗テストがあれば、それが今回の修正対象か確認
Step 2: 影響範囲分析
- 修正対象の関数/型の呼び出し元を Grep で特定
- モジュール依存関係を確認（コアモジュール修正 → 依存モジュールにも影響）
- 公開 API のシグネチャ変更は影響範囲が広いため要注意
Step 3: 修正実行
- 1ファイルずつ修正（複数ファイル一括変更禁止）
- 各ファイル修正後にコンパイル/型チェック確認:
| 言語 | コマンド |
|---|
| Rust | cargo check -p <crate> (コア修正時は cargo check --workspace) |
| Python | ruff check <file> / mypy <file> |
| Go | go build ./<パッケージ>/... |
| Node | npx tsc --noEmit |
- コンパイル/型エラーがあれば即座に修正
Step 4: セキュリティ・堅牢性チェック（修正内容に応じて）
以下のパターンが修正に含まれる場合、追加チェック:
パニック/クラッシュ防止
unwrap() / expect() → ? またはエラーハンドリングに置換- 配列インデックス →
.get() + エラーハンドリング
- 0除算 → 分母の事前チェック
インジェクション防止
- SQL/NoSQL 文字列結合 → パラメータバインドに置換
入力バリデーション
- 外部入力の型・範囲チェック追加
- NaN / Infinity / 空入力のハンドリング
Step 5: リグレッション検証
- Step 1 と同じテストスイートを実行
- コアモジュール修正時は依存モジュールも検証:
- Rust:
cargo test --workspace
- Go:
go test ./...
- Node:
npm test
- 新たに失敗したテストがあれば修正を revert:
git checkout HEAD -- <file>
- revert 後、より小さな単位で再修正を試みる
- 3回連続でリグレッションが起きたら代替案を3つ提案してユーザーに選択を求める
Step 6: エッジケーステスト追加
修正に対応するテストが不足している場合、以下を追加:
- 修正したバグの再現テスト（今後のリグレッション防止）
- 境界値テスト（0, 空, 最大値, null/None/nil）
- エラーケーステスト（不正入力、タイムアウト等）
テスト追加後に再度テスト実行で PASS を確認。
Step 7: 完了確認
git diff --stat で変更概要確認- lint グリーン確認（言語に応じたツール）
- 修正内容サマリーを表示:
