Back to Details

k2f-sales-deck

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

K2F Sales Deck — AI-Native Aesthetic Design

K2F 销售演示文稿——AI-native 美学设计

Purpose

目的

Teach agents to blueprint sales decks before layout: one meeting, one deal step—with the prospect as hero, pain in their words, proof tied to outcomes—without inventing ROI, logos, or results the user did not supply.
指导 Agent 在排版前规划销售演示文稿的结构：一次会议只推进一个交易步骤——让潜在客户成为主角，用他们自己的语言描述痛点，并将证据与成果关联——同时不得虚构用户未提供的 ROI、logo 或成果。

Built on K2F

基于 K2F 构建

This skill produces sales decks as 
.K2F
packages. Follow the k2f skill for authoring: unpack or init a workspace, edit the semantic tree, pack/verify, and export. K2F keeps agents on meaning (slide roles, narrative, visual intent)—not coordinates—while the engine compiles layout, typography, and theme into export-ready output.
Before you build, install the core skill: 
npx skills add suzheng/k2f --skill k2f
.
此 skill 将销售演示文稿生成为 
.K2F
包。编写时遵循 k2f skill：解包或初始化工作区，编辑语义树，打包/验证并导出。K2F 让 Agent 专注于含义（幻灯片角色、叙事、视觉意图），而非坐标；引擎则将布局、排版和主题编译为可直接导出的成品。
构建前，先安装核心 skill：
npx skills add suzheng/k2f --skill k2f
。

When to Use

适用场景

  • Building discovery, demo, proposal, or executive-briefing decks from call notes or CRM context.
  • Personalizing a template deck for a named account and buying stage.
  • Replacing feature-heavy slides with problem–solution–proof flow and a clear next-step ask.
  • 基于通话记录或 CRM 上下文构建需求探索、演示、方案或高管简报演示文稿。
  • 为指定客户账号和购买阶段个性化模板演示文稿。
  • 将功能堆砌的幻灯片替换为问题—方案—证据流程，并加入明确的下一步行动请求。

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 per slide (role, headline, body, visual type) that the k2f skill can map later.
Sub-steps
  1. Meeting frame — One type and one objective: discovery, demo, proposal, or executive briefing. Record audience mix, buying stage, objections, and desired next step—never multiple meeting goals in one deck.
  2. Input audit — Inventory verified inputs: prospect name/context, pains in their language, scope, pricing rules, approved case studies, product screenshots, competitive facts. Flag 
    NEEDS USER INPUT
    for missing proof; never fabricate metrics, customer names, or ROI.
  3. Narrative spine — Choose a spine matched to the meeting:
    • Problem–solution–proof (default): their world today → better future with your approach → why you (credibility).
    • SPIN-style demo: situation recap → articulated problem → cost of status quo → payoff tied to their use cases.
    • Executive briefing: why we’re here → what we learned → recommendation → investment/timeline → discussion. Prospect is the hero; your product is the guide—lead with “you” outcomes, not company history.
  4. Slide architecture (include / cut) — Map slides to the spine; typical counts: discovery 5–10, demo 5–15, proposal 10–20, executive 10–15.
    • Core path: title → agenda (3–5 items, end with next steps) → their challenge → approach/outcomes → proof → demo/product (if needed) → investment/ROI → mutual next steps.
    • Cut opening company history, generic “best in class” claims, full feature tours, duplicate problem/solution slides, and investor-only blocks (TAM, cap table).
    • Split when two beats share one slide (e.g., problem + recommendation, or price without value context).
  5. Per-slide content contract — For each slide specify:
    • Headline: the point of the slide in buyer terms (“Cut onboarding time 40% for teams like yours” not “Our platform”).
    • Body: max 3–5 bullets or one visual; parallel structure on comparisons; quote their words on problem slides when available.
    • Visual type: workflow diagram, product frame, logo + outcome strip, ROI comparison, timeline, mutual action plan—use chart/callout intent for quantified impact, not paragraph dumps.
    • Proof notes: label each stat Measured / User-provided / TBD; similar industry/use case for case studies; anonymize if required.
  6. Audience depth — Economic buyers: outcomes, ROI, risk, timeline first. Technical buyers: integration/fit slides or appendix pointers, not the whole deck. Mixed room: segment beats (“For leadership… / For your team…”) without doubling slide count.
  7. Design intent — For the engine:
    • Tone: consultative, credible, personalized—no stock hype; mirror prospect formality.
    • Hierarchy: headline states the takeaway; one hero metric or phrase per slide when proof exists; subordinate footnotes for sources.
    • Density: one idea per slide; visuals over text walls; agenda and next-steps slides stay scannable.
    • Palette: restrained base, one accent for metrics and the ask; screen-share contrast; consistent logo and comparison styling.
Rules & constraints
  • One-meeting gate: deck serves exactly one objective and one primary next step.
  • Personalization gate: prospect name, pains, and use cases appear before generic product overview.
  • Proof gate: logos, results, and ROI use user-approved facts or explicit TBD—not implied wins.
  • One-idea gate: if the headline needs “and,” split or cut.
  • Ask gate: closing slide names owners, dates, and a clear question—not a passive “any questions?”
Common failure modes
  • Vendor monologue → lead with their challenge; one credibility beat max for “about us.”
  • Generic or cold deck → personalize title, agenda, and “what we heard.”
  • Feature-tour demo → top 3 use cases; note live-demo vs screenshot.
  • Price before value or weak close → pair ROI with investment; mutual action plan with explicit ask.
  • Wrong audience depth → rebalance or flag appendix slides in the blueprint.
