Frontend Project Bootstrap
UI/UXで納品されたプロトタイプを「チーム標準のフロントエンドプロジェクト + 記入済みドキュメント + 着手可能なタスクリスト」に変換し、後に異なる人や異なるコーディングエージェントが書くコードが同一人物が書いたかのように統一されるようにします。
バージョン: CHANGELOG.md の最新エントリを参照。
基本原則
- プロトタイプは要件素材であり、プロジェクトにそのままコピーするコードではない。 そこから画面、データ、カラーパレット、インタラクションを抽出するが、実装をコピーしてはならない。元ファイルとスクリーンショットはリポジトリに保存し、受け入れ基準とする。
- チーム標準はそのままコピーし、プロジェクト内容はプロトタイプに基づいて記入する。 この2種類のファイルの扱いは異なる（下記「ファイルインデックス」参照）。
- 不明な点は推測せずに質問する。 質問は一時停止ポイントでラウンドごとに行い、各質問には推奨回答を付ける。「はい」と回答されたら推奨を受け入れたものとする。
- ビジネス機能は実装しない。 このスキルはスケルトン、空のページ、ドキュメントのみを作成する。ビジネス機能は後でタスクリストに基づいて
/implementが開発する。 - 検証が完了条件。 lint、typecheck、test、buildがすべてパスし、残留プレースホルダーがなく、各画面のスクリーンショットが存在すること。
必要な入力
- プロトタイプ（単一HTML、複数ページHTML、デザインファイルのリンク、またはスクリーンショット）とそのバージョン/納品日
- プロジェクト名と一言説明
- 新規プロジェクトのディレクトリパス（空のディレクトリまたは新規リポジトリであること。内容が存在する場合は一旦停止して確認）
その他の情報（デプロイ環境、バックエンドの現状、言語、ダークモード）はステップ1で質問します。詳細は references/workflow-detail.md を参照。
事前準備（各マシンで1回のみ）
cd <skill> && npm ci && npx playwright install chromium # scripts/ で使用する Playwright と Prettier。プロジェクトスケルトンには含めない
# 既に Chromium がインストールされている場合はダウンロード不要。スクリーンショットスクリプト実行時は CHROMIUM_EXECUTABLE=<path> を使用
フロー
以下の5ステップのタスクリストを作成し、各ステップ完了ごとにチェックを入れる。
ステップ1: 受付
まず、プロジェクトフォルダが存在しないか空であることを確認する（内容がある場合は停止して質問する）。次に、プロトタイプファイル、バージョン、チーム共有の保存場所を確認し、references/workflow-detail.md のステップ1の表にあるまだ提供されていない項目を質問する。
ステップ2: プロトタイプ分析とスクリーンショット
references/prototype-analysis.md を読み、その方法に従って分析し、docs/_bootstrap/prototype-analysis.md を生成する（フォーマット: templates/prototype-analysis.md）。プロトタイプがHTMLの場合は、元ファイルを docs/prototype/ に配置し、docs/prototype/screens.json（フォーマット: templates/prototype-screens.json）を記入し、スクリーンショットスクリプトを実行して各画面のpngを生成する。
⏸ 一時停止ポイント: references/prototype-analysis.md の「一時停止ポイント」に従い、ラウンドごとに質問する: 確認が必要な問題、不足している状態のデフォルト動作、ルーティングモード（history / hash）、バックエンドの現状。回答を受け取ったら、分析ファイルのセクション11、12に記録してから続行する。
ステップ3: スケルトン作成
assets/skeleton/（node_modules を除く）をコピーし、npm ci を実行する。その後、references/workflow-detail.md のステップ3に従って、名前、カラーパレット、ルーティングモード、ルートとメニュー、空のページ、権限コードを修正する。Itemサンプル機能は最初の実際の機能が完成するまで保持する。
ステップ4: ドキュメント生成
references/workflow-detail.md のステップ4の対応表に従ってコピーと記入を行う。すべての <!-- FILL: --> は指示に従って記入し、コメントを削除する。すべての {{PLACEHOLDER}} は置き換える。不明な場合は「確認中」と書き、捏造しない。
ステップ5: 検証、コミット、報告
npm run lint && npm run typecheck && npm test && npm run build
node <skill>/scripts/check-placeholders.mjs <project>
4項目すべてがパス（lintにwarningがない）、チェックスクリプトがERROR0件で完了とする。その後、初回コミットを行う。
報告フォーマットは references/workflow-detail.md のステップ5を参照。
ユーザーが不在の場合：推奨回答があるものは採用し「推奨採用（仮）」とマークする。推奨回答がないものは「確認中」と書き、通常通り続行する。両方とも報告に記載する。唯一停止すべきケースは、プロジェクトフォルダに既に内容がある場合。
ファイルインデックス
そのままコピー（名前の置き換えのみ許可、内容の書き換え不可）
| パス | コピー先 | 内容 |
|---|---|---|
assets/skeleton/ | プロジェクトルート | 実行可能スケルトン: 設定ファイル、api層、データフック、DataBoundary、権限、i18n、テーマ、MSW、テスト、CI（Azure DevOps）、PRテンプレート、Itemサンプル機能 |
references/standards/ | docs/conventions/ | 18のチーム開発標準 + インデックス |
references/adr-baseline/ | docs/adr/ | ADR 0001–0016 + インデックス |
templates/agents/ | docs/agents/ | mattpocock skills の tracker と domain docs 設定（local markdown、single-context） |
プロトタイプに基づいて記入
| テンプレート | 出力 |
|---|---|
templates/prototype-analysis.md | docs/_bootstrap/prototype-analysis.md |
templates/prototype-screens.json | docs/prototype/screens.json（スクリーンショットスクリプトの入力） |
templates/README.md、AGENTS.md、ARCHITECTURE.md、GLOSSARY.md | プロジェクトルート |
templates/CLAUDE.md | プロジェクトルート（Claude Code 用アダプタファイル: コメント行と @AGENTS.md、そのままコピー） |
templates/prototype-README.md | docs/prototype/README.md |
templates/adr-router-mode.md | docs/adr/0017-router-mode.md |
templates/api-interface-auth.md、api-interface.md、api-checklist.md | docs/api/ |
templates/feature-spec.md | docs/specs/<feature>.md |
templates/task.md、tasks-README.md、task-remove-example.md | docs/tasks/ |
templates/adr.md、bug-report.md など | コピーを docs/templates/ に保存して後で使用 |
説明とツール
| パス | いつ読むか |
|---|---|
references/workflow-detail.md | 各ステップの具体的な手順、コマンド、ファイル対応表 |
references/prototype-analysis.md | ステップ2 |
scripts/screenshot-prototype.mjs | ステップ2（プロトタイプ改版時も再実行） |
scripts/check-placeholders.mjs | ステップ5 |
mattpocock skills との連携
このスキルの出力は mattpocock/skills の入力です。プロジェクトで /setup-matt-pocock-skills を実行する必要はありません（実行しても AGENTS.md の ## Agent skills と docs/agents/ が更新されるだけで、CLAUDE.md には書き込ませないでください）。
| そのスキル | このスキルでの対応 |
|---|---|
/grill-with-docs、grilling | ステップ2の一時停止ポイントは同じ種類のインタビュー。設計変更時は直接これを使用。用語は GLOSSARY.md、決定は docs/adr/0018+ に記録 |
domain-modeling | GLOSSARY.md（同じフォーマット）と docs/adr/（チームフォーマット、docs/agents/domain.md 参照）を読み書き |
/to-spec、/to-tickets | 不要。仕様は既に docs/specs/（Gherkin番号付き）、タスクは既に docs/tasks/（階層化ファイルパスと再利用可能コンポーネント付き） |
/implement | 初版の実装方法: 一度に1つの docs/tasks/<ID>-*.md、main からタスクリストのブランチを作成。tdd と code-review を呼び出す |
tdd | seamは既に AGENTS.md「テストseam」に記述済み。議論不要 |
/implement-spec | 使用可能だが未試行: 各worktreeで npm ci（husky prepare）が必要。Azure DevOps は draft PR 統合なし |
エージェントツール互換性
AGENTS.md が唯一のルールソースです。opencode と Kimi Code CLI はプロジェクトルートの AGENTS.md を直接読みます。Claude Code は CLAUDE.md を読みます。そのため、スケルトンには @AGENTS.md のみを含むアダプタファイルを添付します。アダプタファイルに追加のルールを記述しないでください。
このスキルの更新
チーム標準を変更する場合は、このスキルを変更します（standards、adr-baseline、skeleton を一緒に変更）。CHANGELOG.md に記録し、バージョンを上げます。個別のプロジェクトでのみ変更しないでください。個別のプロジェクトの逸脱は、そのプロジェクトのADR（0017以降）に記述します。
skeleton を変更した後は、必ず assets/skeleton/ で lint、typecheck、test、build を実行します。Markdownを変更した後は npm run format を実行します。