.md
Skill.mdサーチャーJP
Skill.md一覧に戻る
Y
v1.0.0

計画・アイデアに対して容赦なく質問を繰り返す

by yut0takagi

0
181
2026-04-08

説明

できること

  • ユーザーの計画・設計・アイデアについて、曖昧な部分を容赦なく1問ずつ質問し、共通理解に達するまで深掘りできます。Why(目的)、Who(ステークホルダー)、What(スコープ)、How(技術的手段)、When(期限)、Risk(リスク)、Edge cases(想定外のケース)の7つの観点から、決定木の各分岐を解決していきます。
  • 自分の推奨回答を提示したうえで質問するため(「私なら○○にしますが、いかがですか?」)、ユーザーが判断しやすく、ベストプラクティスに基づいた意思決定ができます。
  • コードベースや既存ドキュメントで答えがわかる質問は先に自分で調べてから聞くため、無駄な質問がなく、本当に必要な判断ポイントに集中できます。
  • 曖昧な回答には「具体的には?」と追撃し、「なんとなく」では流さないため、計画の穴や矛盾を事前に洗い出し、実装時のリスクを減らせます。
  • 最大20問までの上限があり、疲労を検知して途中で打ち切れるため、適切なタイミングで議論を終わらせてサマリーにまとめられます。

こんな人におすすめ

  • プロダクトマネージャー・企画:新機能やプロジェクトの計画を詳しく詰めたい
  • アーキテクト・技術リーダー:システム設計の穴や矛盾を事前に見つけたい
  • スタートアップ創業者:事業計画やプロダクト戦略をAIに壁打ちしたい
  • 開発チーム:要件定義やスコープの曖昧さを早期に解消したい
SKILL.md の内容
ユーザーの計画・設計・アイデアについて、**容赦なく質問を繰り返し**、共通理解に達するまで深掘りしてください。

## ルール

1. **質問は必ず1つずつ**聞く。まとめて複数投げない
2. 各質問には**自分の推奨回答を添える**(「私なら○○にしますが、いかがですか?」の形式)
3. コードベースや既存ドキュメントを見れば答えがわかる質問は、**先に自分で調べてから**聞く
4. 決定木の各分岐を1つずつ解決していく — 依存関係がある決定は、先に前提を確定させてから次へ進む
5. 曖昧な回答には「具体的には?」と追撃する。「なんとなく」で流さない
6. ユーザーが「もういい」「十分」「OK」と言うまで止めない

Skill.md 情報

バージョン
v1.0.0
カテゴリ
architecture
作成日
2026-03-31

インストール

ワンコマンドで導入
1

下の「Skill.mdをダウンロード」ボタンを押す

2

お使いのAIツール(Claude Code・Cursor・Copilot など)にファイルをアップロードして「このスキルを追加して」と入力する

ターミナルから追加する場合
$ mkdir -p ~/.claude/skills/ && curl -sL "https://github.com/yut0takagi/vault-template" -o ~/.claude/skills/SKILL.md

関連 Skill.md

Y

AWS仕様の陳腐化をAIが検出・更新

by YoshiiRyo1

非機能要件ヒアリングシート(8ファイル)に記載されたAWSサービスの仕様が最新版と一致しているか自動チェックできます。 SLA・クォータなどの数値、サービス機能、ベストプラクティスが現在の公式情報と乖離していないかを検証できます。 旧サービス名のままで記載されている、サービス提供が終了している、新機能が言及されていないなどの課題を特定できます。 チェック範囲を全体・特定ファイル・カテゴリごとに指定でき、効率的に更新対象を絞り込めます。 AWS最新情報との照合結果をレポートにまとめ、ドキュメント更新の優先度判断ができます。 AWSソリューションアーキテクトやクラウド設計者 定期的にAWSドキュメント・ベストプラクティスを最新に保ちたい企業 長期運用しているAWSプロジェクトの非機能要件定義を刷新したい PM・要件定義者 信頼性・セキュリティ・コスト最適化など特定カテゴリの陳腐化を重点的にチェックしたいアーキテクト 非機能要件ヒアリングシート(reliability・security・cost-optimization等8ファイル)に記載されたAWSサービス情報を最新の公式仕様と照合します。検索範囲は $ARGUMENTS で指定可能(引数なし=全体、ファイル名指定、カテゴリ指定)。 ワークフローは4段階です。Step 1: nfr-taxonomy.mdとチェック対象ファイルを読み込み、Step 2: 各ファイルからAWSサービス名・SLA数値・機能記述・ベストプラクティスを抽出、Step 3: aws-knowledge MCPサーバーで照合(SLA正確性、サービス機能最新性、リブランド有無、新サービス欠落、非推奨サービス記載の5観点)、Step 4: 照合結果を日本語レポートで出力。AWS最新情報との不一致が確認できた場合のみ指摘し、確認できない情報は記載しません。

