k2f-quotation

K2F 見積書 — AI ネイティブな美的デザイン

目的

レイアウトに取りかかる前に、エージェントが商用見積書の設計図を作成できるようにします。ひと目で内容が伝わる提案の流れ、整合性の取れた価格、明確な範囲（含まれるもの／含まれないもの）、そして価値、合計額、有効期限を前面に出すデザイン意図を示しつつ、ユーザーが提示していない料金、納品物、法的条件を創作しないようにします。

K2F を基盤に構築

このスキルは見積書を .K2F パッケージとして生成します。作成時は k2f スキルに従ってください。ワークスペースを展開または初期化し、セマンティックツリーを編集して、パック／検証を実行してからエクスポートします。K2F により、エージェントはピクセル座標ではなく、意味（当事者、範囲の役割、オプションの段階、合計額）に集中でき、エンジンがレイアウト、タイポグラフィ、テーマをコンパイルして、PDF などの各形式で一貫した出力を生成します。

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

使用する場面

• 依頼概要、RFP の抜粋、ヒアリングメモ、料金表をもとに新しい見積書を作成する場合。
• 範囲、計算、有効性が一貫した提案として伝わるよう、汎用的な AI 見積書を作り直す場合。
• ユーザーがすでに定義した松竹梅の段階やオプションの追加項目を提示する場合。

ワークフロー

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

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

サブステップ

1. 見積書の種類と意思決定の枠組み — 固定価格、時間・材料費の上限付き、マイルストーンベース、または段階別パッケージ。通貨、ロケールに応じた表記、税の扱い（内税／外税／不明）、拘束力のある見積もりか参考価格かを記載します。その種類で不要なセクションは省略します（例：概算見積もりでは承諾欄を省略）。

2. 当事者と識別情報 — 販売者とクライアントの名前、住所、連絡先、ロゴの使用意図。登録番号や納税者番号はユーザーが提示した場合に限り記載します。署名や署名権限者の名前を決して捏造しないでください。

3. 参照メタデータ — 見積番号、発行日、有効期限（または明示的な有効期間のルール）。プロジェクト名、RFP／PO の参照情報、バージョン（v1、v2）。文書全体で通貨を統一し、レイアウト作成前に有効期限の不足を明示します。

4. 提案内容（主張、次に根拠） — クライアントが何を得られ、なぜこの価格なのかを短いブロックで示します（マーケティング的な飾り文句ではなく、成果を中心に記述）。続けて、明細表、段階別の概要、またはマイルストーン一覧で根拠を示します。表の行を繰り返す長文は避けてください。ユーザーがクライアントの要件を貼り付けた場合は、提示された要件の原文を独立したサブセクションに残し、その隣に価格を付けた回答内容を対応付けます。RFP の文面を明細の説明に統合しないでください。

5. 明細項目の構成 — 表を中心にします。各行には、納品物または SKU のラベル、数量、単位、単価、行合計を記載します。セクション（導入、ライセンス、サポートなど）は、ユーザーのデータがすでにそのように分かれている場合に限りグループ化します。オプションの追加項目や代替案は、脚注に隠さず、ラベル付きのブロックとして示します。割引は明示的な行、または根拠を示したパーセンテージのルールとして記載します。

6. 合計額の説明（計算を記載） — 小計 → 税／手数料と明記した税率 → 見積合計額 → 段階がある場合は任意の「〜から」の価格。丸め処理（行ごとか文書全体か）を記載します。入力に矛盾がある場合は推測せず、NEEDS USER CONFIRMATION と記載します。

7. 範囲と条件 — 含まれるもの、含まれないもの、前提条件、クライアントからの入力への依存事項。支払い条件または前金のマイルストーンはユーザーの記載どおりにします。承諾手順、変更注文に関する案内、保証／サポートについては、ユーザーが提示した場合に限り記載します。責任上限や SLA の数値を創作しないでください。

8. デザイン意図 — エンジンに向けてトーン、階層、密度、配色を指定します。

   • トーン：自信に満ち、正確な B2B 向け。誇張ではなく明快さで説得します。
   • 階層：ヘッダーに見積書のタイトルと番号を配置します。範囲の見出しと見積合計額を最も目立たせ、明細表はその次にします。有効期限と除外事項は、探し回らなくても見つかるようにします。
   • 密度：読みやすい表のリズムにします。金額は右揃え、数字は等幅にします。メインビューの前提条件ブロックは、短いものを最大 1 つにします。
   • 配色：抑制の効いたニュートラルカラーを基調とし、合計額と主要な CTA（例：「…までに承諾」）に 1 色のアクセントを使います。WCAG AA に準拠し、比較しやすいよう段階別の列を視覚的に並行させます。 ルールと制約

• 受け入れゲート：見積番号、日付、通貨、整合性の取れた合計金額、有効期限が記載されていない限り、送付可能なブループリントとして完成させてはいけません。
• 分離ゲート：説明、価格設定された事実、法的事項／前提事項の注記は、それぞれラベル付きの独立したセクションに記載します。解釈と確約された範囲を読者が混同しないようにしてください。
• トレーサビリティゲート：すべての数値と成果物は、ユーザー入力または文書内に記載した計算式に紐付けます。税や為替レートが不明な場合は、明示してください。
• 誠実性ゲート：ユーザーの指示がない限り、アップセル、クロスセル、「これも含まれます」といった内容を捏造してはいけません。

よくある失敗

• 段落で価格を記載する → 数量、単価、金額を含む行に書き換えます。
• 合計金額が目立たない、または有効期限がない → メタデータとデザイン意図で目立たせます。
• RFP の説明文を明細項目に貼り付ける → 依頼内容の原文と価格を提示した回答を分けます。
• プランの選択肢ごとに条件が異なる、または比較できない列がある → 各プランの単位、契約期間、小計を揃えます。
• 料金、VAT、支払い条件を捏造する → 削除し、TBD — user must supply を使用します。
• 範囲内の成果物が定義されていない、誇張表現を使う → 測定可能な内容を含む行に置き換えます。

品質チェックリスト

• 当事者と ID は、ユーザー提供のデータのみと一致しています。
• 明記された丸め処理に基づき、明細の計算結果が小計と合計に一致しています。
• 有効期限とバージョンは説明と一致しています（古い日付が残っていません）。
• 含まれる内容／含まれない内容が明細項目と矛盾していません。
• デザイン意図で、範囲の見出し、合計金額、有効期限、表の強調点を指定しています。
• オプションのプランを比較でき、ユーザーが推奨案を指定している場合は、それが明確になっています。

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

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