既存プロジェクトの初期セットアップ（初回のみ）。コードリポジトリを分析してCLAUDE.md、要件概要、 基本設計書（アーキテクチャ、DB設計、API設計）、OpenAPI仕様、MkDocs設定を自動生成する。
「このプロジェクトをセットアップして」「既存コードを分析して」「設計書を初期化して」 「プロジェクトの構造を把握して」などのリクエストで使用する。既にドキュメントがある場合は移行モードで差分だけ補完する。※ 既存Specの全更新・再生成には spec-all を使う。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
本スキルは親=コード分析・方針・レビュー / spec-writer(Sonnet)=ドキュメント執筆 / integrity-checker=機械的整合性検査の三者分担で進める。
プロジェクト規模の閾値定義 の判定ロジックに従い、必要に応じて analyze-codebase スキルの実行を提案する。
まず以下をチェックし、モードを自動判定する：
docs/requirements/features/ にmdファイルが1つ以上ある → 移行モードCLAUDE.md の「プロジェクト概要」にTODO/コメント以外の実際の記述がある → 移行モード判定の注意: テンプレートのCLAUDE.mdには最初から ## プロジェクト概要 のヘッダーとTODOコメントがある。ヘッダーやHTMLコメント（<!-- -->）だけの場合は「記述なし」と判定すること。
判定結果をユーザーに提示して確認する： 「既存のドキュメントを検出しました。移行モードで差分のみ補完します。」 または「ドキュメントが見つかりません。新規セットアップを行います。」
以下のテンプレートが存在する場合、生成する文書のセクション構成を合わせる：
| テンプレート | 用途 |
|---|---|
docs/templates/phase2/system-architecture.md | アーキテクチャ文書の構成 |
docs/templates/phase1/screen-flow.md | 画面遷移図の構成 |
docs/templates/phase2/db-design.md | DB設計書の構成 |
docs/templates/phase2/api-spec.md | 外部連携仕様書の構成 |
テンプレートが存在しない場合は、従来の手順でそのまま生成する（テンプレート不在でブロックしない）。
生成するもの:
コード分析の詳細手順（規模チェック・2段階探索・技術スタック自動検出・テストフレームワークデフォルト表・自動生成ファイル一覧・CIワークフロー生成）: → references/new-mode-detail.md
原則:
詳細手順（棚卸し手順・CLAUDE.md配置・フォーマット差分チェック・不足ドキュメント生成・CI/テスト設定・スキルファイルコピー・移行後の注意）: → references/migration-mode-detail.md
analyze-codebase スキルで並列分析済みの場合はその結果を活用するAgent(subagent_type: spec-writer) に以下を並列で委任する（ファイル単位で独立しているため）:
委任プロンプト形式（例: architecture.md）:
あなたは spec-writer です。以下のドキュメントを生成してください。
## 生成対象
docs/design/architecture.md
## 参照テンプレート
docs/templates/phase2/system-architecture.md
## 埋める情報
- プロジェクト名: [検出値]
- 技術スタック: [検出値（ファイル名:行番号の根拠付き）]
- アーキテクチャ概要: [分析結果]
- コンポーネント構成: [分析結果]
- 外部サービス依存: [検出値]
- デプロイ構成: [検出値]
## コード根拠
- [ファイル名:シンボル名] → [記述内容]
## 厳守事項
- 全ての記述に根拠（ファイル名:シンボル名）を明記する
- 不明点は「※ 要確認」マーカーを残し、推測で埋めない
- index系ファイル（overview.md / spec-map.yml / mkdocs.yml / dependency-graph.md）は触らない（親が更新）
- 完了時に軽量セルフチェックを実行し、結果を報告すること
並列委任する対象（該当するもののみ）:
spec-writer は index 系に触らないため、親が責任を持って更新する:
spec-map.yml を生成（空テンプレートまたは既存機能エントリ付き）mkdocs.yml の nav を更新（新規生成ファイルを全て追加）docs/design/dependency-graph.md が存在する場合、初期エントリを追加python3 ci-templates/generate-ci.py \
--claude-md CLAUDE.md \
--output .github/workflows/ci.yml \
--repo-structure auto
Agent(subagent_type: integrity-checker) を起動して機械的整合性チェック
.claude/skills/_shared/doc-integrity-check.md 参照git add してコミット（docsリポとコードリポそれぞれ）コード分析時の注意: .claude/rules/doc-accuracy.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) 設計書ファーストモード: 要件定義書から詳細設計書を新規作成する（コードなし） 「詳細設計を作って」「設計書を完成させて」「実装に必要な設計書を全部作って」 「他のエンジニアに渡せる設計書にして」などのリクエストで使用する。