菜单
緊急修正（ホットフィックス）。本番障害時にコード先行で修正し、Spec同期を後追いで行う。 設計書ファースト原則の例外措置。通常の仕様変更には revise-spec を使うこと。 「本番が落ちた」「緊急で直して」「ホットフィックスが必要」「本番バグを修正して」 「至急○○を修正して」などのリクエストで使用する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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 に統合する