Skill.md検索

ドメイン構造の自動初期化: 要件ドキュメントから適切なドメイン分割を判定し、各ドメインの責務を明確に定義できます。 インターフェース定義の事前確定: 複数ドメイン間のAPI・データ型・イベントを先に決めることで、各チームが独立して実装できるようになります。 共通基盤の優先実行: 複数機能が使う共通UIやユーティリティを最初に完成させ、その後の開発をブロッキングなく進められます。 並列実行フェーズの自動調整: フェーズ0〜3に分けて、どの機能が同時実行できるか自動判定し、無駄な待ち時間を削減します。 マージ順序の自動制御: 各フェーズの完了後に自動的にmainへのマージを促し、古いブランチからの分岐によるコンフリクトを防ぎます。 複数機能を同時に開発したいプロジェクトマネージャー: チーム間の依存関係を構造的に管理でき、スケジュール遅延を防げます。 大規模なバックエンド開発を指揮する技術リード: ドメイン駆動設計（DDD）の考え方を実装段階で具体化できます。 初期段階で全体の設計を定めたい開発チーム: 曖昧なインターフェース定義のままコードを書き始める問題を回避できます。 複数チームの調整役を務める人: 「何をいつ開始するか」の判断基準が明確になり、進捗報告がしやすくなります。 SuperPMは判断と調整のみ行い、コード実装は行いません。domains/ディレクトリが存在しない場合、初期化フェーズで要件定義書とインターフェース定義から各ドメインを決定し、テンプレートをコピーしてドメイン間IF定義ファイルを作成します。並列実行時は「フェーズ0（IF定義確定）→ フェーズ1（共通基盤）→ フェーズ2（独立機能）→ フェーズ3（依存関係あり機能）」の4段階に分割し、各フェーズ完了後にmainマージしてから次フェーズを開始します。共通基盤は複数機能が共通で必要とするUI・ユーティリティ・認証などを特定し、shared-components.mdにインターフェース付きで記録。全機能の要件分析から不足コンポーネントを洗い出し、共通基盤タスク完了まで個別機能を起動しません。2回目以降は既存shared-components.mdで不足部分を確認する仕組みです。

本番障害を素早く原因特定して修正できる 5分以内に障害内容・原因箇所・修正方針をユーザーに提示し、コード修正に集中できます。 修正範囲を最小限に保てる ホットフィックスモードで「余計なリファクタリング」を排除し、障害の原因箇所のみの修正に限定できるので、予期しない副作用を防げます。 修正後の設計書同期を忘れずに実施できる コード先行を許可しながらも、24時間以内のSpec同期を自動で催促し、設計書とコードの乖離を防げます。 被依存Specへの影響確認ができる 修正対象の要件に依存している他の仕様を逆引きで特定し、回帰テストを漏らさないようサポートします。 再発防止策まで提案できる 根本原因のレビュー後、テスト不足・設計不備・監視不足のいずれが原因かを分析し、次のアクション（テスト追加、仕様見直し、非機能要件の拡充）を提案できます。 本番環境で障害が発生し、「今すぐ直さないといけない」という場面にいる開発者・プロジェクトマネージャー 通常の「設計書ファースト」フローでは間に合わない、緊急度の高いバグ修正に対応したい人 セキュリティ脆弱性など、即座の修正が必要な案件を扱う人 ホットフィックス後も、Spec同期や再発防止を体系的に進めたい人 緊急修正（ホットフィックス）は設計書ファースト原則の例外措置。使用条件：本番環境で障害が発生している、ユーザーが「緊急」「至急」「ホットフィックス」と指示、セキュリティ脆弱性の即時修正が必要。該当しない場合は revise-spec への誘導を提案。フェーズ1障害把握（5分以内）：ユーザーから障害内容を聞く、該当REQ-IDを特定（不明なら REQ-HOTFIX-NNN で仮採番）、2段階探索（code-search-2stage.md）で原因箇所を特定、修正方針をユーザーに提示（障害・原因・修正方針・影響範囲）。フェーズ2コード修正：hotfix/[Spec ID] ブランチ作成（feature/ ではなく hotfix/ を使用）、最小限の修正で障害原因箇所のみに限定、既存テスト全てパス確認、障害再現テストを追加（可能な場合）、コミットメッセージに [HOTFIX] と障害内容記載（Spec同期：未完了（24h以内に実施すること）を明記）。フェーズ3Spec同期（24時間以内）：修正デプロイ後、該当Spec要件定義書を更新、spec-map.yml操作ガイドに従い spec-map.yml を更新、基本設計への影響があれば設計書も更新、docs: [HOTFIX] Spec同期 コミット。フェーズ3b被依存Spec影響確認：spec-map.yml で修正対象REQ-IDに依存しているSpec（被依存先）を逆引きで特定、実装済みSpec のテスト実行で回帰確認（不可能な場合は manual-test-cases.xlsx に「[REQ-YYY] ホットフィックス後の回帰確認」追加）、該当Spec一覧をユーザーに通知。フェーズ4振り返り：障害根本原因をユーザーに報告、再発防止策を提案（テスト不足→gen-testsで補強、設計不備→revise-specで仕様見直し、監視不足→非機能要件追加）、finish-impl.md同様のテンプレートフィードバックチェック。ルール：修正最小限、Spec同期必須24時間以内、仮REQ-ID は後で統合、PR作成は不要（コミットまで）。

