Skill.md検索

ローカル開発環境、Vercel、Neon、GitHub Actions など複数のインフラ環境を一括でセットアップできます。対話的に進めるので、手順書をいちいち確認する手間が減ります。 環境変数（.env.keys など）の初期化と管理を自動化でき、worktree（複数ブランチ環境）でも自動で必要なファイルをコピーしてくれます。 デプロイ設定、GitHub Secrets、CI/CD ワークフローなどインフラ周りの設定を一度に整理できるので、本番環境へのデプロイ時のミスを減らせます。 環境状態を自動検出し、セットアップ済み/未設定を判定して、必要な作業だけを提案してくれます。 新しいプロジェクトを始めるときに環境構築の手間を減らしたい開発者 チーム開発で環境設定のばらつきを統一したい人 Vercel や Neon などのクラウドサービスの連携設定が複雑に感じる人 CI/CD パイプラインを一度に整える必要がある DevOps エンジニア このスキルは対話的なワークフロー定義です。起動時に環境状態を自動検出し、Phase 0（環境セットアップモード判定）→ Phase 1（環境状態の自動検出）→ Phase 2（意図判定）という3段階のフローで進みます。ユーザーの発話に明示意図がある場合（「Vercel だけ設定したい」など）はそのカテゴリに直接遷移します。worktree 環境では.env.keysをメインリポジトリから自動コピーを試行し、セットアップ未完了時は提案モードで対応します。参照ドキュメント（environment-variables.md、deployment.md、environment-setup.md など）はカテゴリ実行時にのみ読み込むことで、効率性を重視した設計になっています。

AC（受け入れ条件）の自動検証: 仕様書に記載された条件を自動テストで確認し、実装が要件を満たしているか即座に判定できます。 E2E・統合テストの実行: 画面フロー、API連携、データ永続化など、複数コンポーネント間の連携動作を検証します。 テスト結果の可視化: テスト実行結果を qa-tests/ に記録し、どの条件が合格・失敗したかを明確に把握できます。 失敗原因の自動分類: 10パターンの失敗原因（実装ミス、要件未定義など）から原因を特定し、対応方針を示唆します。 トラブルシューティング: よくある6つのエラーケースに対する解決手順を提供します。 QAエンジニア: Playwright、Selenium、Jest、Cypressなどのテストツールを使い、自動テストスイートを構築・実行したい方 開発チーム: 単体テストだけでなく、画面操作やAPI連携の統合動作まで確実に検証したい プロダクトマネージャー: テスト実行状況をリアルタイムで把握し、品質ゲート判定を自動化したい DevOpsエンジニア: CI/CDパイプラインにテスト自動実行を組み込みたい このスキルは、QAエンジニアリングの12年以上の経験を持つスペシャリストが、Playwright、Selenium、Jest、Cypressなどのテストツールを用いてE2Eテストからユニットテストまで幅広いテスト戦略を立案・実行します。 中核は「単体テスト（開発者が実装）」と異なる「統合確認（画面フロー、API連携、データ永続化）」の実施です。 実行手順は8ステップで、(0)引数解析、(1)仕様書読み込み・AC抽出、(2)必須自動テスト実行（ユニットテスト、E2E、Lint、ビルド、型チェック：全成功が必須）、(3)テスト仕様読み込み、(4-7)以降のテスト実行と結果記録です。重要な参照ドキュメントは failure-patterns.md（10パターン）、usage-patterns.md（5パターン）、troubleshooting.md（6ケース）、acceptance-criteria-and-qa-guide.md です。

