Back to Details

k2f-fillable-pdf

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

K2F Fillable Pdf — AI-Native Aesthetic Design

K2F 可填写 PDF — AI 原生美学设计

Purpose

用途

Teach agents to author 
content_and_design.md
for forms people actually complete: explicit static copy, a complete field inventory with types and constraints, logical section flow, and aesthetic intent tuned for scanning and typing—not a generic questionnaire dump or a static PDF with boxes pasted on.
教会 Agent 编写 
content_and_design.md
，用于创建真正有人会填写的表单：包含明确的静态文案、完整且带类型和约束条件的字段清单、合理的章节流程，以及针对扫读和输入优化的美学意图——而不是简单堆砌通用问卷，或在静态 PDF 上贴几个方框。

Built on K2F

基于 K2F 构建

This skill produces fillable documents 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 (labels, field roles, instructions, grouping)—not pixel coordinates—while the engine compiles layout, typography, and interactive fields into consistent 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

使用场景

  • New application, registration, intake, onboarding, or compliance forms from requirements or an existing paper PDF.
  • Restructuring a cluttered legacy form before rebuild.
  • Splitting one long form into scannable sections while preserving exact legal or policy wording supplied by the user.
  • 根据需求或现有纸质 PDF 新建申请、报名、信息收集、入职或合规表单。
  • 在重建前重新组织杂乱的旧版表单。
  • 将一份长表单拆分为易于扫读的章节，同时保留用户提供的法律或政策措辞原文。

Workflow

工作流

Step 1. Generate the content_and_design.md

第 1 步：生成 content_and_design.md

One blueprint merging what readers see (static) and what they enter (interactive), plus design intent the engine can interpret. Use labeled blocks; map pages later in k2f.
Sub-steps
  1. Completion scenario — Who fills it (applicant, staff, patient), alone or with attachments, estimated time, submission path, and required vs optional sections. Drop fields that do not change an outcome.
  2. Static layer — Title, version or effective date, issuer identity, short “how to complete” steps, privacy or retention notice only from user text, section introductions, and footers (page x of y, contact). Never invent legal clauses.
  3. Field inventory — Table or structured list: stable id, human label, control kind (single-line text, multiline, checkbox, radio group, dropdown, date, signature attestation), required flag, placeholder or format hint, options for choice fields, max length or line count, help text one line max. Group radios and checkbox sets under one question with mutually exclusive or multi-select semantics spelled out.
  4. Information architecture — Order for cognitive flow: identify → details → choices → authorization → review. Cluster 5–9 fields per section; start a new section when the topic shifts. Pair short labels with inputs in two-column rows; use full width for paragraphs, multiline answers, and declaration blocks. Specify conditional blocks (“show employer block only if Employment = Yes”) as explicit rules, not implied layout.
  5. Design intent — Tone (institutional, clinical calm, friendly intake), hierarchy (title largest; section H2; labels medium weight; help text smaller/lighter), density (generous vertical rhythm; avoid wall-of-boxes), alignment (labels flush right or top-aligned in pairs; choice groups indented under question), accent (one color for section bars or required markers), contrast (WCAG AA on labels and instructions). State where checkboxes need a clear hit target vs inline legal text.
Rules & constraints
  • Label clarity: every field answers “of what?” (“Work email”, not “Email”).
  • One question, one control pattern: exclusives = radio; multi = checkboxes; don’t mix.
  • Required honesty: mark optional fields; don’t default everything required.
  • Verbatim gate: policy, consent, and certification language copied from user sources only.
  • Completion path: last section includes certification name/date/signature fields when the use case needs it.
Common failure modes
  • Placeholder replaces the label → add visible labels; placeholders are hints only.
  • Fishing-expedition forms → cut fields without a stated reviewer or system use.
  • Random field order → reorder to scenario flow; group related rows.
  • Duplicate asks (city in two sections) → merge or cross-reference once.
  • Unspecified radio/checkbox options → list every option label explicitly.
  • Dense single-column marathon → split sections; use label+field pairs for short items.
  • Missing conditional logic → document show/hide rules beside affected fields.
  • Generic “form template” voice → set tone and issuer context in design intent.
