thinkyou0714 Purpose
「何が問題なのか」が曖昧なまま設計・実装へ進むリスクを防ぐ。 相談・課題を構造化して、次のアクションを選べる状態にする。
Use When
- 新機能・改善・施策の検討初動
- 「なんとなく困っている」状態の言語化
- 要件定義前の論点整理
- 設計前の前提確認
- 壁打ち・ブレインストーミングの初動整理
Inputs
以下を準備すること。不足している場合は推測せず、不足を明示する。
- 相談内容: 何に困っているか、何を決めたいか（自由記述可）
- 背景: なぜ今この問題が浮上したか
- 制約: 時間・予算・技術・組織上の制約（わかる範囲で）
- 関係者: 影響を受ける人・チーム・ユーザー
- 期待するアウトプット: この場で何が決まれば前に進めるか
Output Contract
以下の順で出力すること。順序を変えない。
- 論点: この問題の核心は何か（1〜3点に絞る）
- 根拠: その論点をそう判断した理由
- リスク: 放置した場合・誤った判断をした場合の影響
- 含意: この論点が示す構造的・中長期的な意味
- 改善案: 現実的な対応の選択肢（複数提示）
- 代替案: 正攻法以外の選択肢・別の切り口
- 判断材料: 次のアクションを選ぶために人間が確認すべき情報
Review Lens
- 目的妥当性: この問題を解くことが本当に目的に対して有効か
- 範囲の過不足: 問題を過大に取るか、過小に取っていないか
- 中長期リスク: 短期解決が長期に負債を生まないか
- LAB全体との整合性: LMS / 自動化基盤 / B2B展開との矛盾がないか
- 非エンジニア理解可能性: 非エンジニアの関係者に説明できるか
- 他LLM移植耐性: Claude 固有の解釈に依存していないか
Instructions
- 相談内容を読み、論点候補を3〜5点リストアップする
- 各論点を「目的」「成功条件」「失敗条件」「制約」の4軸で確認する
- 最も核心に近い論点を1〜3点に絞る（根拠を添える）
- リスクを「今すぐ」「3ヶ月後」「1年後」のタイムスパンで整理する
- 改善案は最低2案、代替案は最低1案を提示する
- 判断材料を「人間が今すぐ確認できるもの」として具体化する
- 不明な前提がある場合は、仮定を明示した上で進める（推測で埋めない）
Guardrails
- 推測で仕様を埋めない。前提が不明な場合は「前提: ○○と仮定」と明示する
- 解決策を1つに閉じない。必ず複数の選択肢を残す
- コスト比較（時間・技術的負債・機会コスト）を省略しない
- 「これが正解」と断定しない。判断は人間に委ねる
- 実装を勝手に提案・確定しない（この skill は論点整理まで）
- 問題の範囲を自分で勝手に狭めない
LAB Cross-Check
実行結果に対して以下を確認すること。
| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | 自動化の可否・影響を含んでいるか |
| データ / 認証 / ログ | — | データ構造・権限・監査への影響を確認したか |
| 実装 / 運用フロー | — | 実装可能性・運用負荷を考慮したか |
| 非エンジニア理解可能性 | — | 非エンジニアにも説明できる言葉で書けているか |
| 会員共有 / 再利用耐性 | — | 他のケースに転用できる形か |
| 他LLM移植耐性 | — | Claude 固有の前提に依存していないか |
状態は OK / 注意 / NG / 対象外 で記入すること。
Handoff Notes
施工AI（Claude Code / Cursor 等）へ渡す前に以下を確定させること。
- 要件: 何を実現するか（箇条書き）
- 成功条件: どうなれば完了か（測定可能な形で）
- 失敗条件: どうなったら失敗か
- 実行範囲: 触ってよいファイル・モジュール・DBテーブル
- 影響範囲: 変更が波及する可能性のあるシステム・機能
- ロールバック方針: 失敗した場合の戻し方
- コスト比較: 各選択肢の工数・技術的負債・機会コストの概算
Further Reading
- docs/CONTEXT.md — プロジェクト背景・現フェーズ
- docs/DECISIONS.md — 過去の設計決定（再議論しない）
assumption-auditskill — 前提を洗い出したい場合に続けて使うrisk-scanskill — リスクをより深掘りしたい場合に使うdecision-materialsskill — 判断材料を整理したい場合に使う