テストドキュメントセキュリティ
3504.2k2026-02-23
G

プロダクト要求定義書(PRD)を構造的に作成

by GenerativeAgents

プロダクトアイデアから、実装に耐える詳細なPRD(プロダクト要求定義書)を対話的に作成できます。 ターゲットユーザー、課題、機能要件、非機能要件、成功指標をテンプレートに沿って体系的に整理します。 曖昧な要件を具体的・測定可能な形に落とし込み、「これは実装可能か」をAIが検証します。 機能を優先度(P0必須/P1重要/P2検討)で分類し、MVP範囲を明確にします。 既存PRDがある場合は構造を維持しながら更新、新規作成時はテンプレートガイドを参照できます。 起業家・プロダクトマネージャーで、アイデアを実装可能な形に落とし込みたい方 デザイナーや開発チームのリーダーで、要件の曖昧さを事前に潰したい方 投資家向けプレゼン資料としても使える、説得力のあるドキュメントを作成したい方 プロダクト開発の初期段階で、「作る前に仕様を決め切る」プロセスを回したい方 PRD作成の前提条件として、docs/ideas/initial-requirements.md に初期要求(アイデア、課題、ターゲット、主要機能、MVP範囲)を保存する必要があります。既存の docs/product-requirements.md がある場合は最優先し、このスキルのテンプレートは参考資料として使用します。作成プロセスは①initial-requirements.md 確認、②テンプレートに従ってドラフト生成、③5つの観点(ビジョン明確性、ユーザー具体性、成功指標測定可能性、機能詳細化レベル、非機能要件網羅性)でレビュー、④指摘を改善・再レビュー、です。重要な方針として「具体性と測定可能性」「ユーザー中心設計」「優先順位の明確化(P0/P1/P2)」を掲げ、ユーザーストーリーフォーマットと優先度分類が含まれます。

レビューテストドキュメント
821.1k2026-02-28
G

プロジェクト固有の機能設計書をすぐに作成できる

by GenerativeAgents

PRDの要件を技術実装の詳細設計に落とし込み、機能設計書を素早く作成できます。 既存の設計書がある場合は自動的にそれを参考にし、構造を保ちながら更新・補足できます。 テンプレートとガイドが用意されているため、何から書き始めるか迷わずに執筆を開始できます。 設計書を docs/functional-design.md に一元管理し、チーム全体で設計内容を共有できます。 プロダクト企画者が決めた要件を、開発者向けに技術的な実装方法として落とし込みたい人 チームメンバーに「この機能はどう実装する予定?」を分かりやすく説明したい人 新しいプロジェクトやフェーズの開始時に、設計ドキュメントの骨組みをすぐに整えたい人 既存の設計書を保ちつつ、内容を段階的に充実させたい人 機能設計書作成の前提として、docs/product-requirements.md のPRDが存在する必要があります。設計書の優先順位として、既存の docs/functional-design.md がある場合はそれを最優先とし、このスキルのガイドは参考資料として使用します。新規作成時はテンプレート(./template.md)と詳細ガイド(./guide.md)を参照してください。作成した機能設計書は docs/functional-design.md に保存され、既存設計書がある場合は構造と内容を維持しながら更新します。

ドキュメント設計PR
821.1k2026-02-28