既存プロジェクトに新しいリポジトリを追加する。Workspaceにリポを追加した後、 CLAUDE.md・設計書・ドメイン構成を差分更新する。 「モバイルリポを追加した」「新しいリポを取り込んで」「リポを追加したので設計書を更新して」 「Workspaceにリポを足した」などのリクエストで使用する。 init-spec の移行モードではファイル存在チェックしか行わないため、 既存ドキュメントの内容を新リポに合わせて拡張するにはこのスキルを使う。
spec-all
全機能の一括Spec化・一括更新。PM として並列サブエージェントにコード分析を委任し、 結果を統合して全機能の要件定義書を一括生成・更新する。 「全部のSpecを作って」「設計書を全部作って」「全機能をドキュメント化して」 「要件定義を全て更新して」「Specを全部更新して」などのリクエストで使用する。 個別のSpec化には spec-feature を使う。init-specは初期セットアップ専用。
インストール方法を見る含まれるファイル(7)
- SKILL.md5.5 KB
- execution.md8.2 KB
- references/phase0-foundation.md1.3 KB
- references/phase1-domain-split.md4.4 KB
- references/phase3-writing.md5.6 KB
- references/phase4-7-final.md3.2 KB
- references/session-resume.md914 B
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
全機能一括 Spec 化(PM オーケストレーション)
PM オーケストレーション共通パターン(.claude/rules/pm-orchestration.md で自動ロード)に従い、
親 Opus = コード分析の統合・執筆プラン・レビュー / spec-writer(Sonnet) = 執筆の分担で進める。
前提条件
docs/requirements/overview.mdに機能一覧が存在すること(init-spec 済み)- コードリポのパスが
CLAUDE.mdの「プロジェクト構成」に記載されていること
フェーズ 0: 統一基盤の確立
用語辞書作成・統一基盤確認・REQ-ID カテゴリ事前採番。 詳細: references/phase0-foundation.md
フェーズ 1: ドメイン分割計画
現状把握・ドメイン分割・ファイル割り当て・ナビゲーション階層決定・計画記録・ユーザー確認。 詳細: references/phase1-domain-split.md
フェーズ 2: 並列コード分析
spec-all 実行詳細 の「分析エージェントへの指示テンプレート」「結果収集と品質検証」に従い、全ドメインのサブエージェントを並列起動してコード分析を実行する。
フェーズ 3: 執筆プラン整理(親エージェント)
フェーズ2のコード分析結果をもとに、バッチ単位で spec-writer 用の執筆プロンプトを組み立てる。
詳細: references/phase3-writing.md
バッチサイズの原則(詳細は references/phase3-writing.md 参照):
- 大規模機能 → 1〜2 機能/バッチ
- 中規模機能 → 3〜5 機能/バッチ
- トークン残量 7万以下 → 1機能ずつ
フェーズ 4: 執筆委任(spec-writer、バッチ単位で並列)
Agent(subagent_type: spec-writer) をバッチ単位で並列起動し、Spec を執筆させる。
委任プロンプト形式・バッチ管理・index系更新・コミット手順の詳細: references/phase3-writing.md
フェーズ 5: 設計書統合・最終仕上げ
設計書統合更新・共通コンポーネント設計書・依存グラフ生成・最終レビュー・完了。 詳細: references/phase4-7-final.md
フェーズ 6: 最終レビューと整合性チェック(親エージェント)
全バッチ完了後、2種類のレビューを実行する。
6.1 統一性レビュー
Spec 統一性レビュー をフルチェックモードで起動し、結果を全て反映する。
6.2 仕様カバレッジレビュー(コード分析モードのみ)
仕様カバレッジレビュー に従い、コードと要件定義書を突合する。漏れがあれば該当 Spec に追記する。
6.3 機械的整合性チェック
Agent(subagent_type: integrity-checker) を起動する(直列1回のみ):
- 全変更ファイルリスト・新規REQ-IDリストを prompt で渡す
- チェック項目:
.claude/skills/_shared/doc-integrity-check.md参照 - FAIL があれば修正 → 再チェック(最大3ループ)
フェーズ 7: コミット(親エージェント)
全ドキュメント完成後、変更を git add してコミットする。
セッション中断時の再開
「spec-all を再開して」で新セッションから復元できる。 詳細: references/session-resume.md
トークン節約ルール
PM オーケストレーション共通パターン(自動ロード済み) の「トークン節約ルール」に従う。 追加ルール:
- バッチサイズは機能規模に応じて動的に決定し、コンテキスト圧縮を防ぐ
ルール
- PM オーケストレーション共通パターン(自動ロード済み) の全ルールに従う
- 実装に書いていないことは書かない。 spec-feature と同じ正確性ルールを適用する
- 統一性レビューを省略しない。 バッチごと + 最終の両方で必ず実行する
- 機械的整合性チェック(integrity-checker)は最終に1回必ず実行する
- spec-writer には「渡されたリストのみ使う、独自にgrepしない」と必ず明記する
- 既存コードは一切変更しない
コード分析時の注意: .claude/rules/doc-accuracy.md「ドキュメント生成の正確性ルール」を厳守すること。
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
既存プロジェクトをサブエージェントで並列分析し、 精度の高い 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) 設計書ファーストモード: 要件定義書から詳細設計書を新規作成する(コードなし) 「詳細設計を作って」「設計書を完成させて」「実装に必要な設計書を全部作って」 「他のエンジニアに渡せる設計書にして」などのリクエストで使用する。