Skill.md検索

現在の実装状況を自動整理: 完了済み、進行中、未着手のREQ（要件）をテーブル形式で把握できます。 ユーザーの不満や要望を体系的に収集: 困っていることと欲しい機能を分けて整理し、優先度の高さを見える化できます。 アイデアをブレインストーミング: 課題解決型、価値向上型、新規開拓型の3観点からアイデアを発想し、実装難易度や依存関係を評価できます。 次のアクションを明確にする: 優先度別にアイデアを整理し、すぐに着手すべき機能、次のスプリントでやるべき機能を提案できます。 既存機能への追加か新規REQかを判断: 各アイデアが既存のREQに組み込めるのか、新しいREQが必要なのかを整理できます。 プロダクトマネージャーやビジネス側のステークホルダー 新機能の優先順位を決める立場の人 ユーザーの声を開発計画に反映させたい人 「次に何をやるべきか」を体系的に整理したい開発チーム ideation はREQ作成前段階でのアイデア出しスキルです。実行フローは4ステップ：(1)現在の実装状況を把握（done/active/未着手のREQと仕様書カバレッジをテーブル形式で報告）、(2)ユーザーの声を収集（不満・課題、要望、優先度を質問）、(3)アイデアをブレインストーミング（課題解決型・価値向上型・新規開拓型の3観点で各アイデアに優先度・難易度・依存REQ・新規/追加判定を付与）、(4)整理と提案（優先度別テーブルで候補を整理し、すぐ着手・次スプリント・バックログに分類）。テンプレート出力により、次のアクション（req-decision-gate、design-reviewer への流れ）まで示します。

REQに基づきテスト駆動開発（TDD）でコードを実装し、確実な動作を保証します Cargoコマンドで自動的にテストを実行し、失敗時は即座に停止して報告します 実装完了時にコンパイルエラーや警告をチェックし、品質基準を満たすコードを納品します REQの受け入れ基準（AC）ごとに進捗状況を整理して報告し、未完了項目を明確にします 信頼性の高いRustコードを素早く実装したい開発者 テスト駆動開発を厳密に実行したい開発チーム 仕様書の内容を正確に実装に反映させたいプロジェクトマネージャー 実装は /design-reviewer が Go を返したREQのみを対象とします。/impl-plan の出力がある場合はそれに従い、ない場合は簡易版の計画（変更ファイル候補、追加テスト、実装順序）を出力します。Red→Green→Refactorのサイクルで進め、各ステップで cargo test と cargo build --release を実行して検証します。テストが失敗した場合やビルドエラーが発生した場合は実装を停止し、人間の判断を待ちます。Rust固有のチェック（cargo fmt --check、Clippy）も実行し、トークン効率重視で短い出力を心がけます。

要件ドキュメント（REQ）を受け取り、「本当に実装できるのか」を Go（OK）/ Hold（修正後OK）/ Reject（不可）の3段階で判定できます。 受け入れ基準（AC）が曖昧・検証不能・矛盾していないか、スコープは明確か、技術的に実現可能か、などを系統的にチェックできます。 問題点を「AC」「SCOPE」「DEPENDENCY」「UX」「TECH」「CLARITY」などのタグで分類し、優先順位付きの修正指示を出力できます。 開発チームが実装を始める前に、曖昧さや矛盾を事前に潰し、手戻りや議論の迷走を防げます。 レビュー結果は構造化されたフォーマットで出力され、要件提案者がどう直すべきかが明確になります。 要件定義書を書いた後、実装可能性を第三者にチェックしてもらいたいPO・企画者 曖昧な要件を受け取って実装を始める前に、事前に問題を見つけたい開発責任者・テックリード 要件定義と実装の品質ギャップを減らし、手戻りを最小化したいプロジェクトマネージャー 受け入れ基準の妥当性を客観的に判断し、チーム内の議論を効率化したいスクラムマスター このスキルは、要件ドキュメント（REQ）が実装可能な状態かを判定するレビュアーです。役割は REQ を受け取り、Go（実装可能）/ Hold（修正後実装可能）/ Reject（実装不可）を判定し、問題点・影響範囲・修正指示を出力することです。やらないこと：要件ファイル直接修正、新仕様提案、実装方法提案。分類タグは AC（受け入れ基準）、SCOPE（スコープ）、DEPENDENCY（依存関係）、UX（UI/UX）、TECH（技術）、CLARITY（明確性）。評価チェックリスト（必須：目的明確、AC具体的・検証可能、スコープ明確、実装想定可能）。判定基準：Go は全必須項目満たし重大問題なし；Hold は軽微問題ありだが修正可能；Reject は AC根本的不明確、スコープ未定義、矛盾・実現不可能要件が含まれる。