Back to Details

k2f-contract

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

K2F Contract — AI-Native Aesthetic Design

K2F 合同——AI 原生美学设计

Purpose

目的

Teach agents to blueprint contracts before layout: agreement frame, party roles, consistent clause stack, and formal hierarchy for navigation and signing—without fabricating parties, amounts, governing law, or positions the user did not supply.
指导 Agent 在排版前为合同进行蓝图规划：确定协议框架、当事方角色、一致的条款结构，以及便于浏览和签署的正式层级——不得虚构用户未提供的当事方、金额、管辖法律或立场。

Built on K2F

基于 K2F 构建

This skill produces contracts as 
.K2F
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 (articles, defined terms, exhibits, signature blocks)—not pixel coordinates—while the engine compiles layout, typography, and theme into consistent export-ready output.
Before you build, install the core skill: 
npx skills add suzheng/k2f --skill k2f
.
此 skill 生成 
.K2F
格式的软件包。编写时遵循 k2f skill：解包或初始化工作区，编辑语义树，运行 pack/verify，然后导出。K2F 让 Agent 专注于含义（条款、定义术语、附件、签名区块），而不是像素坐标；引擎则将版式、排版和主题编译为一致、可直接导出的输出。
构建前，请安装核心 skill：
npx skills add suzheng/k2f --skill k2f
。

When to Use

使用场景

  • Authoring a new NDA, MSA, SOW, SaaS order form, vendor agreement, or amendment from deal notes or a playbook.
  • Reformatting messy draft text into a signable structure with exhibits and defined terms.
  • Turning approved commercial terms into a polished agreement for counterparty circulation (counsel review still required).
  • 根据交易备注或 playbook 起草新的 NDA、MSA、SOW、SaaS 订购单、供应商协议或修订协议。
  • 将杂乱的草稿文本重新格式化为可签署结构，并补充附件和定义术语。
  • 将已批准的商业条款转换为适合向交易对手发送的精美协议（仍需法律顾问审查）。

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 articles and pages later.
Sub-steps
  1. Agreement frame — Type (NDA, MSA, SOW, license, SaaS, procurement, etc.), effective date logic, and which party you draft for (supplier, customer, licensor, licensee). State governing jurisdiction and currency only if user provided. Omit entire article families the type does not need (e.g., skip payment schedules on a mutual NDA).
  2. Parties & recitals — Legal names, entity types, addresses, and defined short names. Recitals: background facts from user inputs only—no invented deal size or strategic narrative. Flag missing signatory authority or entity details as 
    NEEDS USER CONFIRMATION
    .
  3. Defined terms block — Centralize capitalized terms used across articles (Services, Deliverables, Confidential Information, Fees). One definition per term; no duplicate glossaries in body text.
  4. Clause architecture (include / cut / order) — Plan articles before drafting prose. Default stack; trim per frame:
    • Scope / Services → Fees & payment → Term & termination → IP → Confidentiality → Data protection (or DPA exhibit pointer) → Warranties → Limitation of liability → Indemnification → Insurance → General (assignment, notices, force majeure, entire agreement, amendments, counterparts).
    • Cut duplicate obligations and marketing language.
    • Cross-link: liability cap vs indemnity; survival vs termination—no contradictions.
  5. Commercial & risk allocation (user-sourced) — Payment, caps, indemnity, IP, termination, and data terms verbatim or TBD. Label playbook clauses must-have, negotiable, or placeholder—do not soften must-haves.
  6. Exhibits & schedules — Move long tables (SOW milestones, SLA, DPA, pricing) to exhibits with stable labels (Exhibit A, Schedule 1). Body references exhibits by label; avoid orphan exhibits or terms defined only in attachments.
  7. Execution block — Signature lines, name/title/date per party; witness/notary only if user requested. Match party order to the preamble.
  8. Design intent — Formal document tone and hierarchy for the engine:
    • Tone: precise, neutral, institution-grade; no sales voice inside operative articles.
    • Hierarchy: agreement title and party block strongest on cover/first pages; article numbers (1, 1.1, 1.1(a)) as primary scan anchors; defined-terms section visually distinct; exhibits and signatures clearly terminal.
    • Density: moderate legal density—short paragraphs, numbered lists for obligations; avoid wall-of-text articles; tables for fees and deliverables only in exhibits.
    • Palette: restrained neutrals, minimal accent (signature/date fields); high contrast for body text; WCAG AA; no decorative graphics that compete with clause numbers.
Rules & constraints
  • Counsel gate: state clearly the blueprint is not legal advice; binding language requires qualified counsel review.
  • Side gate: obligations and protections must favor the documented drafting party; if side is unknown, stop and ask—wrong-side drafting inverts risk.
  • Silence gate: flag absent material topics (liability cap, change orders, data processing) instead of inventing market-standard terms.
  • Consistency gate: defined terms, exhibit references, and party names match everywhere; one currency and one governing-law block unless user confirms split structures.
  • Honesty gate: never fabricate registration numbers, insurance limits, fee amounts, or statutory citations.
Common failure modes
  • Pasting deal email as unstructured paragraphs → re-architect into numbered articles and exhibits.
  • Definitions scattered through body → consolidate Defined Terms; fix capitalization drift.
  • Liability and indemnity that read unlimited while a “cap” exists elsewhere → reconcile in blueprint notes before layout.
  • SOW scope in prose without deliverables, acceptance, or change process → add exhibit table or mark gaps.
  • Generic “Agreement” with no parties or effective date → fill from user or flag.
  • Over-designed marketing cover on a contract → shift flair to title block only; keep articles austere.
