Skill.md検索

変更前後のベンチマーク自動比較：Git Diffで変更内容を取得し、変更前後のコードでパフォーマンステストを実行して、レスポンスタイムの変化を定量的に比較します。 SQLクエリ数の監視：変更前後でN+1問題（クエリ数の多重実行）が新たに導入されていないかを検査し、データベースパフォーマンスの劣化を防止します。 メモリフットプリントの変化を追跡：メモリ使用量の増減を計測し、リソース効率の悪化を早期発見します。 インデックス追加による改善効果を検証：スキーマ変更時に、新しいインデックスが実際にパフォーマンスを改善しているかを実測で確認します。 総合的なリグレッション判定：P50・P95・P99のレスポンスタイム分布を分析し、軽微な劣化（許容範囲内）か重大なリグレッション（修正必須）かを判定します。 バックエンド・API開発者：SQLクエリやレスポンスタイムの変化を検証し、パフォーマンス劣化を防ぎたいエンジニア。 データベース最適化担当者：インデックス追加やクエリ改善が実際に効果を生んでいるか、定量的に確認したい人。 パフォーマンス監視の責任者：本番環境への影響を最小化するため、事前にリグレッションを検出したい人。 PR（プルリクエスト）レビュアー：コード変更時に自動的にパフォーマンス影響を把握し、レビュー品質を向上させたい人。 コード変更前後のパフォーマンス比較によるリグレッション検出ツール。使用方法は自動（PR自動実行）または手動（--before/--after指定）。ステップ1ではgit diffで変更内容を取得し、変更されたファイル・レイヤー（Application/Infrastructure/Presentation）を整理。ステップ2で変更前後のpnpm test:performanceをそれぞれ実行、Requests数・Duration・平均値・パーセンタイル値（P50/P95/P99）を比較。リグレッション判定は許容範囲（+10%以内）で🟡軽微劣化、超過で🔴重大劣化と判定。GraphQL Query/Mutation、Batch Processなど複数テスト項目をカバーし、各々の劣化率と原因（日付比較追加など）を記録。

指定したドメイン（例：opportunity、user、wallet）のテストのみを素早く実行し、詳細なテスト結果とカバレッジレポートを生成できます。 全体テストは数分かかりますが、特定ドメインのテストなら数秒で実行完了し、高速フィードバックループを実現します。 テスト失敗時には「どのテストが失敗したか」「どの行か」「なぜ失敗したか」の詳細と修正案を自動表示します。 カバレッジレポートを自動解析し、ステートメント・分岐・関数・行ごとのカバレッジ％を見える化します。 見つかったテストファイルを先に一覧表示し、実行前に対象を確認できるので、意図しないテストの実行を防げます。 開発中のエンジニア：自分の変更がドメイン内でどう影響しているか素早く確認したい テストファースト開発者：特定機能のテストを繰り返し実行しながら開発を進めたい QA・品質管理者：特定ドメインのテストカバレッジを定期的に監視したい 新機能開発のリード：特定ドメインのテスト網が充実しているか確認したい このスキルは、引数で指定したドメイン名（$ARGUMENTS）に基づいて、src/application/domain//{DOMAIN_NAME}//*.test.ts と __tests__//{DOMAIN_NAME}//*.test.ts に合致するテストファイルを自動検索します。ステップ1でドメイン特定→ステップ2でテストファイル一覧表示→ステップ3でテスト実行（pnpm testまたはpnpm test:coverage）→ステップ4で結果解析という4段階プロセスで動作します。実行時は--runInBandフラグを必須使用し、データベーステストのシリアル化・トランザクション競合防止を図ります。テストファイルが見つからない場合はドメイン名確認を促す警告を表示し、成功時は統計（テストスイート数・テスト数・実行時間）とカバレッジ％（Statements・Branches・Functions・Lines）を表示します。失敗時は失敗テスト名・ファイルパス・行番号・エラーメッセージ・修正案を提示します。

