k2f-quotation
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseK2F Quotation — AI-Native Aesthetic Design
K2F 报价单——AI 原生美学设计
Purpose
用途
Teach agents to blueprint commercial quotations before layout: a scannable offer story, reconciled pricing, explicit boundaries (what is in / out), and design intent that foregrounds value, total, and validity—without inventing rates, deliverables, or legal terms the user did not supply.
指导 Agent 在排版前规划商业报价单:构建易扫读的方案叙事,确保价格核对一致、明确边界(包含与不包含哪些内容),并通过设计意图突出价值、总价和有效期——绝不虚构用户未提供的费率、交付物或法律条款。
Built on K2F
基于 K2F
This skill produces quotations as packages. Follow the k2f skill for authoring: unpack or init a workspace, edit the semantic tree, run pack/verify, then export. K2F keeps agents on meaning (parties, scope roles, option tiers, totals)—not pixel coordinates—while the engine compiles layout, typography, and theme into consistent output across PDF and other formats.
.K2FBefore you build, install the core skill: .
npx skills add suzheng/k2f --skill k2f此 skill 会将报价单生成为 包。编写时遵循 k2f skill:解包或初始化工作区,编辑语义树,运行 pack/verify,然后导出。K2F 让 Agent 专注于语义(各方、范围角色、选项层级、总价),而不是像素坐标;同时由引擎将布局、排版和主题编译为一致的输出,覆盖 PDF 和其他格式。
.K2F构建前,安装核心 skill:。
npx skills add suzheng/k2f --skill k2fWhen to Use
使用场景
- Drafting a new quote from a brief, RFP excerpt, discovery notes, or a rate card.
- Rebuilding a generic AI quote so scope, math, and validity read as one coherent offer.
- Presenting good / better / best tiers or optional add-ons the user already defined.
- 根据简报、RFP 摘录、需求调研记录或费率表起草新报价单。
- 重建通用 AI 报价单,使范围、计算和有效期呈现为一套连贯的方案。
- 呈现用户已定义的基础版、增强版、最佳版层级,或可选附加项。
Workflow
工作流
Step 1. Generate the content_and_design.md
第 1 步:生成 content_and_design.md
Single blueprint for semantic content and aesthetic intent. Use labeled blocks the k2f skill can map to regions later.
Sub-steps
-
Quote type & decision frame — Fixed price, time-and-materials cap, milestone-based, or tiered packages. Note currency, locale formatting, tax treatment (inclusive/exclusive/unknown), and whether this is binding or indicative. Omit sections the type does not need (e.g., skip acceptance block on a rough ballpark).
-
Party & identity — Seller and client names, addresses, contacts, logo intent. Registration or tax IDs only if user provided. Never fabricate signatures or authorized signatory names.
-
Reference metadata — Quote number, issue date, valid-until date (or explicit validity rule). Project name, RFP/PO reference, version (v1, v2). One currency for the whole document; flag missing validity before layout.
-
Offer narrative (assertion, then evidence) — One short block states what the client gets and why this price (outcome-oriented, not marketing fluff). Follow with evidence: line table, tier summary, or milestone list—not long prose that repeats table rows. If the user pasted client requirements, keep verbatim ask in a distinct subsection and map your priced response beside it; do not merge RFP text into line descriptions.
-
Line-item architecture — Table-first. Per row: deliverable or SKU label, qty, unit, unit price, line total. Group sections (implementation, licensing, support) only when user data already splits that way. Optional add-ons and alternates as labeled blocks—not hidden footnotes. Discounts as explicit lines or documented percent rules.
-
Totals story (write the math) — Subtotal → taxes/fees with labeled rates → quote total → optional “from” pricing when tiers exist. State rounding (per line vs document). If inputs conflict, markinstead of guessing.
NEEDS USER CONFIRMATION -
Boundaries & terms — Inclusions, exclusions, assumptions, dependencies on client inputs. Payment or deposit milestones verbatim from user. Acceptance steps, change-order pointer, and warranty/support only if supplied. No invented liability caps or SLA numbers.
-
Design intent — Tone, hierarchy, density, palette for the engine:
- Tone: confident, precise B2B; persuasive through clarity, not hype.
- Hierarchy: quote title + number in header; scope headline and quote total strongest; line table secondary; validity and exclusions visible without hunting.
- Density: readable table rhythm; right-align money; tabular numerals; at most one short assumptions block on the main view.
- Palette: restrained neutrals, one accent on total and primary CTA (e.g., “Accept by …”); WCAG AA; tier columns visually parallel for comparison.
Rules & constraints
- Acceptance gate: no send-ready blueprint without quote number, dates, currency, reconciled total, and stated validity.
- Separation gate: narrative, priced facts, and legal/assumption notes stay in distinct labeled sections—readers must not confuse interpretation with committed scope.
- Traceability gate: every figure and deliverable ties to user input or a formula written in the doc; mark missing tax or FX explicitly.
- Honesty gate: no fabricated upsells, cross-sells, or “this also covers …” unless the user said so.
Common failure modes
- Paragraph pricing → rewrite as rows with qty, unit, and amount.
- Buried total or missing valid-until → promote in metadata and design intent.
- RFP prose pasted into line items → split verbatim ask vs priced response.
- Tier options unequal or incomparable columns → align units, term length, and subtotals per tier.
- Invented rates, VAT, or payment terms → strip; use .
TBD — user must supply - Marketing superlatives with no scoped deliverable → replace with measurable inclusion lines.
Quality checklist
- Parties and IDs match user-supplied data only.
- Line math reconciles to subtotal and total under stated rounding.
- Valid-until and version align with narrative (no stale dates).
- Inclusions/exclusions do not contradict line items.
- Design intent names emphasis for scope headline, total, validity, and table.
- Optional tiers are comparable; primary recommendation is obvious if user named one.
为语义内容和美学意图建立统一蓝图。使用带标签的区块,以便 k2f skill 后续将其映射到不同区域。
子步骤
-
报价类型与决策框架——固定价格、封顶工时与材料费、基于里程碑或分层套餐。注明货币、区域格式、税费处理方式(含税、不含税或未知),以及报价是否具有约束力或仅供参考。省略该类型不需要的章节,例如,粗略预算可跳过接受区块。
-
主体与身份信息——卖方和客户名称、地址、联系人、Logo 意图。仅在用户提供时填写注册信息或税号。绝不能虚构签名或授权签字人姓名。
-
参考元数据——报价单编号、签发日期、有效期截止日期(或明确的有效期规则)、项目名称、RFP/PO 引用和版本(v1、v2)。整份文档使用一种货币;排版前标出缺失的有效期信息。
-
方案叙述(先陈述观点,后提供证据)——用一个简短区块说明客户将获得什么,以及为何采用此价格(以结果为导向,不写营销套话)。随后提供证据:明细表、层级摘要或里程碑清单——不要用长篇文字重复表格行。如果用户粘贴了客户需求,请在独立的小节中保留逐字原始要求,并在其旁映射你的定价响应;不要将 RFP 文本合并进明细描述。
-
明细项目架构——以表格优先。每行包含:交付物或 SKU 标签、数量、单位、单价、行项目总额。仅当用户数据本身已按此方式拆分时,才使用分组章节(实施、许可、支持)。可选附加项和备选方案应使用带标签的区块——不要藏在脚注中。折扣应列为明确行项目,或记录百分比规则。
-
总价逻辑(写出计算过程)——小计 → 按明确费率列示税费/费用 → 报价总额 → 存在层级时,可选列出“起价”。说明舍入规则(按行舍入还是按整份文档舍入)。如果输入相互冲突,标记,不要猜测。
NEEDS USER CONFIRMATION -
边界与条款——包含项、排除项、假设,以及对客户输入的依赖。付款或订金里程碑必须逐字沿用用户提供的内容。仅在用户提供时加入验收步骤、变更单指引和保修/支持条款。不得虚构责任上限或 SLA 数字。
-
设计意图——供引擎使用的语气、层级、信息密度和配色:
- 语气:自信、精准的 B2B 风格;通过清晰度而非夸张措辞产生说服力。
- 层级:页眉中放置报价单标题和编号;范围主标题与报价总额最突出;明细表为次要层级;有效性和排除项无需费力查找即可看到。
- 密度:保持易读的表格节奏;金额右对齐;使用表格数字(tabular numerals);主视图最多包含一个简短假设区块。
- 配色:使用克制的中性色,仅在总价和主要 CTA(如“请于……前接受”)上使用一种强调色;符合 WCAG AA;层级列在视觉上平行,便于比较。
规则与约束
- 交付门槛:没有报价单编号、日期、货币、核对一致的总额和明确有效期,就不能形成可发送的蓝图。
- 分离门槛:叙述、定价事实和法律/假设说明必须保留在不同的带标签章节中——读者不得混淆解读内容与承诺范围。
- 可追溯性门槛:每个数字和交付物都必须关联到用户输入或文档中写明的公式;明确标记缺失的税费或 FX 信息。
- 诚实性门槛:除非用户明确提出,否则不得虚构追加销售、交叉销售或“本报价还包含……”等内容。
常见失败模式
- 段落式定价 → 改写为包含数量、单位和金额的行项目。
- 总价被埋没或缺少有效期截止日期 → 在元数据和设计意图中突出。
- 将 RFP 文本粘贴到明细项目中 → 拆分逐字原始要求与定价响应。
- 层级选项不相等或各列不可比较 → 对齐各层级的单位、期限和小计。
- 虚构费率、VAT 或付款条款 → 删除;使用 。
TBD — user must supply - 使用营销最高级用语却没有对应范围的交付物 → 替换为可衡量的包含项。
质量检查清单
- 各方和 ID 仅与用户提供的数据匹配。
- 在所述舍入规则下,明细计算与小计和总价一致。
- 有效期截止日期和版本与叙述一致(不存在过期日期)。
- 包含项和排除项不与明细项目冲突。
- 设计意图明确标出范围主标题、总价、有效性和表格的强调方式。
- 可选层级具有可比性;如果用户指定了主推方案,推荐项一目了然。
Step 2. Use the content_and_design.md and k2f skill to generate a K2F file and export to an appropriate file format.
第 2 步:使用 content_and_design.md 和 k2f skill 生成 K2F 文件并导出为合适的文件格式
Follow k2f to instantiate the quotation from the blueprint, apply roles from design intent, verify, and export the client-ready deliverable.
遵循 k2f,根据蓝图实例化报价单,套用设计意图中的各项角色,进行验证,并导出可直接交付客户的成果。