yamasaki

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を使う）。

レビューマーカーの一覧・承認・除去を行う。「未承認一覧見せて」「r-XXXX を承認して」「このファイルのレビュー全部承認して」「レビューマーカー一覧」「要確認一覧」等のリクエストで発火する。

新機能の要件定義。自然言語の入力から質問→要件定義書を自動生成する。 「通知機能を作りたい」「こういう機能がほしい」「○○ができるようにして」 「新しく○○を追加したい」「○○機能の要件を作って」などのリクエストで使用する。 まだコードが存在しない新機能を定義するときに使う。既存コードのSpec化にはspec-featureを使う。

実装済み機能の仕様変更。要件定義書と基本設計を先に更新してからコード修正→テスト→レビューを実行する。 変更種別を自動判定し、実装はAgent(Sonnet)に委任可能、レビューは本体が直接実行する。 「アップロード上限を10MBに変えて」「この画面にフィールド追加して」「○○の仕様を変更して」 「○○を修正して」「バリデーションを変えて」などのリクエストで使用する。 既に実装済みの機能を変更するときに使う。新規実装はimplement-spec。

NotebookLMからナレッジ（議事録・決定事項・背景情報）を検索して参照する。 「ミーティングの内容を確認して」「先週の決定事項を踏まえて」「会議で話した方針で」 「議事録を参照して」「MTGの背景を確認して」「ノートブックで調べて」 「NotebookLMを検索して」などのリクエストで発火する。

MkDocs プレビュー（:8000）と承認API（:8765）を同時起動する。「ドックを起動して」「docsプレビュー見たい」「設計書をブラウザで確認したい」「承認ボタン使いたい」等のリクエストで発火する。

テンプレートリポの最新をプロジェクトに取り込む。 「テンプレートの最新を取り込んで」「テンプレートを同期して」「スキルを更新して」 「テンプレートをアップデートして」などのリクエストで使用する。

既存プロジェクトに新しいリポジトリを追加する。Workspaceにリポを追加した後、 CLAUDE.md・設計書・ドメイン構成を差分更新する。 「モバイルリポを追加した」「新しいリポを取り込んで」「リポを追加したので設計書を更新して」 「Workspaceにリポを足した」などのリクエストで使用する。 init-spec の移行モードではファイル存在チェックしか行わないため、 既存ドキュメントの内容を新リポに合わせて拡張するにはこのスキルを使う。

Always use when user asks to create, generate, draw, or design a diagram, flowchart, architecture diagram, ER diagram, sequence diagram, class diagram, network diagram, or mentions draw.io, drawio, .drawio files. Use for complex diagrams where Mermaid is insufficient.

全リクエストの受け皿。質問・相談・調査・実装・修正・GitHubイシュー対応など、 あらゆる開発リクエストを受け取り、内容に応じて最適な対応方法を選択する。 「対応して」「直して」「やって」「見て」「確認して」「どう思う？」 「相談したい」「壁打ちしたい」等の汎用的な指示で発火する。

Specに基づく新規機能実装。要件定義書と基本設計を読んで実装プラン作成→コード実装→テスト→レビューを実行する。 実装はAgent(Sonnet)に委任可能、レビューは本体が直接実行する。 「REQ-AUTH-001を実装して」「ログイン機能を作って」「○○を実装して」 「これを作って」「実装に入って」などのリクエストで使用する。 要件定義書が存在する未実装機能を新規実装するときに使う。既存機能の変更はrevise-spec。

SKILLポートフォリオの健全性を監査する。実セッションのトランスクリプトを分析し、 ルーティング正確性・注意力予算・スキル間競合・カバレッジギャップを定量評価する。 「スキルの動作確認をして」「SKILLが正常か確認して」「スキル監査して」 「skill audit」「スキルの健全性チェック」などのリクエストで使用する。 disable-model-invocation: false

ブラウザで画面を確認する。agent-browser CLI を使って画面のスクリーンショット撮影、 アクセシビリティツリー取得、フォーム操作、画面遷移などを行う。 「画面見て」「ブラウザ確認して」「スクショ撮って」「現状把握して」「画面開いて」 「ログインして確認して」「画面の状態を教えて」「UIを確認して」などのリクエストで使用する。 E2Eテストの作成・実行には gen-tests（Playwright）を使うこと。本スキルはテスト実行ではなく 「AIの目」としてブラウザを操作し、画面状態を把握するためのもの。

テンプレートへのフィードバック。開発中の問題や改善点をテンプレートリポにPRとして反映する。 「テンプレートに反映して」「テンプレートを改善して」「テンプレートにフィードバックして」 「親テンプレートにPR作成して」「テンプレートリポにPRして」 「これをテンプレートに反映したい」などのリクエストで使用する。 sync-templateは取り込み（pull）、本スキルは反映（push/PR）。

PRコードレビュー。複数の観点（ロジック・セキュリティ・パフォーマンス・設計整合性）で 並列レビューし、統合結果を出力する。 「PRをレビューして」「このPRの問題点を見て」「PR#123を確認して」 「コードレビューして」などのリクエストで使用する。 PR番号・URL指定、またはカレントブランチのPRを自動検出する。

既存プロジェクトをサブエージェントで並列分析し、 精度の高い overview.md を生成する。init-spec の前処理として使う。 「既存プロジェクトを分析して」「コードベースを理解して設計書を作って」 「overview.mdを作って」などのリクエストで使用する。 ファイル数が200を超えるプロジェクトで特に有効。 200以下の場合は単一エージェントで全体を読む方が精度が高いため、 init-spec をそのまま実行することを提案する。

デザインの差し替え。ロジックは一切触らず見た目（HTML/CSS/テンプレート）だけを更新する。 「このデザインに差し替えて」「UIをFigmaの通りに変えて」「見た目だけ変えて」 「デザインを更新して」「CSSだけ直して」などのリクエストで使用する。 ロジック変更を伴う場合はrevise-specを使う。

ドメインPMとして、SuperPMから受け取ったタスクをPG単位に分解し実装を指揮する。 domains/[ドメイン名]/ ディレクトリ内で実行すること。 orchestrate スキルで起動された場合に自動的に呼ばれる。 ユーザーが直接呼び出すことはない（orchestrate経由専用）。

テスト実行結果を集計してテスト結果報告書を生成する。 「テスト報告書を作って」「テスト結果をまとめて」「リリース判定用の報告書が必要」などのリクエストで使用する。

システムテスト・受入テスト（UAT）の仕様書をテンプレートから生成する。 「システムテスト仕様書を作って」「UATを準備して」「受入テストの仕様書が必要」などのリクエストで使用する。

テストの追加・補強・作り直し。TDDモード（実装前テスト先行生成）にも対応。 Playwright・Jest等のE2Eテスト、ユニットテスト、APIテストの新規作成・補強を行う。 「テストを書いて」「カバレッジを上げて」「テストを作り直して」「E2Eテストを作って」 「自動テストを作成して」「Playwrightでテストして」「操作テストを作って」 「○○のテストを実装して」「バックエンドテストを作って」などのリクエストで使用する。

緊急修正（ホットフィックス）。本番障害時にコード先行で修正し、Spec同期を後追いで行う。 設計書ファースト原則の例外措置。通常の仕様変更には revise-spec を使うこと。 「本番が落ちた」「緊急で直して」「ホットフィックスが必要」「本番バグを修正して」 「至急○○を修正して」などのリクエストで使用する。

SuperPMとしてタスクをドメインPM経由でPGに配布する。 実装を伴うリクエストで自動的に選択される。 3層構造の方針と理由は .claude/CLAUDE.md を参照。