機能変更による見落としがちな副作用・意図しない影響を漏れなく洗い出します。 データモデル変更がビジネスロジックに与える連鎖的な影響を分析できます。 エッジケース（想定外の使い方）やユーザーエクスペリエンスの変化を事前に特定できます。 外部サービス連携・運用面・法的リスクなど、複数の観点から影響範囲を検討できます。 機能実装前にリスク対策が必要な箇所を明確化できます。 重要な機能変更の影響範囲を詳細に検討する必要がある設計者・PO バグ防止・品質向上のため、実装前に副作用をリストアップしたい開発チーム データベース変更やビジネスロジック変更の跡地調査を行いたい人 リリース前に運用面での予期しない問題を特定したい運用担当者 このスキルはユーザーが直接実行できます（user-invocable: true）。以下の分析プロセスに従って副作用を体系的に洗い出します。 実行方法 `bash /side-effect-brainstorming docs/requirements/point-expiration.md # 要件定義書から分析 /side-effect-brainstorming ポイント有効期限機能 # 機能名から分析 /side-effect-brainstorming --pr 123 # PR番号から分析 ` 分析プロセス 1. 変更内容の理解：データモデル変更・ビジネスロジック変更・新規機能を整理 2. データレベルの副作用 - 既存データとの整合性問題（既存レコードへの遡及適用など） - 複数レコード間の相互作用による問題 - パフォーマンスへの影響（クエリ増加・インデックス必要性） 3. ビジネスロジックの副作用 - ビジネスルール変更による連鎖的な影響 - ポイント経済・経営指標への波及 - ユーザー行動の予期しない変化 4. UX・運用面への副作用 - ユーザーインターフェースの意図しない変化 - 運用コストの増加・業務フロー変更 - 顧客サポート対応の増加 5. 優先度付け：各副作用を🟢Low・🟡Medium・🔴Highで評価

新機能の要件定義書を分析し、既存システムのGraphQL API・データベーススキーマ・ビジネスルールとの矛盾を自動検出できます。 フィールド型の破壊的変更、必須フィールドの追加、制約の厳格化など、既存クライアント（iOS/Android/Web）に影響を与える変更を事前に明識できます。 衝突の影響範囲、推奨対策、段階的移行プランをレポート形式で提示し、安全なシステム拡張を実現します。 バックエンド開発者で、既存APIに影響を与えずに新機能を追加したい方 プロダクト企画・PM で、技術的な破壊的変更のリスクを事前に把握したい方 マイクロサービスやマルチプラットフォーム開発チームで、API変更の影響管理が必要な方 要件定義書または機能概要から影響を受けるドメイン・データモデル変更・GraphQL API変更・ビジネスルール変更を抽出します。次に、すべてのGraphQLスキーマファイルを読み取り、影響を受ける型・Query・Mutationを検出します。衝突検出では、フィールド型の破壊的変更（Int→Float、Non-null→Nullable）、必須フィールドの追加によるクライアント互換性破壊、入力制約の厳格化（バリデーション追加）、削除されるフィールド・Query・Mutation、ビジネスルール変更との不整合を検出します。各衝突に対し、影響範囲、推奨対策（新フィールド追加・非推奨化・バージョン分離）、段階的移行プランをレポート形式で出力します。