すべてのサブエージェント（フロントエンド設計者、デザインエンジニア、バックエンド開発者など）が同じ出力形式で結果を報告するため、プロジェクト全体の進捗管理が統一され、情報の検索・把握が容易になります。 エージェント別のテンプレート（フロントエンドアーキテクト、デザインエンジニア、バックエンドアーキテクト、Codexエージェント）が明確に定義されているため、各専門分野の結果を一貫性を保ちながら報告できます。 出力結果を要約・省略することが禁止されているため、ユーザーは最終出力をそのまま信頼でき、重要な情報が失われることがありません。 50行を超える長い出力は詳細表示タグで折りたたみ可能な形式で提供されるため、可読性を損なわずに完全情報を保持できます。 複数のAIエージェントを使用して大規模プロジェクトを進行管理する マネージャー、チームリーダー フロントエンド、バックエンド、デザインなど複数領域の出力を統一的に確認したい開発チーム AIエージェントの出力品質・一貫性を重視するエンタープライズプロジェクト 統一出力形式の必須ルールとして、完全出力の原則（最終出力はユーザーに全文表示）、省略・要約の禁止、この形式からの逸脱禁止の3項目を規定。標準構造は「フェーズ名完了」という見出しに始まり、タスク情報、成功/部分成功/失敗ステータス、サマリー（主要結果・数値）、詳細（項目別情報）、次のステップで構成。frontend-architectは「コンポーネント数・カスタムHooks数・新規ディレクトリ数」を含むサマリー、コンポーネント構造図、状態管理戦略テーブル、技術選定を出力。design-engineerはデザイントークン抽出数、生成/更新ファイル数を報告。frontend-coderは新規作成ファイル数、編集ファイル数、主要機能、ファイル一覧テーブルを提供。backend-architectはAPI数・Repository数・UseCase数・Entity数・テーブル数のサマリー、層間依存関係、デザインパターン適用、DB設計、API設計、テスト設計方針を報告。codex-agentは作業モード（レビュー/実装/バグ修正/リファクタリング/調査）を記載。長い出力（50行超）は最初10行をサマリーとして表示し、残りを詳細タグで折りたたみ表示。

生成されたタスク一覧（Markdown形式）のフォーマットを自動検証し、違反を検出できます。 構造・インデント・メタデータ・依存関係・ATDD・横切り・任意項目など、7カテゴリーの検証を実行します。 違反を発見した場合、エラーレポート（Markdown形式）を自動生成し、修正案を提示します。 「Task X-Y」形式の禁止ID表記や、太字でないメタデータキーなど、致命的なエラーは即座に検出します。 リトライ回数（デフォルト3回まで）を管理し、修正→再検証のサイクルをトラッキングできます。 GitHub Issueのタスク仕様書を自動生成しており、フォーマット品質を確保したい開発チーム ATDD（Acceptance Test Driven Development）に基づいたタスク管理を実践している方 「レイヤーごと」「画面ごと」といった横切り分割を検出し、縦切り（フルスタック）な粒度を強制したい方 Phase・タスクグループ・タスクの3階層構造を厳密に管理したい誰もが このスキルは、einja-issue-spec-create Skillから呼び出される tasks-validator サブエージェントが使用します。入力は検証対象のタスク一覧Markdown、現在のリトライ回数（0～）、最大リトライ回数（デフォルト3）です。 成功時は「バリデーション結果: SUCCESS」を返却。失敗時は「バリデーション結果: FAILURE」と共に、エラー一覧（タスク番号・エラー種別・問題説明・修正案）およびリトライ情報（現在の試行回数・最大回数・残り回数）を返却します。 検証項目: (0)構造前提チェック（最優先・即FAILURE）では、「Task X-Y」形式のID表記、太字でないメタデータキー、3階層構造の欠落を検出。(1)構造検証でPhase連番・タスクID形式をチェック。(2)インデント検証で2・4スペース規則を確認。(3)メタデータ検証で「要件」「実装AC」「依存関係」「完了条件」「対応設計」「シナリオテスト」の6項目を必須確認。(4)依存関係検証で参照先存在・循環依存・書式をチェック。(5)ATDDチェックでPhase数2～3個、タスクグループが縦切りか確認。(6)横切り検出（最重要）で、タスクグループ名に禁止ワード（Domain、Infra、API、UI、Repository、Entity等、レイヤー・クラス・画面単位の分割）が含まれていないか検査。(7)任意メタデータ検証で記載されている項目のみ形式チェック。