Quality checklist
  • Contract type, drafting side, and omitted articles are explicit.
  • Parties and defined terms are complete and consistent with exhibits.
  • Each material topic is present, deliberately omitted, or marked TBD—not silently assumed.
  • Cross-clause interactions (cap, indemnity, survival, termination) noted without contradiction.
  • Exhibits referenced in body exist; signature block matches party count.
  • Design intent names emphasis for article numbering, defined terms, exhibits, and signatures.
  • Counsel-review reminder included; no fabricated legal or commercial facts.
为语义内容和美学意图提供统一蓝图。使用带标签的内容块，以便 k2f skill 后续将其映射到条款和页面。
子步骤
  1. 协议框架——类型（NDA、MSA、SOW、许可协议、SaaS、采购协议等）、生效日期逻辑，以及代表哪一方起草（供应商、客户、许可方、被许可方）。仅在用户提供时填写管辖法和币种。省略该类型不需要的整类条款（例如：互惠 NDA 不应包含付款时间表）。
  2. 当事方与鉴于条款——法定名称、实体类型、地址和约定的简称。鉴于条款：背景事实只能来自用户输入——不得虚构交易规模或战略叙述。将缺少签字授权或实体信息的情况标记为 
    NEEDS USER CONFIRMATION
    。
  3. 定义术语区块——集中定义全文使用的首字母大写术语（Services、Deliverables、Confidential Information、Fees）。每个术语仅定义一次；正文不得重复设置术语表。
  4. 条款架构（保留 / 删除 / 排序）——起草正文前先规划条款。默认结构如下，并根据协议框架进行删减：
    • 范围 / 服务 → 费用与付款 → 期限与终止 → IP → 保密 → 数据保护（或指向 DPA 附件）→ 保证 → 责任限制 → 赔偿 → 保险 → 通用条款（转让、通知、不可抗力、完整协议、修订、副本）。
    • 删除重复义务和营销性语言。
    • 交叉关联：责任上限与赔偿；终止后存续条款与终止条款——不得存在矛盾。
  5. 商业与风险分配（源自用户提供的信息）——付款、责任上限、赔偿、IP、终止和数据条款应逐字照录，或标记为 TBD。将 playbook 条款标注为 must-have、negotiable 或 placeholder——不得弱化 must-have 条款。
  6. 附件与附表——将长表格（SOW 里程碑、SLA、DPA、定价）移至附件，并使用稳定标签（Exhibit A、Schedule 1）。正文通过标签引用附件；避免孤立附件，或仅在附件中定义却在正文使用的术语。
  7. 签署区块——为每一方提供签名栏、姓名/职务/日期；仅在用户要求时添加见证人或公证。当事方顺序须与前言一致。
  8. 设计意图——为引擎设定正式文档的语气和层级：
    • 语气：精准、中立、机构级；生效条款中不得使用销售式口吻。
    • 层级：协议标题和当事方区块在封面/首页最为突出；条款编号（1、1.1、1.1(a)）作为主要浏览锚点；定义术语部分在视觉上独立区分；附件和签名位于文末并清晰呈现。
    • 密度：适中的法律信息密度——采用短段落，并用编号列表呈现义务；避免条款成为大段文字；费用和交付成果表格仅置于附件中。
    • 配色：克制的中性色，极少量强调色（签名/日期字段）；正文高对比度；符合 WCAG AA；不使用与条款编号争夺注意力的装饰图形。
规则与约束
  • 法律顾问审查门槛：明确说明该蓝图不构成法律意见；具有约束力的语言必须由具备资质的法律顾问审查。
  • 起草立场门槛：义务和保护机制必须有利于已确定的起草方；若立场不明，停止并询问——立场错误会颠倒风险分配。
  • 缺项门槛：对于缺失的重要议题，应予以标记，而不是自行添加市场标准条款。
  • 一致性门槛：定义术语、附件引用和当事方名称须处处一致；除非用户确认采用拆分结构，否则全文只能使用一种币种和一个管辖法条款区块。
  • 真实性门槛：绝不虚构注册号、保险额度、费用金额或法律条文引用。
常见失败模式
  • 直接粘贴交易邮件且缺乏结构 → 重新构建为编号条款和附件。
  • 定义分散在正文 → 集中整理至 Defined Terms；修正术语大小写使用不一致的问题。
  • 责任与赔偿条款表面上看似无限，而其他位置存在“cap” → 排版前在蓝图备注中协调一致。
  • SOW 范围仅以散文描述，缺少交付成果、验收或变更流程 → 添加附件表格或标记缺口。
  • 通用“Agreement”缺少当事方或生效日期 → 根据用户信息补充或予以标记。
  • 合同封面过度采用营销化设计 → 将设计感仅保留在标题区块；条款部分保持克制。
质量检查清单
  • 明确说明合同类型、起草立场以及省略的条款。
  • 当事方和定义术语完整，并与附件保持一致。
  • 每个重要议题均已纳入、有意省略或标记为 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 the contract from the blueprint, apply article and exhibit roles from design intent, verify, and export the signable deliverable.
遵循 k2f，根据蓝图实例化合同，应用设计意图中的条款和附件角色，执行验证并导出可签署的交付文件。