開発中に見つけた問題や改善点を、自動的にテンプレートリポジトリ（元になるプロジェクト設定）にPR（プルリクエスト）として提案できます。 「他のプロジェクトでも同じ問題が起きそう」という問題を自動で判定し、テンプレートに反映するかどうかをユーザーに提案します。 CI設定の不具合、非推奨APIの修正、スキルの手順不足など、様々な問題タイプに対応して適切な修正先を自動判定します。 プロジェクト固有の情報（APIキーやURLなど）を自動で除去し、他プロジェクトでも使えるようにテンプレートを整理します。 複数のプロジェクトをテンプレートから作成・管理している開発チームリーダー 開発中に「これはテンプレートにも反映すべき改善だ」と気づく開発者 テンプレートの品質を継続的に改善したいプロジェクト管理者 問題の分析（何が起きたか、なぜか）→ 汎用化判定（他プロジェクトでも起きうるか）→ 修正先の特定（CLAUDE.md、CI設定、スキル等）→ テンプレートリポのクローン・ブランチ作成 → 修正実施（プロジェクト固有情報を除去）→ コミット・プッシュ・PR作成の流れで動作します。修正は「プロジェクト固有の情報（リポ名、URL、APIキー、ポート番号）は含めない」というルールに従い、テンプレートリポの.claude/CLAUDE.mdの共通ルール部分やコメント内の例示のみを修正対象とします。既存のスキル構造を壊さず手順追加のみを行います。

既に実装されている機能の仕様変更をする際に、要件定義書→基本設計→コード→テストを一貫して同期させます。 変更内容の種別（見た目のみ/動作ロジック変更/機能追加）を自動判定し、必要な更新範囲を特定します。 変更したい機能が他の機能に依存している場合の影響範囲を、依存グラフから自動抽出して可視化します。 仕様書の統一基盤（unified-base）を確認し、新しい概念が出た場合は用語集（glossary）に自動追記します。 API変更がある場合、openapi.yaml の存在確認と更新を含めた一括チェックができます。 開発チームのリーダーで、仕様変更の影響範囲を正確に把握したい方 プロダクトマネージャーで、要件変更時に開発側への負担を最小化したい方 技術仕様書とコード実装のズレを防ぎたい方 複雑なシステムで、変更による予期しない副作用を事前に検出したい方 分析フェーズでは①該当Spec読み込み、②2段階探索によるコード全体把握、③spec-map.yml による依存Spec健全性チェック（confirmed == spec_version の確認）、④openapi.yaml 存在確認（API変更時）を実施します。変更種別を自動判定し、見た目変更のみならばコード修正のみ、動作変更なら要件定義書・基本設計・コード・テスト全て同期更新を行います。依存グラフ影響分析では推移的閉包を構築し、直接依存と推移的依存を区別して影響範囲を特定します。循環依存検出、dependency-graph.md との突合も含まれます。