Reactコードの健康状態を数値化 - oxlint と knip をベースに60以上のルールでコードを分析し、0〜100のヘルススコアを算出します。 カテゴリ別の問題を検出 - 状態管理・パフォーマンス・セキュリティ・アクセシビリティ・Next.js固有など8つのカテゴリで問題を分類し、優先度を明確にします。 ファイル名・行番号付きで問題を特定 - 各問題の具体的な場所を示すため、修正アクションにすぐつなげられます。 モノレポ対応の柔軟なスキャン - プロジェクト全体または特定アプリケーションディレクトリを指定でき、差分モード（--diff）による変更ファイル限定スキャンもサポートします。 React/Next.jsプロジェクトのコード品質を定期的に監視・改善したい開発チーム CI/CD パイプラインに自動コード診断を組み込みたいエンジニア モノレポ構成の複数アプリケーションの健全性を一括管理したい人 react-doctor は oxlint + knip ベースの Reactコードベースヘルススキャナーで、0〜100のヘルススコアを出力します。 カバー範囲: useState/useEffect誤用、不要な再レンダリング、メモ化欠如、アニメーション非効率、バンドルサイズ肥大化、セキュリティリスク（dangerouslySetInnerHTML等）、アクセシビリティ欠陥、Next.js固有違反、デッドコード・未使用依存関係。 実行方法: モノレポの場合は対象アプリケーションディレクトリを特定し、npx -y react-doctor@latest --verboseで実行。--diff mainで mainブランチとの差分のみ診断可能。 出力: ヘルススコア（総合）、カテゴリ別問題数、ファイル名・行番号付き詳細。スコア90〜100は優秀、70〜89は良好、50〜69は要改善、0〜49は要注意。モノレポでは各アプリを個別実行推奨。

参照元の最新情報を自動検出: GitHub、npm、ドキュメントサイトなどから外部ツール・ライブラリの最新情報を自動収集し、Skillの内容と比較します。 差分を構造化して提示: 新ルール追加、オプション変更、破壊的変更（互換性を損なう更新）など、何が変わったかを分かりやすく整理して報告します。 承認ベースで安全に更新: ユーザー確認後のみSkillを更新し、誤った変更を防ぎます。 一括管理で管理コストを削減: 複数のSkillを一度にスキャンして、どれが更新の対象かを可視化します。 外部ツール・ライブラリの更新に追従させたいSkill開発者 古い情報で誤った指示を出したくないAIエンジニア 多数のSkillを管理していてメンテナンス負荷が大きいチームリーダー セキュリティアップデートを見落としたくないセキュリティ意識が高い開発者 対象Skillを特定し、本文中の``ブロック（url、type、descriptionを含む）をスキャン。WebFetchで各参照元を取得し、GitHubリポジトリならREADME.md、npmパッケージなら最新レジストリ情報、ドキュメントページなら該当内容を取得。現在のSkill内容と参照元の最新情報を比較して差分を検出。変更がある場合はCritical（致命的）、Important（重要）、Consider（検討推奨）の3段階で優先度分け。AskUserQuestionでユーザーに更新内容を提示し、承認後のみSkillを更新。失敗したWebFetchはスキップして次に進む。大幅な変更がある場合は慎重に対応。トリガーキーワード: 「Skillを更新して」「参照元を最新化して」

要件定義書と設計書から、実装タスク一覧をGitHub Issueに自動生成できます。 階層化されたタスク構造（Phase→タスクグループ→タスク→サブタスク）を自動作成できます。 各タスクに要件番号、実装AC、依存関係、完了条件などのメタデータを自動付与できます。 エラーフィードバックを受けて、修正版タスク一覧を再生成できます。 プロダクトマネージャーで、要件から開発タスクを体系的に生成したい人 開発チームリードで、タスク管理の精度を高めたい人 TDD（テスト駆動開発）を実践している開発チーム このスキルは、requirements.mdとdesign.mdに基づいてGitHub Issueにタスク一覧を生成します。責務は①タスク一覧の生成と②エラーフィードバック時の修正版生成のみで、検証・修正は行いません。入力は仕様書ディレクトリパスとIssue番号（更新時）、オプションでエラーレポートです。出力はMarkdown形式のIssue本文で、AS-IS/TO-BE/対応方針とタスク一覧を含みます。フォーマットはPhase（### Phase 1）→タスクグループ（- [ ] 1.1）→タスク（1.1.1）→サブタスクの階層です。各タスクに必須メタデータ（要件、実装AC、依存関係、完了条件、対応設計、シナリオテスト）と任意メタデータ（実行サブエージェント、使用Skill、UIデザイン）を付与します。サブエージェントはグループ・タスク共に1つのみ指定可能です。ロジック・コード実装タスクは原則TDDデフォルト適用です。

merge・rebase・cherry-pick・stashなど複数のGit操作中に発生するコンフリクトを、1ファイルずつユーザー確認を取りながら安全に解消します。 両側（HEAD側・マージ元側）の変更内容を視覚的に提示し、複数の解消案（HEAD優先・マージ元優先・統合案など）を提案します。 解消内容の確認と編集まで対話的にサポートし、誤った解消による予期しない動作を防ぎます。 10件以上のコンフリクトがある場合は事前に通知し、中断オプションも提供することで安全性を確保します。 rebaseやmerge時のコンフリクト解消に時間がかかっている開発者 複数ブランチの変更を統合する際に、どちらの変更を優先すべきか判断に迷う人 コンフリクト解消を急いで誤った統合をしてしまった経験がある人 大規模チームで複数人による並行開発により、頻繁にコンフリクトが発生する環境にいるエンジニア