後方互換性の自動検証: GraphQL スキーマの変更を解析し、既存クライアント（iOS/Android/Web）が破壊的な影響を受けるかどうかを自動判定できます。 破壊的変更の検出と分類: フィールド削除、型の削除、Enum値削除、Query/Mutation削除など、よくあるパターンを自動認識し、「なぜこれが破壊的か」を根拠とともに説明します。 影響範囲の可視化: 各クライアント（iOS/Android/Web）のどのファイルが影響を受けるかを具体的に特定し、修正対象を明確にできます。 安全なスキーマ進化の提案: 非推奨化（deprecation）や段階的な廃止スケジュール、代替フィールドの追加など、既存クライアントに迷惑をかけない API 進化パターンを提案できます。 API 互換性の数値化: 互換性スコアで API の「安全さ」を定量評価し、リリース判断をデータドリブンで行えます。 バックエンド開発者（GraphQL担当）: API 変更前に破壊的変更がないか自動チェックしたい フロントエンド開発者（iOS/Android/Web）: API 更新が自分たちのアプリに影響しないか事前確認したい API プロダクトマネージャー: クライアント側への負担を最小化しながら API を進化させたい QA・品質管理: API の互換性テストを自動化し、リグレッションを防ぎたい このスキルはGraphQL スキーマの互換性を複数ステップで検証。ステップ1 で変更された.graphql ファイルを特定（PR番号・ファイルパス・ドメイン名で指定可）し git diff で変更内容を取得。ステップ2 で変更を分類（Type/Input/Enum/Interface の追加・削除・フィールド変更と、Query/Mutation の追加・削除・引数変更等）。ステップ3 で破壊的変更を検出（フィールド削除、型削除、Input 必須フィールド追加、Enum値削除、Query/Mutation削除、戻り値型変更等）し、各パターンに対して「なぜ破壊的か」「どのクライアントが影響か」「代替手段」を記載。ステップ4 以降では各クライアントへの影響評価、互換性スコア算出、安全なスキーマ進化方針の提案、破壊的変更が必要な場合の移行スケジュール、API 互換性テストの実装等をカバー。allowed-tools は Read/Grep/Glob/Bash で、ユーザー実行可能（user-invocable: true）。

prisma/schema.prisma の変更を自動検出し、破壊的変更・制約欠落・命名規則违反などの一般的な問題を事前に分析・指摘できます 「add_user_phone_field」「update_opportunity_status_enum」などプロジェクトのベストプラクティスに従った説明的なマイグレーション名を自動提案します スキーマ検証結果に基づいて、外部キーのインデックス欠落や @default 欠失などの改善提案が表示され、品質が高いマイグレーションが実装できます マイグレーション実行前にユーザーに確認を求め、生成されたSQL をレビューさせることで、不正な変更を事前防止できます テーブル名の snake_case（t_users）、カラム名の camelCase（createdAt）、Enum の PascalCase など、プロジェクトの命名規則を一貫性をもって維持できます Prisma を使用したバックエンド開発で、スキーマ変更時に品質の高いマイグレーションを安全に作成したい開発者 チーム開発で複数の人がスキーマ変更を行うため、一貫した命名規則と検証プロセスを統一したい PM やテックリード 本番環境への影響が大きいプロジェクトで、マイグレーション前に SQL をレビューする体制を構築したい方 破壊的変更の防止やインデックス設計など、DBマイグレーションのベストプラクティスを学びながら進めたい初心者から中級者 このスキルは Prisma スキーマ変更をサポートします。ステップ1では git status で prisma/schema.prisma の未コミット変更を検出、変更なしは保留中マイグレーションをチェック。ステップ2 では以下の項目を検証：破壊的変更（カラム削除・型変更・テーブル削除・PKキー変更）、制約欠落（外部キーのインデックス、nullable フィールドのユニーク制約、@default 欠失）、命名規則（テーブル name:snake_case t_users、カラム:camelCase、Enum:PascalCase）、Row-Level Security（t_ プレフィックス）、インデックス戦略。ステップ3 ではマイグレーション名を {action}_{subject}_{detail} 形式（アクション: add/update/remove/fix/refactor）で提案。ステップ4 では pnpm db:migrate コマンドをユーザーに提示し、確認後に実行。ステップ5 では生成された SQL をレビューし、prisma/migrations/ に格納される。使用コマンドは /db-migration（完全ワークフロー）と /db-migration status（ステータス確認のみ）。