Back to Details

k2f-company-deck

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

K2F Company Deck — AI-Native Aesthetic Design

K2F 公司演示文稿 — AI 原生美学设计

Purpose

用途

Teach agents to blueprint company decks before layout: a stakeholder-ready story that explains who the company is, what it delivers, and why it matters—without inventing funding, customers, metrics, or leadership the user did not supply.
指导 Agent 在排版前规划公司演示文稿：构建可直接面向相关方的叙事，解释公司是谁、提供什么以及为何重要——绝不虚构用户未提供的融资信息、客户、指标或管理层。

Built on K2F

基于 K2F

This skill produces company 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

适用场景

  • Introducing the company to partners, enterprise buyers, recruits, press, or board guests (no investment ask).
  • Consolidating website copy and bios into one coherent overview.
  • Refreshing a generic “about us” deck for skimmable positioning and contact in under ten minutes.
  • 向合作伙伴、企业买家、招聘对象、媒体或董事会来宾介绍公司（不提出投资请求）。
  • 将网站文案和简介整合为一份连贯的企业概览。
  • 刷新通用的“关于我们”演示文稿，使其便于快速浏览、定位清晰，并能在十分钟内以联系信息收尾。

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. Deck frame — Primary audience (partner, customer, talent, media), setting (first meeting, conference, onboarding), and time budget. Choose emphasis: credibility + capabilities for B2B; mission + culture for talent; news + proof for press. Drop fundraising slides unless the user explicitly wants a hybrid.
  2. Input audit — Inventory verified inputs: positioning, products, public pricing, permitted logos, milestones, team, partnerships, news. Flag 
    NEEDS USER INPUT
    for gaps—never fabricate headcount, revenue, clients, or awards.
  3. Narrative spine — Plan flow before titles: identity → problem space → offer → how it works → proof → difference → people & scale → direction (vision, not roadmap dump) → engage. Opening = name + tagline; closing = one CTA.
  4. Slide architecture (include / cut) — Default overview stack (~12–16 slides); merge or omit when inputs are thin:
    • Title → Company snapshot → Mission / values (optional) → Problem & opportunity (light) → Solutions / product lines → How we work or platform → Customers & outcomes → Differentiation → Team → Milestones / footprint → Partners or ecosystem (optional) → Vision → Contact.
    • Cut investor-only blocks (TAM essay, use-of-funds, cap table), duplicate product slides, long feature lists, and internal org charts unless audience is recruits.
    • Split when identity and product story share one slide, or when two products each need a hero proof point.
  5. Per-slide content contract — For each slide specify:
    • Headline: outcome or position, not a section label (“Payments infrastructure for internet businesses” not “About us”).
    • Body: max 3–5 bullets or one visual; ~2 lines per bullet; parallel grammar on lists.
    • Visual type: logo strip, product frame, workflow diagram, metric callouts, timeline, team grid, map—prefer visual intent over paragraphs for comparisons, milestones, and portfolios.
    • Footnotes: source + year for external claims; logo approval notes if needed.
  6. Proof layering — Permitted logos or named references first; anonymize if required. Scale metrics only when user-supplied; else qualitative proof with TBD.
  7. Design intent — For the engine: tone institutional, from user brand voice—not generic hype; hierarchy one hero per slide, calm contact block; density one message per slide, grids for portfolios; palette user colors or neutral + one accent, WCAG AA, consistent logos/timelines.
Rules & constraints
  • Audience gate: every slide must earn its place for the chosen audience; recruit slides ≠ partner slides unless user wants one master deck.
  • Truth gate: metrics, customers, funding, and headcount match user materials or are marked TBD—no rounded-up fiction.
  • One-idea gate: if the headline needs “and,” split or cut.
  • Brand gate: tagline, product names, and legal entity spelling identical everywhere.
  • Logo gate: only logos the user confirmed; otherwise “category examples” or omit.
Common failure modes
  • Pitch deck as company deck → drop ask, financials, TAM; strengthen identity and contact.
  • Website walls of text → headline + proof only; detail in blueprint notes.
  • Feature lists without outcomes → tie capabilities to customer results.
  • Weak differentiation → two-column comparison or cut.
  • Long team bios → name, role, one line each.
  • Cluttered closing → one CTA plus minimal contact.
Quality checklist
  • Tagline and company snapshot appear in the first three slides; contact/CTA on the last slide.
  • Every slide has one headline claim and a declared visual type.
  • No slide exceeds density limits; external stats have sources or TBD flags.
  • Product and company names spelled consistently; repeated metrics match.
  • Audience-irrelevant sections removed or moved to optional appendix notes in the blueprint.
  • Design intent names tone, hero emphasis, and accent usage for the full deck.
