k2f-business-proposal

K2F ビジネス提案書 — AI ネイティブな美的デザイン

目的

レイアウトに入る前にビジネス提案書を設計する方法をエージェントに教えます。信頼を得て、納品物の範囲を定め、価格を明確に示す自己完結型のストーリーを作成します。その際、ユーザーから提供されていない予算、料金、事例、条件を作り出しません。

K2F を基盤として

このスキルでは、ビジネス提案書を .K2F パッケージとして作成します。オーサリングには k2f スキルに従ってください。ワークスペースを展開または初期化し、セマンティックツリーを編集して、pack/verify を実行した後にエクスポートします。K2F を使うことで、エージェントはピクセル座標ではなく、意味（セクションの役割、ナラティブの流れ、表）に集中できます。その一方で、エンジンがレイアウト、タイポグラフィ、テーマをコンパイルし、一貫性のあるエクスポート可能な出力を作成します。

作成を始める前に、コアスキルをインストールしてください：npx skills add suzheng/k2f --skill k2f。

使用する場面

• RFP の抜粋、ヒアリングメモ、またはソリューション概要から、プロジェクトやサービスの提案書を作成する場合。
• ありきたりな AI 提案書を再構成し、エグゼクティブサマリー、スコープ、価格設定に一貫したストーリーを持たせる場合。
• 有効期限、含まれるもの／含まれないもの、次のステップを明示する必要がある正式な提案を準備する場合。

ワークフロー

ステップ 1. content_and_design.md を生成する

セマンティックなコンテンツと美的意図を定める単一の設計図です。k2f スキルが後でセクションに対応付けられるよう、ラベル付きのブロックを使用してください。

サブステップ

1. 提案書の枠組み — 対象者（購入者か評価者か）、契約形態（一括、段階式、リテイナー）、求める決定を定めます。有効期限を設定します（ユーザーが指定しない場合のデフォルトは30日）。枠組みに不要なセクションは省略します。

2. 表紙とメタデータ — タイトル、任意のサブタイトル、クライアント組織と連絡先、自社と連絡先、日付、バージョンを記載します。全体を通して通貨を統一し、わかる場合はロケールに応じた表記を明示します。

3. ナラティブの軸（CLOSE） — セクションの執筆前に流れを計画します：

   • 状況：ユーザーが提供した情報をもとに、相手の状況を相手の言葉で記述します。
   • 損失：何もしない場合のコストを示します。データがある場合に限り数値化し、それ以外は定性的な情報であることを明記します。
   • 成果：目指す将来像とビジネス価値を示します（可能な限り測定可能な形にします）。
   • ソリューション：アプローチ、フェーズ、納品物、成功基準を示します。
   • 根拠：提供能力の証拠として、ケースの概要、方法論、ユーザーが提供した資格情報を示します。 エグゼクティブサマリーはそれだけで内容が完結するようにします（最大約400語）。そのブロックだけで提案書全体を理解できるようにします。

4. セクション構成（含める／省く） — デフォルトの構成です。枠組みに応じて削除または短縮します：

   • エグゼクティブサマリー → 理解／現状と課題 → 提案アプローチ（概要＋段階的な提供）→ 期待される成果とROI → チームとガバナンス（該当する場合）→ 投資 → 当社を選ぶ理由 → 条件 → 次のステップ。
   • 機能の羅列、方法論の重複、競合他社への攻撃、詳細な法律上の定型条項は省きます。

5. スコープと納品 — フェーズごとに、目的、主な活動、納品物、成功基準、期間を示します。含まれるものと含まれないものを明示的なリストにし、初日からの認識違いを防ぎます。前提条件とクライアント側の依存事項は、本文に埋もれさせず独立したブロックにまとめます。

6. 投資のブロック — 価格モデルはユーザーが指定した場合に限り記載します。料金はまず表で示し、支払いのマイルストーンはユーザーの表現をそのまま使用します。料金や税金を捏造してはいけません。計算が不完全な場合は NEEDS USER CONFIRMATION を使用します。モデル → 合計 → 正味額 → 支払いスケジュールの順に、ひと目で確認できるようにします。

7. 商取引上の締めくくり — 開始前提、期間、場所、出張・経費の方針にはユーザーから提供された情報を使用します。知的財産、機密保持、解約、変更手続きは概要レベルで記載し、法務レビューを推奨する旨を明記します。日付または実行条件を付けた次のステップを番号付きで示します。

8. デザインの意図 — エンジンのトーン、階層、情報密度、配色：

   • トーン：相談型のB2B。誇張ではなく、理解を通じて信頼を築きます。クライアントの課題を先に示し、価格を見つけやすくします。
   • 階層：エグゼクティブサマリーと理解を最も強調します。各フェーズのタイトルは結論を先に示し、合計金額を埋もれさせません。
   • 情報密度：フェーズごとに箇条書きと表を使用し、段落は約6行までに抑えます。成果／ROIのブロックは繰り返さず、1つにまとめます。
   • 配色：控えめなニュートラルカラーを基調とし、フェーズ、合計金額、CTAにアクセントカラーを1色使います。WCAG AAに準拠し、料金はインラインの金額ではなく表で示します。

ルールと制約

• ディスカバリーの誠実さ：入力情報が少ない場合は、主張を限定して仮定を明記します。クライアントの状況を決して捏造しません。
• ストーリーのゲート：CLOSEの流れは、空の見出しを並べたチェックリストではなく、物語として読めるようにします。
• 自己完結性のゲート：過去のチャット履歴がない読者にも、課題、提案内容、価格の範囲、次に取るべき行動が伝わるようにします。
• 追跡可能性のゲート：すべての数値、期間、実績はユーザーからの入力に基づくものとし、そうでない場合は明示的にTBDとします。
• 分離のゲート：クライアントの状況、ソリューション、商取引条件は、それぞれラベル付きのセクションに分けます。RFPの文章を成果物の説明に混在させないでください。

よくある失敗

• クライアントの課題と結び付けずに機能を羅列する → 各機能を、明示された課題に結び付く成果として書き直します。
• 価格を埋もれさせたり、スコープを曖昧にしたりする → 投資概要を目立たせ、含まれる内容と含まれない内容を分けます。
• エグゼクティブサマリーが宣伝文句になる → クライアント固有の事実を用いて、CLOSE形式の段落に置き換えます。
• フェーズに活動内容はあるが、成果物や成功基準がない → フェーズごとに両方を追加するか、フェーズを統合します。
• 導入事例、チーム名、支払条件を捏造する → 削除し、プレースホルダーを使用します。
• 有効期限や次のステップがない → メタデータと締めくくりの両方に追加します。

品質チェックリスト

• エグゼクティブサマリーだけで内容が伝わり、本文と整合している（矛盾がない）。
• 少なくとも1つのセクションで、ユーザー提供の情報に基づき、クライアントの状況を深く理解していることを示している。
• すべてのフェーズに成果物と成功基準があり、含まれる内容／含まれない内容がフェーズと整合している。
• 投資額の表に矛盾がなく、未検証の価格にはその旨が明記されている。
• 有効期限、バージョン、日付に一貫性がある。
• デザインの意図で強調対象が明示され、指標や法的義務を捏造していない。

ステップ2：content_and_design.mdとk2fスキルを使い、K2Fファイルを生成して適切なファイル形式でエクスポートします。

k2fに従ってブループリントから提案書を作成し、デザインの意図に基づいてセクションの役割を適用し、検証したうえで、クライアントに提出できる成果物としてエクスポートします。