実装済み機能の仕様変更。要件定義書と基本設計を先に更新してからコード修正→テスト→レビューを実行する。変更種別を自動判定し、実装はAgent(Sonnet)に委任可能、レビューは本体が直接実行する。
「アップロード上限を10MBに変えて」「この画面にフィールド追加して」「○○の仕様を変更して」 「○○を修正して」「バリデーションを変えて」などのリクエストで使用する。既に実装済みの機能を変更するときに使う。新規実装はimplement-spec。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
本スキルは親=分析・方針・レビュー / spec-writer(Sonnet)=設計書更新執筆 / integrity-checker=機械的整合性検査 / coder(Sonnet)=コード実装の四者分担で進める。
Spec 統一基盤確認 を実施する。新しい概念が出てきた場合は glossary.md にも追記する。
spec-map.yml で以下を確認する：
confirmed == spec_version か（不一致なら先にコード追従が必要）depends_on に列挙された依存Spec全てが confirmed == spec_version かconfirmed == spec_version かdocs/api/openapi.yaml が存在し対象エンドポイント定義を含んでいるか確認するspec-map.yml の全エントリから depends_on を読み取り、逆引きインデックスを構築する
depends_on: [REQ-A] → REQ-A の被依存先に REQ-B を追加
b. 変更対象のREQ-IDから、被依存先を再帰的に辿り、推移的影響範囲を特定するdocs/design/dependency-graph.md が存在する場合はそちらも参照し、spec-map.yml と突合する
d. 影響範囲を以下の形式で整理する：## 影響範囲
### 直接影響（変更必須）
- REQ-XXX-001: [変更理由]
### 推移的影響（要確認）
- REQ-YYY-001 → REQ-XXX-001 経由: [確認観点]
### コードファイル
- [2段階探索で見つけた全ファイル]
Agent(subagent_type: spec-writer) に設計書更新を委任する:
委任プロンプト形式:
あなたは spec-writer です。以下のドキュメントを差分更新してください。
## 更新対象
docs/requirements/features/[REQ-ID].md
## 更新箇所
- セクション名: [XXX]
- 変更前: [値]
- 変更後: [値]
## 更新方針
- 差分更新が基本。既存文書の全面書き換えはしない
- 変更箇所のセクションだけを更新し、周辺は触らない
- 画面遷移に影響する変更の場合は画面遷移図も更新する
- 不明点は「※ 要確認」マーカーを残し、推測で埋めない
## 変更内容サマリ
[フェーズ1で整理した変更内容・影響範囲]
## 厳守事項
- index系ファイル（overview.md / spec-map.yml / mkdocs.yml / dependency-graph.md）は触らない（親が更新）
- コードを変更しない（コード変更は親が coder エージェントに委任する）
- 完了時に軽量セルフチェックを実行し、結果を報告すること
並列委任する対象（該当するもののみ）:
spec-writer は index 系に触らないため、親が責任を持って更新する:
mkdocs.yml の nav に追加するspec_version をインクリメントする（「見た目のみ」変更ではインクリメント不要）docs/requirements/overview.md を更新（新REQ-IDを追加した場合）docs/design/dependency-graph.md が存在する場合、変更対象Specの依存関係を更新するAgent(subagent_type: integrity-checker) を起動して機械的整合性チェック
.claude/skills/_shared/doc-integrity-check.md 参照impl-plans/[REQ-ID].md を作成（または更新）する：docs: [REQ-ID] 実装プラン作成実装プラン（impl-plans/[REQ-ID].md）の順序に従ってコードを修正する。
以下の基準で実装方法を自動判断する：
Agent(subagent_type: "coder") で起動し、実装プランのパスと設計書パスリストを prompt に渡す実装時の共通ルール（本体/Agent 共通）：
.claude/skills/_shared/finish-impl.md の共通仕上げ手順を実行/cost でトークン使用量を随時確認するimpl-plans/[REQ-ID].md の末尾に追記し、新セッションでの再開を提案するまだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
既存プロジェクトに新しいリポジトリを追加する。Workspaceにリポを追加した後、 CLAUDE.md・設計書・ドメイン構成を差分更新する。 「モバイルリポを追加した」「新しいリポを取り込んで」「リポを追加したので設計書を更新して」 「Workspaceにリポを足した」などのリクエストで使用する。 init-spec の移行モードではファイル存在チェックしか行わないため、 既存ドキュメントの内容を新リポに合わせて拡張するにはこのスキルを使う。
既存プロジェクトをサブエージェントで並列分析し、 精度の高い 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) 設計書ファーストモード: 要件定義書から詳細設計書を新規作成する（コードなし） 「詳細設計を作って」「設計書を完成させて」「実装に必要な設計書を全部作って」 「他のエンジニアに渡せる設計書にして」などのリクエストで使用する。