Quality checklist
  • Meeting type, single objective, and target next step stated at top of blueprint.
  • Prospect-specific challenge appears before solution/product slides.
  • Every slide has one headline claim and a declared visual type.
  • Proof slides cite source, approval, or TBD; no unlabeled metrics.
  • Agenda and final slide align (discussion + next steps with owners/dates).
  • Design intent names tone, hero emphasis, and accent usage for the full deck.
这是一个承载语义内容和美学意图的单一蓝图。每张幻灯片使用带标签的区块（角色、标题、正文、视觉类型），供 k2f skill 后续映射。
子步骤
  1. 会议框架——确定一种会议类型和一个目标：需求探索、演示、方案或高管简报。记录受众构成、购买阶段、异议和期望的下一步——一个演示文稿中绝不设置多个会议目标。
  2. 输入审核——盘点已验证的输入：潜在客户名称/背景、他们原话描述的痛点、范围、定价规则、已批准的案例研究、产品截图、竞争事实。对于缺失的证据，标记 
    NEEDS USER INPUT
    ；绝不捏造指标、客户名称或 ROI。
  3. 叙事主线——选择与会议类型匹配的主线：
    • 问题—方案—证据（默认）：他们今天所处的世界 → 使用你的方案后的更好未来 → 为什么是你（可信度）。
    • SPIN 式演示：情境回顾 → 明确问题 → 维持现状的代价 → 与其使用场景关联的收益。
    • 高管简报：我们为何来到这里 → 我们了解到了什么 → 建议 → 投入/时间线 → 讨论。 潜在客户是主角；你的产品是向导——先讲“你”的成果，而不是公司历史。
  4. 幻灯片架构（保留/删减）——根据主线映射幻灯片；典型页数：需求探索 5–10 页，演示 5–15 页，方案 10–20 页，高管简报 10–15 页。
    • 核心路径：标题 → 议程（3–5 项，以下一步结束）→ 他们的挑战 → 方法/成果 → 证据 → 演示/产品（如需要）→ 投入/ROI → 双方下一步。
    • 删减开场的公司历史、泛泛的“行业领先”声明、完整功能巡览、重复的问题/方案幻灯片，以及仅面向投资人的板块（TAM、cap table）。
    • 当两个内容节点共用一张幻灯片时进行拆分（例如问题 + 建议，或价格缺少价值背景）。
  5. 单页内容契约——为每张幻灯片指定：
    • 标题：用买家语言表达该页的核心观点（“像你们这样的团队可将入驻时间缩短 40%”，而不是“我们的平台”）。
    • 正文：最多 3–5 个要点或一个视觉元素；比较内容采用平行结构；问题页在有原始表述时引用他们的话。
    • 视觉类型：流程图、产品界面框、logo + 成果条、ROI 对比、时间线、联合行动计划——使用 chart/callout intent 表达量化影响，而不是堆砌段落。
    • 证据说明：将每个统计数据标记为 Measured / User-provided / TBD；案例研究应选用相似行业/用例；必要时进行匿名化处理。
  6. 受众深度——经济决策者：先讲成果、ROI、风险和时间线。技术决策者：提供集成/适配幻灯片或附录指引，而不是整套演示文稿。混合受众：按受众切分内容节点（“对于管理层…… / 对于你的团队……”），但不要让幻灯片数量翻倍。
  7. 设计意图——供引擎使用：
    • 基调：顾问式、可信、个性化——不要使用套话式炒作；匹配潜在客户的正式程度。
    • 层级：标题陈述核心结论；有证据时，每页只突出一个核心指标或关键短语；来源置于次级脚注。
    • 信息密度：每页只讲一个观点；视觉元素优先，避免文字墙；议程和下一步幻灯片应便于快速浏览。
    • 配色：使用克制的基色，指标和行动请求只用一种强调色；具备适合屏幕共享的对比度；logo 和比较项样式保持一致。
规则与约束
  • 单会议门禁：演示文稿只服务于一个目标和一个主要下一步。
  • 个性化门禁：在泛泛的产品概览之前，必须呈现潜在客户名称、痛点和用例。
  • 证据门禁：logo、成果和 ROI 只能使用用户批准的事实或明确标注的 TBD——不能暗示未经证实的成果。
  • 单观点门禁：如果标题需要使用“和”，就拆分或删减。
  • 行动请求门禁：结尾幻灯片要明确负责人、日期和具体问题，而不是以被动的“有什么问题吗？”收尾。
常见失败模式
  • 供应商单方面宣讲 → 先讲他们的挑战；“关于我们”最多保留一个建立可信度的部分。
  • 通用或冷淡的演示文稿 → 个性化标题、议程和“我们听到的信息”。
  • 功能导览式演示 → 只展示前 3 个使用场景；注明是实时演示还是截图。
  • 先讲价格后讲价值，或结尾乏力 → 将 ROI 与投入配对；用联合行动计划给出明确请求。
  • 受众深度处理不当 → 重新平衡内容，或在蓝图中标记附录页。
质量检查清单
  • 蓝图顶部写明会议类型、单一目标和目标下一步。
  • 潜在客户特有的挑战出现在方案/产品幻灯片之前。
  • 每张幻灯片都有一个核心观点标题和明确标注的视觉类型。
  • 证据页注明来源、批准状态或 TBD；不得出现无标签指标。
  • 议程与最终幻灯片保持一致（讨论 + 包含负责人/日期的下一步）。
  • 设计意图明确整套演示文稿的基调、核心强调项和强调色用法。

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 slides from the blueprint, apply roles from design intent, verify, and export the meeting-ready deliverable.
遵循 k2f，根据蓝图实例化幻灯片，应用设计意图中的角色，验证并导出可用于会议的交付物。