GitHub Issue・PRの対応判断を自動調査

バージョン自動計算とリリース分岐を一括生成：引数（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) を追記。

コンテキストから最適なフォーマットを自動選択：障害・バグ・設計・企画など事象の種類を判定し、4F形式（事実・原因・対応・再発防止）またはSTAR形式（状況・課題・計画・成果）を自動選択して起票します。 既存Issueとの重複をチェック：起票前にキーワード検索で重複がないか確認し、既存Issue がある場合はコメント追加を提案します。 優先度・ラベルを自動判定：P0（本番障害）、P1（開発支障）、P2（改善）、ラベル（troubleshooting / planning / design / knowledge）を自動で付与します。 トラブルシューティング完了時に自動起票：Claude Codeのエージェント作業中に問題が解決したら、その知見を自動的にIssueとして記録できます。 開発チーム全体：バグ報告、設計議論、技術調査の結果を一元管理したい人 プロジェクトマネージャー：タスクの状態把握と優先順位付けを効率化したい人 テクニカルリード：解決済みのトラブルを組織的なナレッジ資産に変えたい人 AIエージェント連携開発者：自動化したトラブルシューティング結果をすぐにIssue化したい人 このスキルはコンテキスト分析、フォーマット自動選択、重複チェック、起票、プロジェクト追加の5ステップで動作します。コンテキスト分析では事象の種類（障害/バグ/企画/検討）、時制（過去/未来）、ラベル、優先度を判定します。4F形式は既発生の障害・バグ・調査結果に、STAR形式は未来の機能検討・設計議論・アップグレード計画に、フリーフォーマットはナレッジ共有・議論の記録に選択します。gh issue list コマンドで重複確認し、重複がなければ gh issue create で起票、gh project item-add でプロジェクトに追加します。トラブルシューティング自動起票ルール では、Claude Code エージェント作業中に問題が解消したら自動的に /issue を実行し、作業コンテキスト（エラー内容、原因、修正内容）から4F形式でIssueを生成し、ユーザー承認後に起票します。