Pitch explainer
実装完了後、プロトタイプ・仕様・実装ノートを1つの共有ドキュメントにまとめて、ステークホルダーの承認・買い込み（buy-in）を得るためのピッチ資料を作るスキル。ユーザーが「Slackに貼れる資料にまとめて」「ピッチドキュメントを作って」「レビュー用の説明資料が欲しい」「関係者向けにまとめて」「buy-in用のdocを」と言ったとき、または実装成果を第三者に説明する資料が必要なときに使用する。From its SKILL.md
npx -y skills add kaito-siba/fable-field-guide --skill pitch-explainerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.7 KB, as published. Nobody here has run it
pitch-explainer: 承認を得るための共有ドキュメント
作業の成果物（プロトタイプ・仕様・実装ノート）を、第三者が短時間で判断できる1つのドキュメントにまとめる。目的は承認と買い込み: 「unknownsと失敗ポイントをちゃんと考慮した」と示すことが説得力の核になる。 （出典: "A Field Guide to Claude Fable: Finding Your Unknowns"）
Step 1: 材料の収集と読者の確認
会話・リポジトリから以下を集める（なければ省略、あるものを活かす）:
- プロトタイプ・デモ（スクリーンショット、GIF、動くHTML）
- 仕様・実装計画
- implementation-notes.md（逸脱の記録）
- 実際の変更内容（diff の要約）
読者と場所が不明なら確認する: Slack投稿 / PR説明 / 経営層向け資料では、長さとトーンが変わる。
Step 2: ドキュメント構成
順序が重要。デモを先頭に:
# <一言で価値が伝わるタイトル>
## デモ（先頭に置く）
（GIF・スクリーンショット・動くリンク。読者が3秒で「何ができたか」を掴めるもの）
## 何を作ったか・なぜ
（2-4行。課題 → 解決。経緯の時系列は書かない）
## 検討した選択肢と採らなかった理由
（承認者が聞きたいのは「他の道を考えたか」）
## 想定した失敗ポイントと対処
（エッジケース、リスク、implementation-notesのDeviationsから抽出）
## 未解決のこと・次のステップ
（正直に。隠すと信頼を失う）
Step 3: 仕上げ
- 長さは読者に合わせる。Slack向けなら1画面に収まる分量、詳細は折りたたみやリンクに逃がす
- デモ素材（スクリーンショット等）が無くて作れる場合は作る（プロトタイプHTMLを開いてスクリーンショットを撮る等）
- 完成したらSendUserFileで提示する。外部への投稿（Slack送信等）はユーザーの確認を得てから行う