Skill.md検索

Epic進捗をリアルタイムに確認 - 完了Story数・Task完了率・実績時間などを一目で把握でき、プロジェクトの進行状況を素早く把握できます。 次に実装すべきStoryを自動提案 - 依存関係を自動判定して、今すぐ着手できるStoryを提案するため、チームの作業優先度が明確になります。 Issue番号で素早く検索 - Issue番号または識別子を指定してEpicを即座に呼び出せます。 Story別の詳細進捗を把握 - 各Storyのタスク完了状況、見積もり時間との進捗率、関連PRなどを確認でき、細かい進捗管理が可能です。 全Epicをダッシュボード表示 - 引数なしで実行すると、全EpicをUI選択で表示でき、複数プロジェクトを同時管理する際に便利です。 プロジェクトマネージャー・スクラムマスター - チーム全体の進捗管理と次の作業優先度の決定が効率化します。 開発チームリード - メンバーの次の着手タスクを迅速に提示でき、チーム全体の進捗管理が簡単になります。 個別開発者 - 現在のEpic進捗を把握し、次に実装すべきStoryを確認してから着手できます。 ステークホルダー・経営層 - Story完了率や実績時間を数字で確認でき、プロジェクト状況を正確に報告できます。 .epic/ディレクトリ内のEpic情報から、Story進捗率（完了Story数/全Story数）、Task進捗率（完了Task数/全Task数）、時間進捗率（実績時間/見積もり時間）を計算します。各Storyのtasklist.mdから完了チェックボックス、見積もり時間、実績時間を抽出。GitHubのIssue/PR状態をghコマンドで確認し、未完了Storyの依存関係をoverview.mdから解析して、依存するStoryがすべて完了しているStoryを推奨として提案します。進捗バーを含む見やすいレポートを生成し、各Story別に状態（✅完了/🚧進行中/⏱️未着手）、Task完了状況、時間進捗、PR番号などを表示します。

GitHub上にEpic Issue（大型機能開発の親タスク）を作成し、Issue番号を確定させられます。 ユーザーの質問に答える形で、背景・目的・スコープなどの開発計画を自動で整理し、Markdown形式で本文を生成します。 仕様駆動開発（SDD）プロセスのチェックリスト付きIssueを自動作成し、次のステップ（仕様PR作成）へのガイダンスを提供します。 作成したIssue番号を使って、後続のコマンド（/create-spec-prなど）をすぐに実行できるようにセットアップします。 GitHubを使って大型機能開発を管理するエンジニア・プロジェクトマネージャー 要件定義と実装計画を体系的に進めたい開発チーム 仕様駆動開発（SDD）プロセスで統一された管理をしたい組織 コマンドラインから素早くEpic Issueを作成・運用したい人 ユーザーが直接実行するコマンド専用スキルで、他のツール・エージェントからの呼び出しは禁止です。/create-epic-issue [タイトル]で実行し、AskUserQuestionツールを使って背景・目的・スコープ（Phase定義）を対話形式で収集します。収集した情報をMarkdown形式にまとめ、gh issue createコマンドで自動作成します。Issue本文には、仕様駆動開発の13ステップチェックリストを埋め込み、進捗管理を容易にします。作成後、Issue番号とURLを表示し、次のステップ（仕様PR作成）をガイドします。エラーハンドリング（GitHub CLI未認証、作成失敗時の対応）も含みます。

