Menu
緊急修正（ホットフィックス）。本番障害時にコード先行で修正し、Spec同期を後追いで行う。 設計書ファースト原則の例外措置。通常の仕様変更には revise-spec を使うこと。 「本番が落ちた」「緊急で直して」「ホットフィックスが必要」「本番バグを修正して」 「至急○○を修正して」などのリクエストで使用する。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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) 設計書ファーストモード: 要件定義書から詳細設計書を新規作成する（コードなし） 「詳細設計を作って」「設計書を完成させて」「実装に必要な設計書を全部作って」 「他のエンジニアに渡せる設計書にして」などのリクエストで使用する。
既存プロジェクトの初期セットアップ（初回のみ）。コードリポジトリを分析してCLAUDE.md、要件概要、 基本設計書（アーキテクチャ、DB設計、API設計）、OpenAPI仕様、MkDocs設定を自動生成する。 「このプロジェクトをセットアップして」「既存コードを分析して」「設計書を初期化して」 「プロジェクトの構造を把握して」などのリクエストで使用する。 既にドキュメントがある場合は移行モードで差分だけ補完する。 ※ 既存Specの全更新・再生成には spec-all を使う。
全機能の一括Spec化・一括更新。PM として並列サブエージェントにコード分析を委任し、 結果を統合して全機能の要件定義書を一括生成・更新する。 「全部のSpecを作って」「設計書を全部作って」「全機能をドキュメント化して」 「要件定義を全て更新して」「Specを全部更新して」などのリクエストで使用する。 個別のSpec化には spec-feature を使う。init-specは初期セットアップ専用。
既存機能のSpec化。実装済みコードを分析して要件定義書を逆生成する。 spec-map.yml にコードとSpecの対応関係を記録する（コード変更なし）。 「ツイート機能のSpecを作って」「認証周りをドキュメント化して」「既存の○○機能を設計書にして」 「この機能の要件を整理して」「○○の仕様を分析して」などのリクエストで使用する。 既に動いているコードからドキュメントを起こすときに使う。新規機能にはdraft-specを使う。 コード変更後のドキュメント追従にはupdate-docsを使う。
コード変更からドキュメントを追従更新する。設計書ファースト原則の例外措置。 やむを得ず先にコードを変更した場合にのみ使用する。 「さっきの変更をドキュメントに反映して」「設計書を最新にして」 「コードと設計書がズレてるから直して」「ドキュメントを最新化して」 「ドキュメント更新して」「設計書を現状に合わせて」などのリクエストで使用する。 通常はドキュメントを先に更新してからコードを修正すること（revise-specを使う）。
| name | hotfix |
| description | 緊急修正（ホットフィックス）。本番障害時にコード先行で修正し、Spec同期を後追いで行う。 設計書ファースト原則の例外措置。通常の仕様変更には revise-spec を使うこと。 「本番が落ちた」「緊急で直して」「ホットフィックスが必要」「本番バグを修正して」 「至急○○を修正して」などのリクエストで使用する。 |
| context | {"required":["_shared/spec-map-operations.md","_shared/code-search-2stage.md","_shared/finish-impl.md"],"on_error":["_shared/error-recovery.md"]} |
設計書ファースト原則の例外措置。本番障害・緊急バグ修正時にのみ使用する。 通常の仕様変更には revise-spec を使うこと。
以下のいずれかに該当する場合のみホットフィックスモードを許可する：
該当しない場合は revise-spec への誘導を提案する： 「緊急度が高くない場合は revise-spec で設計書を先に更新してから修正する方が安全です。ホットフィックスモードで進めますか？」
障害: [概要]
原因: [ファイル:行番号]
修正方針: [概要]
影響範囲: [変更ファイル一覧]
hotfix/[Spec ID] ブランチを作成（通常の feature/ ではなく hotfix/ を使う）[HOTFIX] プレフィックスと障害内容を記載する：
fix: [HOTFIX] REQ-XXX-NNN [障害概要]
障害内容: [詳細]
原因: [根本原因]
修正内容: [変更概要]
Spec同期: 未完了（24h以内に実施すること）
修正をデプロイした後、以下を実施する。ユーザーに「Spec同期はいつやりますか？今すぐ、または後で（24h以内）」と確認する。
feat: ではなく docs: [HOTFIX] Spec同期 で）spec-map.yml で、修正対象REQ-IDに依存しているSpec（被依存先）を逆引きで特定する
manual-test-cases.xlsx に「[REQ-YYY] ホットフィックス後の回帰確認」として追加するREQ-HOTFIX-NNN で仮採番した場合、Spec同期時に正式な REQ-ID に統合する