Quality checklist
  • Every interactive control appears in the field inventory with type and required flag.
  • Section order matches completion scenario; tab flow is top-to-bottom, left-to-right within pairs.
  • Static instructions precede the fields they govern.
  • Choice fields list complete, non-overlapping options.
  • Legal or policy text is user-supplied and unchanged.
  • Design intent covers tone, hierarchy, density, and accent without layout coordinates.
  • No orphan labels or fields lacking purpose in the scenario.
创建一份蓝图，合并读者看到的内容（静态内容）、读者输入的内容（交互内容），以及引擎可以理解的设计意图。使用带标签的区块；页面映射稍后在 k2f 中完成。
子步骤
  1. 完成场景——谁负责填写（申请人、员工、患者），是独立填写还是需要附材料，预计用时、提交路径，以及必填与选填章节。删除不会影响办理结果的字段。
  2. 静态层——标题、版本或生效日期、发布方身份、简短的“如何填写”步骤、隐私或保留声明（仅使用用户提供的文本）、章节导语和页脚（第 x 页，共 y 页、联系方式）。不得虚构法律条款。
  3. 字段清单——使用表格或结构化列表：稳定 ID、用户可读标签、控件类型（单行文本、多行文本、复选框、单选按钮组、下拉框、日期、签名确认）、是否必填、占位符或格式提示、选择字段的选项、最大字符数或行数，以及不超过一行的帮助文本。将单选按钮组和复选框组归到同一个问题下，并明确写出互斥或多选语义。
  4. 信息架构——按照认知流程排序：身份识别 → 详细信息 → 选项 → 授权 → 确认。每节归组 5–9 个字段；主题变化时开始新章节。短标签与输入框成对排在双列行中；段落、多行答案和声明区块使用整行宽度。将条件区块（“仅当 Employment = Yes 时显示雇主信息区块”）明确写成规则，不要用隐含布局表达。
  5. 设计意图——基调（机构化、临床式冷静、友好信息收集）、层级（标题最大；章节使用 H2；标签采用中等字重；帮助文字更小、更浅）、密度（留出充足的垂直节奏；避免满屏方框）、对齐（在成对布局中将标签右对齐或顶部对齐；选项组在问题下方缩进）、强调色（章节色条或必填标记只使用一种颜色）、对比度（标签和说明达到 WCAG AA）。明确哪些复选框需要清晰的可点击区域，哪些属于行内法律文本。
规则与约束
  • 标签清晰度：每个字段都要回答“填写什么？”（使用“工作邮箱”，不要只写“邮箱”）。
  • 一个问题对应一种控件模式：单选使用单选按钮；多选使用复选框；不要混用。
  • 如实标记必填项：明确标注选填字段；不要默认所有字段都必填。
  • 逐字校验：政策、同意和认证措辞只能逐字复制自用户提供的来源。
  • 完成路径：如果用例需要，最后一个章节应包含认证人姓名、日期和签名字段。
常见失败模式
  • 占位符取代标签 → 添加可见标签；占位符只能作为提示。
  • 过度索取的表单 → 删除没有明确审核人员或系统用途的字段。
  • 字段顺序混乱 → 按照场景流程重新排序；将相关行归为一组。
  • 重复询问（城市在两个章节中出现）→ 合并，或仅交叉引用一次。
  • 未指定单选按钮或复选框选项 → 明确列出每个选项标签。
  • 密集的单栏马拉松 → 拆分章节；短项目使用“标签+字段”成对布局。
  • 缺少条件逻辑 → 在受影响字段旁记录显示或隐藏规则。
  • 通用“表单模板”语气 → 在设计意图中设定语气和发布方背景。
质量检查清单
  • 每个交互式控件都在字段清单中列出，并标明类型和必填状态。
  • 章节顺序与完成场景一致；Tab 顺序在整体上自上而下，在成对布局内从左到右。
  • 静态说明位于其对应字段之前。
  • 选择字段包含完整且互不重叠的选项。
  • 法律或政策文本来自用户且未作改动。
  • 设计意图涵盖语气、层级、密度和强调色，但不包含布局坐标。
  • 不存在孤立标签，也不存在在场景中没有用途的字段。

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 pages from the blueprint, bind field roles from the inventory, verify, and export the fillable PDF deliverable.
遵循 k2f，根据蓝图实例化页面、绑定字段清单中的字段角色、进行验证，然后导出可填写 PDF 交付物。