mcpField
H
hotfix

hotfix

github.com/andrewvaughan開発1596 回インストール35 週間前に更新
リポジトリ

hotfix について

hotfixは、本番環境の緊急バグやセキュリティ修正、重大なリグレッションに対応するワークフロースキルです。調査とテストからレビュー、プルリクエスト作成、CI監視までを案内します。

主な機能

  1. 01ホットフィックス範囲の確認
  2. 02ブランチ作成とバグ調査
  3. 03最小限の修正と回帰テスト
  4. 04重点的なセキュリティ・アクセシビリティレビュー
  5. 05プルリクエスト作成とCI追跡

活用シーン

  1. 01本番障害への対処
  2. 02セキュリティ脆弱性の修正
  3. 03重大なリグレッションの修正
  4. 04緊急修正のCI確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/andrewvaughan/agent-council --skill hotfix

インストール後、Claude Code で/hotfixを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
platform-engineer.md
qa-lead.md
security-engineer.md
councils/
deployment-council.md

詳細

ホットフィックスワークフロー

完全な計画サイクルを省略する簡略化されたパイプラインで、緊急の修正を適用します。このスキルは、本番環境のバグ、セキュリティパッチ、重大なリグレッションを対象としています。

注意

機能開発の近道として使わないでください。 変更によって新しい機能が追加される場合、ユーザー向けの動作が変わる場合、または変更箇所が約100行を超える場合は、代わりに /plan-feature を使用してください。ホットフィックスは小規模で、対象が絞られ、範囲が明確である必要があります。

注意

適用範囲：このスキルは修正を実装し、レビューし、PRを作成して、CIを監視します。緊急修正のライフサイクル全体をカバーするため、ユーザーが複数のスキルを連続して実行する必要はありません。

ステップ 1：修正内容を定義する

チェックポイント：ホットフィックスの範囲を確認する

ユーザーに問題の説明を求めます。以下の情報を収集します。

  1. 何が壊れていますか？（症状、エラーメッセージ、影響を受けるユーザー）
  2. バグはどこにありますか？（ファイル、エンドポイント、コンポーネント。不明な場合はその旨）
  3. 緊急度はどの程度ですか？（本番環境の停止、データ破損、セキュリティ脆弱性、ユーザー体験の低下）
  4. GitHub の Issue 番号（ある場合）

ユーザーが GitHub の Issue 番号を提示した場合は、その Issue を取得します。

gh issue view <number> --json title,body,labels,state,number

概要を提示し、これが機能開発ではなくホットフィックスとして適切か、ユーザーに確認します。

ステップ 2：ブランチを作成して調査する

  1. main ブランチにいて、最新の状態であることを確認します。

    git fetch origin
git checkout main
git pull origin main

  2. fix/ ブランチを作成します。

    git checkout -b fix/<short-description>

  3. GitHub の Issue がある場合は、in-progress ラベルを追加します（AGENTS.md のラベル管理ルールに従い、先に他の Issue から削除します）。

  4. バグを調査します。関連ファイルを読み、可能であれば問題を再現し、根本原因を特定します。

作業を進める前に、根本原因の分析をユーザーに提示します。

ステップ 3：修正を適用する

  1. 問題を解決するために必要な最小限の変更を加えます。

  2. バグを対象とするテスト（リグレッションテスト）を作成または更新します。

  3. 自己チェックを実行します。

    pnpm type-check
pnpm lint
pnpm test

  4. 上記のチェックで失敗した項目を修正します。

チェックポイント：修正をレビューする

以下を提示します。

  • 変更したファイル（それぞれの変更内容の簡単な説明付き）
  • 追加または変更したテスト
  • テスト結果（成功／失敗、カバレッジ）

コミットする前に、ユーザーの承認を待ちます。

ステップ 4：コミットする

Conventional Commits 形式でコミットします。

git add <specific-files>
git commit -m "fix(<scope>): <description>"

ステップ 5：対象を絞ったレビュー

軽量なレビューを実施します（完全な Review Council ではありません）。

  1. セキュリティスキャン（常に実施）：変更したファイルに対して /security-scanning:security-sast を実行します。
  2. アクセシビリティチェック（フロントエンドの変更がある場合）：変更したコンポーネントに対して /ui-design:accessibility-audit を実行します。

セキュリティスキャンで変更したファイルに重大または高深刻度の問題が見つかった場合は、ユーザーに提示します。先に進む前に、正当な指摘事項を修正します。

ステップ 6：デプロイメント評議会（条件付き）

修正に以下のいずれかが含まれる場合のみ、Deployment Council を起動します。

  • データベースのマイグレーション
  • Docker またはインフラストラクチャの変更
  • 環境変数の変更
  • 認証または認可コード

どれにも該当しない場合は、ステップ 7 に進みます。

起動する場合は、.claude/councils/deployment-council.md に記載された Deployment Council の評価を、3人のメンバー（Platform Engineer、Security Engineer、QA Lead）全員で実施します。

チェックポイント：デプロイ準備状況

Deployment Council の判定を提示します。ユーザーの承認を待ちます。

ステップ 7：PR を作成して CI を監視する

  1. プッシュ前のチェックを実行します。

    pnpm type-check && pnpm lint && pnpm format:check && pnpm test

    format:check が失敗した場合は、pnpm format でフォーマットの問題を自動修正します。

  2. プッシュして PR を作成します。

    git push -u origin fix/<short-description>

  3. PR の説明を作成します。.github/PULL_REQUEST_TEMPLATE.md が存在する場合は、そのテンプレートを使用します。以下を含めます。

    • バグと根本原因の説明
    • 適用した修正
    • 追加したテスト
    • 関連する Issue 番号（該当する場合）
チェックポイント：PR の説明

PR のタイトルと本文を提示します。ユーザーの承認を待ちます。

  1. PR を作成します。

    gh pr create --title "<title>" --body "<body>"

  2. CI を監視します。

    gh run list --branch fix/<short-description> --limit 1 --json databaseId --jq '.[0].databaseId'

    続けて、以下を監視します。

    gh run watch <run-id> --exit-status

  3. CI が失敗した場合は、原因を診断して修正します。コミットする前に、修正内容をユーザーに提示します。

ステップ 8：引き継ぎ

完了したホットフィックスの概要を提示します：

  • PR の URL
  • 変更したファイル
  • 追加したテスト
  • CI のステータス
  • 関連するイシュー（該当する場合）

/hotfix が完了しました。PR はマージできる状態です。関連する GitHub イシューがある場合、PR の本文に Closes #N が含まれていれば、PR のマージ時に自動的にクローズされます。

コメント

Markdown 対応