菜单
ユーザーの発言内容だけを忠実にドキュメント化するスキル。PRD・仕様書・企画書・ 提案書など構造化ドキュメントの作成時に使う。AIが「言ってないことを勝手に補足する」 問題を防ぐためのもの。以下のような場面で必ず発動すること: "PRDを書いて", "企画書を作って", "仕様書をまとめて", "ドキュメントにして", "草案を書いて", "叩き台を作って", "提案書を書いて", "聞いた内容をまとめて", "話した内容を文書化して", "言ったことだけ書いて", "勝手に足さないで" またユーザーの口頭説明や会話からドキュメントを起こす場面でも積極的に使うこと。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
「点と点を線にする」快感を軸にゲームデザインを設計・レビューするスキル。 人間の脳は「無関係に見えたAとBに関係性を見出した瞬間」に強い快感を得る。 伏線回収・知識アンロック・シナジー発見・隠れた関係性は全てこの派生。 「線（=AとBを結ぶ説明）はプレイヤー自身に引いてもらう設計」が核心で、 デザイナーは点を配置し、余白（=線にあたる部分）をあえて残す。 以下のような場面で使う: - 新しいゲームメカニクスを設計するとき - ストーリー・世界観・伏線を設計するとき - チュートリアル・知識提示・情報UIを設計するとき - ゲームの「面白さが弱い」「淡々としている」「アハ体験がない」と感じたとき - 既存のゲーム（cookie, factory, rpg, abyss, godfield, metropolis など）の面白さを強化する提案をするとき - 「点と線で考えて」「伏線として」「アンロックの設計」「アハ体験」といったキーワード
ゲームデザインを分析し、面白さを改善するための提案を行う。対象ゲームを指定するか、全ゲームを対象にできる。
方針合意後の実装を自律的に進め、テストを丁寧に書き、セルフレビューを徹底するスキル。 実装タスク全般で使うこと。機能追加、バグ修正、リファクタリング、テスト追加など、 コードを書く作業が発生したら必ずこのワークフローを通す。 「実装して」「作って」「追加して」「直して」「書いて」といった依頼はもちろん、 ユーザーが方針を決めて「進めて」「お任せ」「どんどんやって」と言った場合にも使う。 確認を挟まず自律的に完成まで持っていくためのワークフロー。
| name | faithful-doc-writing |
| description | ユーザーの発言内容だけを忠実にドキュメント化するスキル。PRD・仕様書・企画書・ 提案書など構造化ドキュメントの作成時に使う。AIが「言ってないことを勝手に補足する」 問題を防ぐためのもの。以下のような場面で必ず発動すること: "PRDを書いて", "企画書を作って", "仕様書をまとめて", "ドキュメントにして", "草案を書いて", "叩き台を作って", "提案書を書いて", "聞いた内容をまとめて", "話した内容を文書化して", "言ったことだけ書いて", "勝手に足さないで" またユーザーの口頭説明や会話からドキュメントを起こす場面でも積極的に使うこと。 |
AIは文書作成時に「ユーザーが言ったこと」と「AIが補足・推測したこと」の境界を 曖昧にしがちで、ユーザーが後から「違う、それはそういうことじゃない」と修正する 手間が発生する。このスキルは、ユーザー発言の忠実な記録を最優先とし、AIの推測を 排除することで、この問題を根本的に防ぐ。
[TBD] と明記する[TBD] には何が不足しているかを簡潔に添える
[TBD: 対象ユーザー数の目標値][TBD: リリース希望時期][TBD] の項目について質問リストを提示するユーザーの発言を以下の3カテゴリに分類する:
| カテゴリ | 説明 | ドキュメントへの反映 |
|---|---|---|
| 明言された事実 | ユーザーが明確に述べた情報 | そのまま記載 |
| 示唆された方向性 | ユーザーが匂わせたが断定していない情報 | 記載 + [要確認] マーク |
| 言及されていない項目 | テンプレートにあるがユーザーが触れていない | [TBD: 説明] |
自分の分類に自信がない場合、「明言された事実」ではなく「示唆された方向性」に 分類する。過大評価より過小評価のほうが安全。
[TBD]ドキュメント末尾に以下を追加:
---
## TBD 項目（未定・要確認）
| # | セクション | 不足している情報 | 優先度 |
| --- | ---------- | ---------------------- | ------ |
| 1 | 計測 | 主要メトリクスの目標値 | 高 |
| 2 | リスク | 想定されるリスクと対策 | 中 |
| ... | ... | ... | ... |
## 質問リスト
以下について教えていただけると、ドキュメントをより充実させられます:
1. [具体的な質問]
2. [具体的な質問]
ユーザーが質問に回答したら:
[TBD] を解消する[TBD] があれば追加する以下は絶対にやらないこと:
| やりがちなこと | なぜダメか |
|---|---|
| ユーザーの発言を「より良く」言い換える | 意図が変わるリスクがある |
| 「一般的にはこうなので」と情報を追加する | ユーザーの文脈では正しくない可能性 |
| テンプレートの空欄をそれっぽく埋める | 後から「これ違う」となり修正コスト発生 |
| ユーザーの言葉を専門用語に置き換える | ニュアンスが失われる |
| 結論や提案を勝手に書く | ユーザーの意思決定を先取りしている |
| 「〜と考えられます」で推測を紛れ込ませる | 推測を事実のように見せている |
ドキュメントを書き終えたら、以下を確認する:
[TBD] にする