複数の観点から自動判定: セキュリティ、ロジック、設計、整合性など7つの観点から、変更内容に応じた必要なレビューを自動選択して実施します。 複数のレビュアーが同時に検査: 選ばれた観点ごとにAIレビュアーが並列で動作し、見落としを防いで高速に完了します。 設計パターンから実装詳細まで網羅: Skill設計の妥当性、コードロジック、入力値の安全性、既存コードとの互換性、テストカバレッジなど、包括的な品質チェックを自動実行します。 外部API連携時のセキュリティ確認: 認証・API呼び出し・データベース操作を含む変更では、OWASP（セキュリティ脅威リスト）に基づいた検査を自動的に追加します。 設定変更やドキュメント更新漏れを検出: 公開API変更時にREADMEやドキュメントの更新が必要な場合も自動判定し、修正案を提示します。 開発チームのリードやレビュアー: コード変更の品質ばらつきを減らし、人手による細かい確認の負担を軽減したい方 セキュリティを重視する体制: 入力値検証やエラーハンドリングなどセキュリティ面を漏らさずチェックしたい組織 複数機能の同時開発: 大きな変更を多観点で素早く検査し、後からの手戻りを減らしたい場合 品質基準を統一したいチーム: 観点別の検査基準を統一しながら、誰が見ても同じレベルのレビューが受けられる環境を作りたい方

要件の漏れ・重複を自動検出: ユーザーの元要求と計画書を照らし合わせ、対応しない要件や暗黙的な前提条件を指摘します。 タスク設計の妥当性を判定: タスクの大きさが適切か、並列実行できるかなど、実装フェーズでの進め方が現実的かを複数の視点から検査します。 技術的リスク・影響範囲を可視化: 既存コードへの副作用やエッジケース（特殊な条件）の考慮漏れなど、実装中に発見しやすい問題を早期に摘出します。 過剰/不足な変更スコープを警告: オーバーエンジニアリング（必要以上に複雑な設計）や必要な対応漏れを指摘し、スコープを最適化します。 複数の専門家による同時検査: プロジェクトマネージャー視点と技術専門家視点の両方で検証し、計画段階での齟齬を防ぎます。 プロジェクトマネージャー・PO: 計画が現実的で実装可能かを確認し、チーム間のズレを早期に解決したい方 大規模機能開発: 複数フェーズに分かれた計画の整合性を保ち、リスクを事前に対策したい場合 アジャイル開発チーム: Planモードで立てた短期計画の品質を素早く確保し、スプリント開始までのリードタイムを短縮したい方 初めての大型開発: 計画段階でプロの視点から指摘をもらい、自チームの見落としを減らしたい場合

要件・設計・QA・UI画面の一貫性を確認: 仕様書の各パート（要件定義、設計書、画面定義、テスト仕様、タスク一覧）が互いに矛盾していないか自動チェックします。 受け入れ基準が実装・テスト可能か判定: 抽象的すぎる条件や検証できない要件を検出し、具体的で正確な仕様へ改善する指摘を提示します。 UI/UX画面と要件の整合を確認: ペン（Pencil）で作成した画面デザインが、要件書で定めた機能・導線と一致しているか自動検査します。 実装可能性・既存アーキテクチャ整合を検証: 既存の技術スタック・設計パターンと矛盾する仕様を早期に検出し、実装段階の混乱を防ぎます。 複数フェーズの検査に対応: 要件定義フェーズ、設計フェーズ、タスク分割フェーズそれぞれに最適化されたレビューを自動実行します。 QAリード・テスト担当者: 仕様書の曖昧さや検証不可能な条件を実装前に見つけ、テスト計画を効率的に立てたい方 要件定義・仕様設計者: 複数のドキュメント間のズレを自動検出し、ユーザーレビュー前に品質を高めたい場合 デザイナー・フロントエンド開発: 画面設計が要件と整合しているか確認し、実装段階での仕様変更を最小限にしたい方 大型プロジェクト・複雑な仕様: 多数の成果物をまとめて検査し、全体の一貫性を保ちながら品質を確保したい組織