메뉴
既存の設計ドキュメント・RFC・計画書を読み込み、AskUserQuestion による構造化された質問を 通じて、曖昧さ・矛盾・未定義事項を洗い出し、決定事項と残課題を整理するスキル。 「深掘りして」「曖昧な点を洗い出して」「設計の穴を突いて」「challenge my assumptions」 「ドキュメントを読んで質問して」のような依頼でトリガーすること。 仕様書（spec）の生成が目的の場合は design-to-spec を使うこと。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
ポーカーのハンドレビューと座学を統合的に行うスキル。 ユーザのハンドをGTO Wizardのソルバーデータとブログ記事を根拠に多角的にレビューし、 同時に集合分析ベースの体系的な座学を実施する。 数学的根拠（ポットオッズ、エクイティ、EV計算）とexploit観点を含む。 「ハンドレビューして」「このハンドどう思う？」「レビューお願い」「hand review」 「この判断正しかった？」「座学したい」「このスポットを勉強したい」 「集合分析を見たい」「深掘りして勉強」「このスポットの全体像を知りたい」
Create a git commit, push a branch, and open a Pull Request with gh. Use when asked to commit changes, push to origin, or create PRs, especially when conventional commits and PR templates are required.
設計ドキュメント（Design Doc）を実装可能な仕様書（Spec）に変換するスキル。 「なぜ作るか」を「何を作るか」に変換し、実装者・QA・保守者が参照できる明確な仕様を生成する。 「スペックにまとめて」「仕様書にして」「実装仕様を書いて」「specに変換して」でトリガーすること。 dig で曖昧さを解消してから使用すると最も効果的。
設計ドキュメント（Design Doc）を実装可能な仕様書（Spec）に変換するスキル。 「なぜ作るか」を「何を作るか」に変換し、実装者・QA・保守者が参照できる明確な仕様を生成する。 「スペックにまとめて」「仕様書にして」「実装仕様を書いて」「specに変換して」でトリガーすること。 dig で曖昧さを解消してから使用すると最も効果的。
既存の設計ドキュメント・RFC・計画書を読み込み、AskUserQuestion による構造化された質問を 通じて、曖昧さ・矛盾・未定義事項を洗い出し、決定事項と残課題を整理するスキル。 「深掘りして」「曖昧な点を洗い出して」「設計の穴を突いて」「challenge my assumptions」 「ドキュメントを読んで質問して」のような依頼でトリガーすること。 仕様書（spec）の生成が目的の場合は design-to-spec を使うこと。
Automates browser interactions for web testing, form filling, screenshots, and data extraction. Use when the user needs to navigate websites, interact with web pages, fill forms, take screenshots, test web applications, or extract information from web pages.
| name | dig |
| description | 既存の設計ドキュメント・RFC・計画書を読み込み、AskUserQuestion による構造化された質問を 通じて、曖昧さ・矛盾・未定義事項を洗い出し、決定事項と残課題を整理するスキル。 「深掘りして」「曖昧な点を洗い出して」「設計の穴を突いて」「challenge my assumptions」 「ドキュメントを読んで質問して」のような依頼でトリガーすること。 仕様書（spec）の生成が目的の場合は design-to-spec を使うこと。 |
| argument-hint | <doc-path> [output-path] |
| allowed-tools | Read, AskUserQuestion, Write, Edit, Glob, Grep |
既存の設計ドキュメントを読み込み、構造化された質問で曖昧さを洗い出し、 決定事項と残課題を整理する。Spec は生成しない。
docs/design.md）<doc-basename>-decisions.md以下の7カテゴリでドキュメントを分析し、質問項目を洗い出す。 各質問には2〜4個の具体的な選択肢を準備し、各選択肢に pros/cons を付記する。
分析カテゴリ:
すべてを網羅する必要はなく、ドキュメントの内容に応じて重要度の高いものから優先する。
AskUserQuestion を使って、1ターンにつき1〜3問ずつ質問する。
質問のルール:
description: "Pros: シンプルな実装。Cons: スケール時にボトルネックになる可能性"インタビューの進め方:
完了の判断基準:
完了と判断したら、その旨をユーザーに伝えて確認を取る。
全カテゴリの質問完了後、以下を実施する:
再分析は最大2回まで。 2回目の再分析で新たな問題がなければ Step 5 へ進む。
以下の構造で決定事項ドキュメントを生成する:
# Decisions: <ドキュメントタイトル>
## Decision Records
| # | カテゴリ | 質問 | 決定事項 | 根拠 |
|---|---------|------|---------|------|
| 1 | ... | ... | ... | ... |
## Open Questions
- [ ] <未解決の質問1>
- [ ] <未解決の質問2>
## Next Steps
- <次にやるべきこと>
出力ルール:
<doc-basename>-decisions.md（第2引数で上書き可能）design-to-spec の利用を提案する