既存プロジェクトに新しいリポジトリを追加する。Workspaceにリポを追加した後、 CLAUDE.md・設計書・ドメイン構成を差分更新する。 「モバイルリポを追加した」「新しいリポを取り込んで」「リポを追加したので設計書を更新して」 「Workspaceにリポを足した」などのリクエストで使用する。 init-spec の移行モードではファイル存在チェックしか行わないため、 既存ドキュメントの内容を新リポに合わせて拡張するにはこのスキルを使う。
hotfix
緊急修正(ホットフィックス)。本番障害時にコード先行で修正し、Spec同期を後追いで行う。設計書ファースト原則の例外措置。
通常の仕様変更には revise-spec を使うこと。「本番が落ちた」「緊急で直して」「ホットフィックスが必要」「本番バグを修正して」 「至急○○を修正して」などのリクエストで使用する。
含まれるファイル(1)
- SKILL.md4.8 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
緊急修正(ホットフィックス)
設計書ファースト原則の例外措置。本番障害・緊急バグ修正時にのみ使用する。 通常の仕様変更には revise-spec を使うこと。
使用条件
以下のいずれかに該当する場合のみホットフィックスモードを許可する:
- 本番環境で障害が発生している
- ユーザーが明示的に「緊急」「至急」「ホットフィックス」と指示している
- セキュリティ脆弱性の即時修正が必要
該当しない場合は revise-spec への誘導を提案する: 「緊急度が高くない場合は revise-spec で設計書を先に更新してから修正する方が安全です。ホットフィックスモードで進めますか?」
フェーズ1: 障害把握(5分以内)
- ユーザーから障害内容を聞く(何が壊れているか、影響範囲)
- 該当する REQ-ID を特定する(不明なら「REQ-HOTFIX-NNN」で仮採番)
- 2段階探索 で原因箇所を特定する
- 修正方針をユーザーに提示する:
障害: [概要] 原因: [ファイル:行番号] 修正方針: [概要] 影響範囲: [変更ファイル一覧]
フェーズ2: コード修正(設計書更新なし)
hotfix/[Spec ID]ブランチを作成(通常のfeature/ではなくhotfix/を使う)- 最小限の修正を実施する
- 修正範囲は障害の原因箇所のみに限定する
- 「ついでにリファクタリング」は絶対にしない
- 既存テストを実行して全てパスすることを確認
- 障害を再現するテストを追加(可能な場合)
- コミットメッセージに
[HOTFIX]プレフィックスと障害内容を記載する:fix: [HOTFIX] REQ-XXX-NNN [障害概要] 障害内容: [詳細] 原因: [根本原因] 修正内容: [変更概要] Spec同期: 未完了(24h以内に実施すること)
フェーズ3: Spec同期(24時間以内)
修正をデプロイした後、以下を実施する。ユーザーに「Spec同期はいつやりますか?今すぐ、または後で(24h以内)」と確認する。
- 該当 Spec の要件定義書を更新する
- 障害で判明した仕様の不備があれば受入条件を修正する
- 非機能要件の見直しが必要であれば追加する
- spec-map.yml 操作ガイド に従い spec-map.yml を更新する
- 基本設計への影響がある場合は設計書も更新する
- コミット(通常の
feat:ではなくdocs: [HOTFIX] Spec同期で)
フェーズ3b: 被依存Specの影響確認
spec-map.ymlで、修正対象REQ-IDに依存しているSpec(被依存先)を逆引きで特定する- 依存しているSpecが実装済みの場合、そのSpecのテストを実行して回帰がないか確認する
- テスト実行ができない場合は
manual-test-cases.xlsxに「[REQ-YYY] ホットフィックス後の回帰確認」として追加する - ユーザーに「以下のSpecが影響を受ける可能性があります。確認してください: [REQ-ID一覧]」と通知する
フェーズ4: 振り返り
- 障害の根本原因をユーザーに報告する
- 再発防止策を提案する:
- テストの不足 → gen-tests で補強を提案
- 設計の不備 → revise-spec で仕様見直しを提案
- 監視の不足 → 非機能要件への追加を提案
- テンプレートフィードバックチェック(finish-impl.md と同様)
ルール
- 修正は最小限。 障害の原因箇所のみを修正する。関連するリファクタリングは後日別タスクで行う
- Spec同期は必須。 コード先行を許可するが、24時間以内のSpec同期を義務化する。Spec同期が完了するまで hotfix ブランチの完了としない
- 仮REQ-IDは後で統合。
REQ-HOTFIX-NNNで仮採番した場合、Spec同期時に正式な REQ-ID に統合する - PR作成は行わない。コミットまでで完了とする
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
既存プロジェクトをサブエージェントで並列分析し、 精度の高い overview.md を生成する。init-spec の前処理として使う。 「既存プロジェクトを分析して」「コードベースを理解して設計書を作って」 「overview.mdを作って」などのリクエストで使用する。 ファイル数が200を超えるプロジェクトで特に有効。 200以下の場合は単一エージェントで全体を読む方が精度が高いため、 init-spec をそのまま実行することを提案する。
デザインの差し替え。ロジックは一切触らず見た目(HTML/CSS/テンプレート)だけを更新する。 「このデザインに差し替えて」「UIをFigmaの通りに変えて」「見た目だけ変えて」 「デザインを更新して」「CSSだけ直して」などのリクエストで使用する。 ロジック変更を伴う場合はrevise-specを使う。
ブラウザで画面を確認する。agent-browser CLI を使って画面のスクリーンショット撮影、 アクセシビリティツリー取得、フォーム操作、画面遷移などを行う。 「画面見て」「ブラウザ確認して」「スクショ撮って」「現状把握して」「画面開いて」 「ログインして確認して」「画面の状態を教えて」「UIを確認して」などのリクエストで使用する。 E2Eテストの作成・実行には gen-tests(Playwright)を使うこと。本スキルはテスト実行ではなく 「AIの目」としてブラウザを操作し、画面状態を把握するためのもの。
ClaudeDesign(claude.ai/design)とClaude Codeの連携。DesignSyncツールで デザインプロジェクトからプロトタイプHTML等を取得(インポート)、または ローカルのコンポーネントをデザインシステムプロジェクトへ同期(プッシュ)する。 「ClaudeDesignからデザインを取得して」「claude.ai/design のURLを取り込んで」 「デザインプロジェクトに同期して」「デザインシステムをプッシュして」 などのリクエスト、または claude.ai/design のURLが渡されたときに使用する。 取得したデザインのコード実装への適用は apply-design を使う。
詳細設計書の一括生成。2つのモードを自動判定する: (A) コード分析モード: 既存コードから詳細設計書を逆生成する(init-spec + spec-all 完了後) (B) 設計書ファーストモード: 要件定義書から詳細設計書を新規作成する(コードなし) 「詳細設計を作って」「設計書を完成させて」「実装に必要な設計書を全部作って」 「他のエンジニアに渡せる設計書にして」などのリクエストで使用する。