Epic（大型機能開発）の全ステップを体系的に実行できます。 Story（小分割タスク）の抽出・管理・実装割り当てを自動化できます。 Clean Architecture・テスト戦略などのベストプラクティスに基づいた実装をガイドします。 テスト（ユニットテスト・インテグレーションテスト・受け入れテスト）の作成・実行を管理できます。 Git ブランチ・コミット・Pull Request作成までの一連のワークフローを進行できます。 Epic完了状況をリアルタイム追跡できます。 複数のStoryにまたがるEpic実装の全体進捗を管理したい開発チームリード ベストプラクティスに準拠した品質の高い実装を確実に進めたい開発者 実装→テスト→レビューの一連フローを効率化したい人 既存のEpicの完了状況を確認し、実装漏れを検出したい人 このスキルはユーザーが直接実行するスキル（エージェント呼び出し禁止）です。Git操作・GitHub PR作成などの副作用を伴うため、disable-model-invocation: trueに設定されています。 実行方法 `bash /implement-epic 88 # Epic #88を実装 /implement-epic issue-88 # 同上（別フォーマット） /implement-epic # Epic選択画面を表示 ` Epic選択フロー .epic/ディレクトリをスキャンして全Epic一覧を取得 各Epic のoverview.mdから Issue番号・タイトル・Story完了数を抽出 AskUserQuestionで複数選択肢を表示（完了済みEpicは✅マーク） ユーザー選択に基づいて実装開始 実行前の必須確認 1. ティア確認：gh issue viewでラベルを確認 - tier:major → 通常フロー - tier:minor/micro → 自律実装フロー 2. ベストプラクティス読み込み - backend/docs/BEST_PRACTICES.md（Clean Architecture・テスト戦略・アンチパターン） - frontend/docs/BEST_PRACTICES.md（コンポーネント設計・Hook パターン） 3. 仕様読み込み - specs/acceptance/*.feature（受け入れ条件） - specs/openapi/openapi.yaml（API仕様） 禁止事項：他のスキル・エージェントからの呼び出しは厳禁（リポジトリ状態破壊のリスク）

Issue（仕様承認済み）を指定するだけで、実装に必要なドキュメント（overview.md・tasklist.md など）を .epic/ ディレクトリに自動生成できます。 OpenAPI 仕様と受け入れ条件から、バックエンド・フロントエンドの実装タスクを自動分割し、詳細な実装計画を作成できます。 レイヤー別テスト戦略（Domain・UseCase・Controller など）に基づき、各タスクに適切なテスト種別とカバレッジ目標を反映できます。 作成した計画を AI が自動レビューし、タスク漏れや見積もり誤りがないか品質をチェックできます。 ティアラベル（Major/Minor/Micro）に応じて、Story 数やタスク粒度を最適化できます。 バックエンド・フロントエンド開発者で、仕様から実装タスクへの落とし込みを効率化したい人 スプリント計画で「どのタスク」「どのくらいの工数」で実装するかを見積もる必要がある人 テスト設計（単体テスト・統合テスト・E2E テスト）をしっかり計画に組み込みたい人 Issue 作成後、すぐに開発を開始したいけど計画書を手作業で書くのは避けたい人 このスキルは ユーザー専用 で、エージェント（Task ツール）からの呼び出しを禁止します。実行前に BEST_PRACTICES.md（バックエンド・フロントエンド）から §2・§4 テスト戦略とカバレッジ目標を読み込み、レイヤー別テスト対応表を把握することが必須です。実行フロー：(1) Issue から spec-approved ラベル・ティアラベル・状態を確認、(2) gh CLI で仕様 PR とファイルパスを抽出、(3) OpenAPI 定義と受け入れ条件を読み込み、(4) バックエンド実装（Controller・UseCase・Entity・テスト）と フロントエンド実装（API クライアント・Hooks・コンポーネント・テスト）に Story を分割、(5) BEST_PRACTICES の対応表に基づき各 Story にテストタスクを追加（Domain 90%+、UseCase 85%+、Mapper・Controller 80%+ など）、(6) 見積もり・工数・依存関係を記載した tasklist.md を生成、(7) 計画の漏れ・誤りを AI が自動レビュー。仕様 PR には実装コードを含まず、未実装エンドポイントを前提とします。

仕様から実装計画に変換: OpenAPI仕様と受け入れ条件をもとに、バックエンド・フロントエンド別の詳細な実装タスクを自動生成できます。 レイヤー別テスト戦略を組み込む: BEST_PRACTICES（テスト対応表、カバレッジ目標）を読み込み、Domain/UseCase/Controllerなど各レイヤーの必要なテストを漏れなく計画に反映できます。 Story分割と依存関係の明確化: 実装を段階的なStoryに分割し、どのTaskがどの順序で実行すべきかを可視化できます。 .epic/ディレクトリの自動生成: overview.md、tasklist.md、acceptance_criteria.md などの計画ドキュメントを自動作成できます。 計画の妥当性を自動レビュー: 仕様との整合性、テストの過不足、依存関係の誤りなどを自動的にチェックできます。 仕様から実装を始める開発者 テスト漏れや計画の抜け落ちを防ぎたい人 チームで実装計画を共有して漏れなく進めたい人 SDD（仕様駆動開発）のワークフローを使っている組織 plan-epic は Issue #番号を指定して実行する human-only スキル（エージェント呼び出し禁止）です。複数フェーズの長時間作業とユーザー対話を前提とするため、直接実行のみ許可。前提条件：Issue に spec-approved ラベル＋ティアラベル（major/minor/micro）があり、仕様PR がマージ済み。重要な前提として、仕様PRには実装コードを含まず、仕様PR で追加されたAPIエンドポイントは未実装という SDD の原則を遵守。実行フロー：(0) BEST_PRACTICES の読み込み（テスト戦略とカバレッジ目標を把握）→ (1) Issue 情報チェック＋ティア確認 → (2) 仕様情報収集（Issue本文から PR番号・ファイルパス抽出）以降のステップへ。

実装完了後の学びや改善点を記録して、同じ課題の再発を防止 何がうまくいったか、何が課題だったかを構造的に分析し、次回以降の参考資料として蓄積 繰り返し発生する手作業やパターンを自動化スクリプト・新スキルとして提案 セッション中に気づいた定型作業を自動化し、チーム全体の生産性向上に貢献 Epic・Story・セッション単位で振り返りを体系的に整理 ディレクトリ構造によって過去の振り返りを検索しやすくし、知見の再利用を促進 次のアクション（残課題・改善施策）をタスク化して、継続的改善の輪を回す 単なる記録に終わらず、実際の改善にまでつなげるアクションプランを立案 プロジェクトやスプリント完了時に形式的な振り返りで終わっているチーム 具体的な改善提案と自動化提案まで含めた深い振り返りができるようになる エンジニア個人の成長を可視化したい人 学んだ技術、失敗から得た知見を記録することで、スキルアップの実感が得られる チーム内の知見共有の仕組みを作りたいマネージャー 個別の振り返りを蓄積することで、暗黙知をチーム資産に変換できる

Storybook開発サーバーを起動して、UIコンポーネントを独立した環境で開発・検証 ブラウザ上でコンポーネントの見た目や挙動をリアルタイムで確認でき、デバッグサイクルが高速化 複数の状態（ローディング・エラー・成功）をストーリーで管理して、全パターンの動作を検証 Mock Service Worker（MSW）でAPI応答をシミュレートし、バックエンド完成待たずにフロントエンド開発を進行 コンポーネントと同じディレクトリにストーリーファイルを配置して、コンポーネント変更時の更新漏れを防止 コンポーネントとストーリーの関連性が明確になり、保守性が向上 Storybook の自動ドキュメント機能で、UIコンポーネント仕様書を自動生成 Props の説明や使用例が自動でドキュメント化され、チーム内の認識ズレを削減 UIコンポーネントの開発効率を上げたいフロントエンドエンジニア ブラウザでのリアルタイムプレビューにより、修正・確認のサイクルを短縮化 バックエンド開発と並行してUI実装を進めたい開発チーム MSW によるモック化で、API完成を待たずにコンポーネント開発が可能 デザインシステムやコンポーネントライブラリを管理している組織 Storybook を中心にコンポーネント仕様を一元管理でき、デザインとコードの統一性を確保

git worktree により複数のブランチを別々のフォルダで並行開発でき、ブランチ間の切り替えが瞬時に行える Docker Compose環境の自動セットアップにより、各worktreeに異なるポート番号（PORT_OFFSET）を割り当てて、複数の開発環境を同時起動できる COMPOSE_PROJECT_NAME による自動名前空間分離で、コンテナ・データベース・ネットワークがworktree ごとに独立し、データ競合やポート衝突を防ぐ セットアップスクリプトが .env 設定やデータベース初期化を自動化するため、手作業が最小限で済む フィーチャーブランチとメインブランチの両方で同時に開発したい開発者 バグ修正と新機能開発を並行して進める必要があるプロジェクト 複数の PR レビューや検証を同時進行したいチーム

フロントエンド・バックエンドのテストカバレッジレポートを自動生成し、目標値（90%）に対する現状を把握できる カバレッジが 90% 未満のファイルを自動抽出して一覧表示し、テスト改善が必要な箇所を一目で特定できる フロントエンド（pnpm）とバックエンド（Maven）それぞれの計測ツール（Vitest、JaCoCo）に対応した統一的なレポート生成ができる カバレッジ比較スクリプトにより、修正前後でのカバレッジ向上を可視化できる テスト品質を数値で管理し、段階的に改善していきたい開発者やQAエンジニア CI/CDパイプラインにカバレッジ計測を組み込みたい開発チーム コードレビュー時に「テストが十分か」を客観的に判定したいレビュアー