要件定義書（features/*.md）の受入条件から自動的に、システムテスト仕様書を生成できます。 エンドユーザー向けの受入テスト（UAT）仕様書をビジネス用語で分かりやすく生成できます。 要件から導出した具体的なテストステップ（「ログインする」ではなく「メールアドレスとパスワードを入力し、ログインボタンをクリックする」）で、テスト漏れを防げます。 APIドキュメント（OpenAPI）や画面遷移図から、テストシナリオを自動導出できます。 テンプレートに従うため、ドキュメント品質が安定し、作成時間を大幅削減できます。 QA・テスト担当者（テスト仕様書作成を効率化したい人） プロジェクトマネージャー（テスト工程の準備を加速したい人） 開発チーム（要件からテスト仕様書まで一気通貫で生成したい人） 受入テストを実施するビジネスユーザー（非技術者向け手順書が必要な人） 前提ファイル: features/*.md（受入条件）、OpenAPI YAML（API仕様）、screen-flow.md（画面遷移）、*-logic.md（ビジネスロジック）。これらの存在をチェックして、不足があれば報告・停止。 生成手順: テンプレート読み込み → 要件定義から受入条件を全て抽出 → ユーザーに生成対象を確認 → システムテスト仕様書を生成（機能テスト、非機能テストを記載）→ UAT仕様書を生成（ビジネスシナリオ、非技術者向け手順を記載）→ mkdocs.ymlに追加 → 次ステップを提案。 ルール: テンプレート構成を維持（削除不可、追加は可）。シナリオは要件に基づき推測で作らない。UATは非エンジニアが実施できる表現。実装コード存在時は実際のUI要素（画面名・ボタン名）に合わせる。

開発中のウェブアプリケーションの画面をスクリーンショットで確認できます。 複雑なUIのアクセシビリティツリー（要素の構造・テキスト・ボタン配置）をテキストで取得し、分析できます。 ログイン・フォーム入力・ボタンクリック・セレクト操作など、ブラウザ上のインタラクション（操作）を自動実行できます。 APIの通信内容（ネットワークリクエスト・レスポンス）をキャプチャ・確認できます。 バグ調査や画面の現状把握を素早く行えます。 開発中のフロントエンド画面をAIに見てもらいながら改善指示したい開発者 複雑な画面のバグ原因を特定するため、AIと一緒に操作・確認したい人 E2Eテスト作成前に、実際の画面動作を確認・検証したい人 認証が必要なページにログインして、その先の画面をAIに確認させたい人 このスキルは開発中の画面を確認する「AIの目」として機能します。テスト実行ツールではなく、観察・調査・確認目的で使用します。 基本フロー 1. ページを開く：agent-browser open 2. 画面状態を把握：snapshot（テキスト・効率的）またはscreenshot（画像・視覚的） 3. 要素を操作：snapshot取得時の@ref参照を使用してクリック・入力・選択を実行 4. 遷移・待機：ページ遷移完了を待ち、新しい画面状態を再度snapshot snapshot（テキスト）の利点 アクセシビリティツリー形式で出力（@e1、@e2などの参照付き） トークン効率が良い（シンプルな画面向き） 要素参照をそのまま操作に使える screenshot（画像）の利点 複雑な画面・レイアウト全体を視覚的に把握 テーブル多数の場面で効率的 ログイン・認証対応 認証情報は.env.testやCLAUDE.mdの「テスト設定」セクションから読み取る ハードコード（スキルに直書き）は禁止 ネットワーク調査 agent-browser network har start/stopでAPI通信をキャプチャ agent-browser network requestsでリクエスト一覧を確認

アーキテクチャ図、フローチャート、ER図、ネットワーク構成図などを自動作成できます。 Draw.ioの.drawio形式で高度にカスタマイズされた図を生成し、MkDocsドキュメントに自動埋め込みできます。 Mermaidでは表現しきれない複雑な図（AWS/GCP等のアイコン豊富、レイアウト自由度が高い）を作成できます。 既存の図を編集・改善し、バージョン管理できます。 システムアーキテクチャを図で説明したいエンジニア・技術リード インフラやネットワーク構成図を頻繁に作成・更新する運用チーム ドキュメント（MkDocs）に自動で図を組み込みたいドキュメント担当者 営業提案資料で複雑なシステム図を視覚的に説明したい営業・コンサルタント

ユニットテスト、E2Eテスト（Playwright）、APIテストを自動生成できます。 TDDモード（テスト駆動開発）で、実装前にテストコードを先行生成し、テストを起点に開発を進められます。 既存テストの不足箇所を自動検出し、カバレッジを高めるテストを追加できます。 テスト設計書の情報を活用し、ビジネス要件に沿った包括的なテストを生成できます。 正常系・異常系・境界値テストなど、多角的なテストケースを自動作成できます。 テスト駆動開発（TDD）を導入・実践したい開発チーム テストカバレッジを高め、品質を向上させたいQAエンジニア 既存プロジェクトのテスト整備に時間をかけたくない急成長スタートアップ Playwright、Jest等のテストフレームワークを使いこなしたい開発者

セキュリティ、コード品質、アーキテクチャ、ドメインロジック、テスト・ドキュメントの5つの観点から、同時並列でPRを自動レビューできます。 XSS・SQLインジェクション・認証バイパスなどセキュリティリスクを検出します。 型安全性、エラーハンドリング、命名規則、パフォーマンス問題を指摘できます。 ビジネスロジックの配置、ドメイン知識の散在、外部依存の設計上の問題を検出できます。 PR番号やURLを指定するだけで自動実行され、レビュー結果を統合レポートで出力できます。 コードレビューの属人性を減らし、高速化したい開発チーム セキュリティリスクを早期発見したいセキュリティチーム・リード ドメイン駆動設計（DDD）の原則を保ちたい設計思想重視の組織 PRレビューの負担を削減し、より高度なレビュー（ビジネス価値検証等）に集中したい技術リード