細かいコミットを整理して歴史をキレイに

Issue番号またはPR番号を指定するだけで、対応に必要な情報をまとめたレポートが自動生成されます。 バグ報告、機能要望、プロンプト要望など、Issue の種別を自動判定し、対応すべき内容を明確にします。 コードベースを調査して、その要望を実現するために変更が必要なファイルや影響範囲を自動で洗い出します。 実装の難易度を Low / Medium / High / Very High で判定し、工数目安を提示するため、優先度判断がしやすくなります。 既存機能との重複がないか、プロトコル変更が必要か、セキュリティ上の懸念はないかなど、多角的に対応判断を支援します。 GitHub上の Issue / PR が大量に溜まっており、どれから対応すべきかを判断したい プロジェクトマネージャーやチームリード バグ報告や機能要望の優先度を決める際に、実装難易度を知りたい開発者 新しい外部PRの内容をサッと把握して、マージ判定する必要がある レビュアー 実装前に関連コードや影響範囲を把握したい エンジニア GitHub Issue / PR 番号を入力するとトリアージレポートが自動生成されます。手順は4フェーズで実行されます。Phase 1ではghコマンドで Issue またはPRの詳細情報、コメント、レビューを取得し、テンプレートやラベルから種別（Bug / Feature / Prompt Request / Dependabot / 外部PR）を判定します。プラットフォームサポート状況も評価し、実機検証が必要な環境（Windows Bridge Server、macOS Flutter等）は experimental / best-effort として区別します。Phase 2では関連コード、既存機能との重複、影響範囲、プロトコル変更の必要性をExploreサブエージェントで並列調査します。PRの場合は変更ファイル一覧、diff、規約準拠、テスト追加の有無、セキュリティ懸念をチェックします。Phase 3では調査結果をもとに難易度を判定（工数目安：Low ~1時間、Medium 数時間、High 1日以上、Very High 数日以上）し、具体的なファイルパスと変更箇所を根拠として示します。Phase 4でレポートをマークダウン形式で出力します。

バージョン自動計算とリリース分岐を一括生成：引数（patch/minor/major）またはバージョン直指定から、セマンティックバージョニング規則に従った次バージョンを計算し、git worktree + release ブランチを自動作成します。 commandmatedev エージェント委譲でリリース準備を自動化：package.json 更新、CHANGELOG 作成、ビルド・テスト・lintの品質チェック完全自動化をエージェント経由で実施、失敗時は中断報告。 3フェーズ制御でリリース完了まで一気実行：①worktree作成と登録確認、②エージェント委譲でリリース準備、③マージ・タグ・push を制御フロー通りに順序保証。 疎通確認と段階的ロールバック対応：commandmatedev サーバー状態確認、main ブランチ最新化、worktree 登録失敗時のユーザーガイダンスを自動判定。 リリースマネージャー・リードエンジニア：手動リリースの繰り返し作業を廃止し、リリース品質を標準化したい マイクロサービス・モノレポ運用チーム：複数パッケージの並行リリースを一元管理したい CI/CD パイプライン構築者：git worktree + エージェント委譲の組み合わせパターンを参考にしたい DevOps エンジニア：リリースプロセスのボトルネック自動化が必要な組織 3フェーズ実行フロー：Phase1（worktree準備）では commandmatedev 疎通確認→現在バージョン取得→次バージョン計算（セマンティックバージョニング準拠）→main ブランチ最新化→release ブランチと worktree 作成→npm install→worktree 登録確認。Phase2（エージェント委譲）では WT ID 取得→リリースタスク（package.json version更新、package-lock.json更新、CHANGELOG追加、品質チェック：lint・tsc・test・build）を commandmatedev send で送信→エージェント完了待機。Phase3（完了処理）では main マージ・タグ作成・push・worktree 削除。前提：main 最新、commandmatedev 起動、lint/tsc/test/build 全パス状態。

GitHub プルリクエストを統一された標準フォーマットで作成・更新でき、チームのコードレビュープロセスを効率化できます。 実装内容（何が変わったか、何が良くなるか）を人間向けの自然な文章で記録し、動作確認の結果と実装メモを一箇所に集約できます。 計画や技術的意思決定は Issue に記録し、PR は実装結果のみに集中させることで、ドキュメント管理の役割分担を明確化できます。 Verification チェックリスト（対象機能の動作確認、既存機能への影響確認）により、マージ前の品質確認を可視化できます。 チーム全体で PR フォーマットを統一し、コードレビューの効率を上げたい技術リード 実装の意図と実装結果を明確に分離して管理したいエンジニアチーム Issue と PR の役割分担を徹底し、ドキュメント管理を整理したい開発チーム 実装時に気づいた補足情報や次回への申し送りを体系的に記録したいコントリビューター PR の目的は「何が変わったか」を人間がレビューできるようにすること。必須セクション: (1) closes 行（Issue リンク）、(2) 冒頭の概要（見出しなし、自然な文章で何が変わるか・何が良くなるかを記述、リスクや影響を含める）、(3) Verification（実際にブラウザ操作や API 呼び出しで確認した内容、test/build などの技術的チェックは含めない）。ルール: 計画・技術的意思決定は Issue の Plan セクションに記録して PR には書かない。必須セクション後に任意セクション（Implementation Notes、Breaking Changes、Screenshots など）を自由に追加可能。Claude が残したい実装メモは何でも記録してよい。プロパティ形式（「リスク評価:」など）は使わない。Notion タスクが存在する場合は closes 行に [TASK-{番号}](Notion URL) を追記。