Skill.md検索

データベース設計の妥当性を事前検証する テーブル構造、カラム設計、制約条件（ユニーク制約、外部キーなど）を整理し、実装前に技術的な問題がないか確認できます。 N+1クエリやトランザクション問題を設計段階で防ぐ データ取得パターンを分析して必要なインデックスやプリロード戦略を先に定めることで、後からの修正を避けられます。 複数の技術案のトレードオフを見える化する 実装コスト、拡張性、既存システムとの相性などを表形式で比較し、チーム全体で納得できる選択肢を選べます。 実装に入る前に確実な合意を取る 「合意なくして実装に進まない」原則に従い、ユーザーとClaudeで設計内容を相互レビューして承認を得てから次フェーズに進みます。 設計意図をドキュメント化する なぜその設計にしたのか、別案を採用しなかった理由を明記することで、後の保守時に判断の背景が理解しやすくなります。 バックエンド開発者・リードエンジニア システム実装前に技術的な落とし穴を見つけたい開発者 データベース設計者 大規模なスキーマ変更や新機能追加時に設計案をレビューしてもらいたい人 プロダクトマネージャー・PO 技術的なトレードオフを理解した上で要件を確定させたい人 チームリーダー チーム内で設計の合意形成を効率的に進めたい管理職 Phase 1（設計合意）はPhase 0（インテイク）での合意済み要約・スコープ・受入条件をベースに実行します。推奨モデルはopusです。実行フロー：design.mdで設計方針を再確認 → 現在のコードベース（モデル・スキーマ・コントローラ・ルーティング）調査 → 観点別に設計整理（データ構造・DB制約・N+1・トランザクション・Service分離）→ 複数案がある場合はトレードオフを提示して合意取得 → セルフレビュー実行 → 設計ドキュメント保存。出力フォーマットは「この設計で作るもの」「目的」「スコープ（含むもの/含まないもの）」「設計方針（トレードオフ表付き採用理由）」「データ設計（DB制約表付き）」の各セクションで、各セクションには必ず設計意図を記載して、「何を作るか→なぜその設計か→どう作るか→完了条件→結論」の順序で出力します。

Phase 1（設計合意）の内容を基に、GitHub Issueを正式に作成できます。 「目的」「背景」「設計」「ユーザーフロー」「スコープ」「受入条件」「検証」「改善」「制約」の9セクションを自動で構成し、体系的なIssueを生成します。 Issue作成前に既存の類似Issueを自動検索し、重複を防げます。 Issue番号を含む命名規則のブランチ（例: feature/114-dashboard-ui-consistency）を自動生成できます。 GitHub ProjectへのIssue自動紐づけ、最新のmainブランチへの同期を自動化します。 設計フェーズから実装フェーズに移行するタイミングで、Issueを体系的に作成したい開発チーム 受入条件・検証項目を漏れなく記載したIssueを作成したい品質管理担当者 「いま何をするのか」を明確にしたブランチ作成とIssue連携を実現したい開発リーダー GitHub Issue・プロジェクト・ブランチ管理の工数を削減したい誰もが このスキルは、Phase 1の設計合意完了後に呼び出され、以下4つのステップで実行されます。鉄則: Phase 1合意なしにIssueは作成しません。 Step 0: gh issue list で既存の開いているIssue（最大50件）を確認し、類似Issueがないかチェックします。見つかった場合はユーザーに提示し、既存利用か新規作成かを確認します。 Step 1: Phase 0～1の合意内容を確認し、不足があれば $ARGUMENTS から内容を整理。Issueタイトル・各セクション・ラベルをAskUserQuestionで確認します。 Step 2: gh issue create で「目的」「背景」「設計」「ユーザーフロー」「スコープ」「スコープ外」「受入条件（チェックリスト）」「検証（正常系・異常系・既存影響）」「改善（既知課題・将来拡張）」「制約」の9セクションを含むIssueを作成し、GitHub Project「hobby-matching-app」に紐づけます。 Step 3: git checkout main && git pull && git checkout -b feature/- でmain最新からブランチを作成します。完了時にIssue URLと作成ブランチ名を表示します。

要件の構造化整理: 依頼内容を「要約・目的・スコープ・受入条件・制約・未確定事項」として系統立てて整理できます。 未確定事項の洗い出し: 仕様の曖昧さや判断が必要な事項を1つずつ特定し、実装前にすべて解決できます。 質問を1つずつ提示: ユーザーの負担を減らすため、複数の質問を一度に投げず、ステップバイステップで確認できます。 選択肢型の質問: 曖昧なオープン質問ではなく、選択肢を示して的確な意思決定をサポートできます。 設計方針との整合性確認: .claude/design.md を読み込み、プロジェクトの既存設計方針に準拠した要件整理ができます。 新機能の追加やバグ修正を依頼したいが、最初の説明が曖昧なままエンジニアに投げたくない人 要件定義を形式化し、実装前の認識ズレを最小化したい PO・PM 複雑な仕様変更を伴う案件で、漏れなく確認事項をリストアップしたい人 エンジニアとのコミュニケーションコストを削減し、実装効率を上げたい人 推奨モデル: 要件整理には Claude Sonnet で十分（現在のモデルが Sonnet でない場合は切り替え確認)。 鉄則: 未確定事項が残る限り、実装提案は禁止。 プロセス: (1) .claude/design.md を読み設計方針把握 → (2) 依頼内容を分析 → (3) フォーマットで整理 → (4) 未確定事項の有無判定 → (5) あれば AskUserQuestion で1つずつ質問 → (6) すべて解決したら最終整理結果を提示。 出力フォーマット: 要約（1〜3行）、目的、スコープ（変更対象・影響範囲）、受入条件（チェックリスト形式）、制約（技術的ルール）、未確定事項（列挙）。 ルール: 複数質問は禁止、選択肢がある場合は選択式で提示、仕様の曖昧さはこのPhaseで必ず解決する。