为语义内容和美学意图生成一份统一蓝图。对每张幻灯片使用带标签的内容块（角色、标题、正文、视觉类型），供 k2f skill 后续映射。
子步骤
  1. 演示框架 — 确定主要受众（合作伙伴、客户、人才、媒体）、应用场景（首次会面、会议、 onboarding）以及时间预算。选择侧重点：B2B 场景侧重可信度 + 能力；人才场景侧重使命 + 文化；媒体场景侧重新闻 + 佐证。除非用户明确需要混合版本，否则删去融资相关幻灯片。
  2. 输入审计 — 盘点已验证的输入材料：定位、产品、公开定价、获准使用的 logo、里程碑、团队、合作关系、新闻。对于缺失项标记 
    NEEDS USER INPUT
    ——绝不虚构员工人数、营收、客户或奖项。
  3. 叙事主线 — 先规划流程，再拟定标题：身份 → 问题领域 → 产品/服务 → 运作方式 → 佐证 → 差异化 → 团队与规模 → 发展方向（愿景，而非堆砌路线图）→ 促成行动。开篇 = 名称 + 宣传语；结尾 = 一个 CTA。
  4. 幻灯片架构（包含 / 删减） — 默认概览结构（约 12–16 页）；当输入材料较少时，合并或省略：
    • 标题 → 公司概览 → 使命/价值观（可选）→ 问题与机会（简要）→ 解决方案/产品线 → 工作方式或平台 → 客户与成果 → 差异化 → 团队 → 里程碑/业务布局 → 合作伙伴或生态系统（可选）→ 愿景 → 联系信息。
    • 删减 仅供投资方使用的内容（TAM 长文、资金用途、股权结构表）、重复的产品页、冗长的功能列表和内部组织架构图；但如果受众是招聘对象，组织架构图可以保留。
    • 拆分 当公司定位与产品故事共用一页时，或当两种产品各自需要一个主视觉佐证点时。
  5. 每页内容约定 — 为每张幻灯片明确以下内容：
    • 标题：表达结果或定位，而不是栏目名称（例如使用“面向互联网企业的支付基础设施”，而不是“关于我们”）。
    • 正文：最多 3–5 个要点或一个视觉元素；每个要点约 2 行；列表采用并列结构。
    • 视觉类型：logo 组合条、产品界面框图、工作流图、指标标注、时间线、团队网格、地图——对于比较、里程碑和产品组合，优先表达视觉意图，而不是使用大段文字。
    • 脚注：外部主张标注来源和年份；必要时注明 logo 审批说明。
  6. 分层构建佐证 — 优先使用获准的 logo 或具名引用；如需则匿名处理。仅在用户提供数据时展示量化指标；否则使用定性佐证并标注 TBD。
  7. 设计意图 — 为引擎明确以下规范：语气 应具备机构级专业感，遵循用户的品牌表达，而不是泛泛的炒作话术；层级 每页一个主视觉，联系信息块保持克制；密度 每页一个信息，产品组合使用网格；配色 使用用户提供的颜色，或中性色 + 单一强调色，符合 WCAG AA，logo 与时间线保持一致。
规则与约束
  • 受众规则：每一页都必须对所选受众有存在价值；除非用户需要一份通用母版，否则招聘版页面 ≠ 合作伙伴版页面。
  • 真实性规则：指标、客户、融资信息和员工人数必须与用户材料一致，否则标记为 TBD——不得虚构或使用向上取整的数据。
  • 单一信息规则：如果标题需要用“和”连接，就拆分或删减。
  • 品牌规则：宣传语、产品名称和法人实体拼写在所有页面中保持一致。
  • Logo 规则：仅使用用户确认的 logo；否则使用“类别示例”或省略。
常见失败模式
  • 把融资路演稿误作公司概览 → 删除融资诉求、财务数据和 TAM；强化公司定位与联系信息。
  • 直接堆砌网站大段文字 → 仅保留标题和佐证；详细内容放入蓝图说明。
  • 功能列表没有成果 → 将能力与客户结果关联。
  • 差异化表达薄弱 → 使用双栏对比，或删减。
  • 团队简介过长 → 仅保留姓名、职位和一行说明。
  • 结尾信息杂乱 → 保留一个 CTA 和最精简的联系信息。
质量检查清单
  • 宣传语和公司概览出现在前三页；联系信息/CTA 位于最后一页。
  • 每页都有一个标题主张，并明确声明视觉类型。
  • 任何页面的信息密度都不得超过限制；外部统计数据必须有来源或 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 stakeholder-ready deliverable.
遵循 k2f skill，根据蓝图实例化幻灯片，应用设计意图中的角色，进行验证并导出可直接面向相关方的交付物。