Back to Details

k2f-intake-form

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

K2F Intake Form — AI-Native Aesthetic Design

K2F 信息采集表——AI 原生美学设计

Purpose

目的

Teach agents to blueprint intake forms in 
content_and_design.md
: what to collect before a relationship or case begins, how to sequence and group questions, and aesthetic intent (tone, hierarchy, fillable density)—without inventing clinical protocols, legal consent text, or eligibility rules the user did not supply.
指导 Agent 在 
content_and_design.md
中规划信息采集表：在建立服务或合作关系、启动案例之前应收集哪些信息，如何排序和分组问题，以及美学意图（语气、层级、可填写密度）——同时不得臆造用户未提供的临床规范、法律同意文本或资格规则。

Built on K2F

基于 K2F

This skill produces intake forms 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—sections, labels, field roles—not coordinates.
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

何时使用

  • Printable or fillable intake for clinics, agencies, legal, consulting, or enrollment—and redesigns of email questionnaires, legacy PDFs, or multi-step wizards as one coherent packet.
  • 适用于诊所、代理机构、法律服务、咨询或登记报名场景的可打印或可填写信息采集表——也可将电子邮件问卷、旧版 PDF 或多步骤向导重新设计为一份连贯的资料包。

Workflow

工作流

Step 1. Generate the content_and_design.md

第 1 步：生成 content_and_design.md

Single blueprint for form content and design intent. Use labeled blocks (header, instructions, sections, field rows, consent, review) the k2f skill can map later.
Sub-steps
  1. Intake frame — Domain (healthcare, professional services, creative brief, internal project), organization, audience (new patient, client, vendor), submission path, page budget (often 1–2 pages; add pages only when regulated sections or signature blocks require it), tone band (clinical-calm, warm service, formal compliance).
  2. Listen & requirement audit — From brief or template: must-collect facts (identity, contact, reason for visit, dates, insurance IDs, emergency contact). Mark attachment-backed items once. Unknowns → 
    OPEN QUESTION
    or 
    NEEDS USER INPUT
    ; never guess statutory or clinical wording.
  3. Information architecture (include / cut / merge) — Default stack (reorder when the frame demands it):
    • Header → form title, org, optional logo note, version or effective date if supplied.
    • Instructions (2–4 lines): what to bring, estimated time, how data will be used, who to call with questions.
    • Identity & contact → legal name, DOB or age gate when relevant, phone, email, address; emergency contact when normative.
    • Reason & context → why they are here, referral source, urgency, service line or project type.
    • Domain blocks → only sections the user or template requires (e.g., insurance, medical history, scope, budget, stakeholders)—one theme per section.
    • Preferences & logistics → scheduling, communication, accessibility needs—compact rows, not essays.
    • Consent & attestation → signature, date, checkboxes only with user-supplied or stubbed legal copy.
    • Review intent → summary mirrors prior sections; identical labels.
    • Cut duplicate contacts, off-topic surveys, re-entered attachment data, optional hobbies.
  4. Section flow pass — Easy facts first; sensitive history mid-document; consent last. Yes/no before “If yes, describe…”. Default one scrollable packet; name wizard steps in the blueprint only when the user requires them.
  5. Field typing pass — Per prompt: one-line factual; short multiline (2–4 lines) for context; controlled yes/no/select rows; date fields with format note; signature block intent. State word or line limits in labels for open text. When in doubt, shorter—intake is discovery, not a memoir.
  6. Design intent — Tone: respectful, low anxiety; legal/clinical copy only when supplied. Hierarchy: title and org first; strong section heads; clear labels. Density: section breaks; aligned label–field pairs; no underline grids. Rhythm: row facts plus small multiline bands; consent separated. Brand: restrained, one accent, readable contrast.
Log assumptions (order, omitted optionals) vs open questions (blockers for fields or consent).
Rules & constraints
  • Truth gate: org names, clinical questions, consent clauses, and prefilled defaults trace to user input or explicit stubs.
  • Scope gate: in / out of scope for this intake; post-submit flow is one instruction line, not a plan.
  • One-purpose gate: each field asks one thing; split compound prompts.
  • Non-duplication gate: data on attachments → pointer or “provided separately” checkbox—not full re-entry.
  • Consent gate: no fabricated HIPAA, GDPR, or treatment consent; flag 
    NEEDS USER INPUT
    .
  • Length gate: overflow → drop optional sections or move to follow-up form; do not shrink type in the blueprint.
Common failure modes
  • Planning essay or wizard bullet dump → labeled fields with types and answer-space intent.
  • Sensitive questions before basic contact → reorder stack.
  • Missing instructions or signature block → add brief how-to-submit and attestation intent.
  • Generic questionnaire (“tell us about yourself”) → replace with domain-specific, concrete prompts.
  • Review step that introduces new questions → review mirrors prior sections only.
Quality checklist
  • Frame, page budget, tone, and requirement audit (must-collect vs attachments) documented.
  • Section stack and in/out scope explicit; cuts explained.
  • Every field has type, label text, and answer-space intent; conditional follow-ups noted.
  • Consent and legal slots stubbed or sourced; assumptions vs open questions listed.
  • Design intent covers tone, hierarchy, density, rhythm, and brand for the full form.
为表单内容和设计意图创建一份统一蓝图。使用带标签的区块（页眉、说明、章节、字段行、同意、复核），供 k2f skill 后续映射。
子步骤
  1. 采集框架——领域（医疗保健、专业服务、创意需求简报、内部项目）、机构、受众（新患者、客户、供应商）、提交路径、页数预算（通常为 1–2 页；仅当受监管章节或签名块确有需要时才增加页数）、语气档位（临床沉着、温暖服务、正式合规）。
  2. 倾听与需求审计——从需求说明或模板中提取：必须收集的事实信息（身份、联系方式、来访原因、日期、保险编号、紧急联系人）。对附件支持项仅标记一次。未知项 → 
    OPEN QUESTION
    或 
    NEEDS USER INPUT
    ；绝不猜测法定条文或临床措辞。
  3. 信息架构（纳入 / 删除 / 合并）——默认结构如下（可按框架要求重新排序）：
    • 页眉 → 表单标题、机构名称、可选的 Logo 说明，以及用户提供的版本号或生效日期。
    • 说明（2–4 行）：需携带的材料、预计耗时、数据使用方式，以及遇到问题时应联系谁。
    • 身份与联系方式 → 法定姓名、出生日期（DOB）或年龄门槛（视相关情况而定）、电话、电子邮箱、地址；在适用时收集紧急联系人。
    • 原因与背景 → 来访目的、转介来源、紧急程度、服务线或项目类型。
    • 领域模块 → 仅设置用户或模板要求的章节（如保险、病史、项目范围、预算、利益相关者）——每个章节只处理一个主题。
    • 偏好与事务安排 → 排期、沟通方式、无障碍需求——采用紧凑字段行，而不是长篇文本框。
    • 同意与声明 → 签名、日期、复选框，且法律文案必须来自用户提供或明确设为占位。
    • 复核意图 → 摘要与此前各节一一对应，并使用完全一致的标签。
    • 删除重复的联系人信息、偏离主题的调查、要求重新录入附件中已有数据的项目，以及可选的爱好问题。
  4. 章节流程检查——先询问容易回答的事实；敏感病史放在文档中部；同意事项放在末尾。是/否问题放在“如果是，请描述……”之前。默认采用一份可滚动的资料包；仅当用户要求时，才在蓝图中为向导步骤命名。
  5. 字段类型检查——根据具体提示设计：单行事实型字段；用于背景说明的短多行字段（2–4 行）；受控的是/否/选项字段行；附格式说明的日期字段；签名区意图。开放式文本字段应在标签中注明字数或行数上限。拿不准时，选择更短的版本——信息采集是为了发现需求，而不是写回忆录。
  6. 设计意图——语气：尊重、低焦虑；法律或临床文案仅在用户提供时使用。层级：标题和机构名称优先；章节标题醒目；标签清晰。密度：通过章节进行分隔；标签与字段成对对齐；不使用下划线网格。节奏：事实型单行字段与小型多行内容区交替；同意事项单独分隔。品牌：风格克制、仅使用一种强调色，并保持清晰对比度。
记录假设（排序、删去的可选项）与开放问题（会阻碍字段或同意项确定的因素）。
规则与约束
  • 真实性关卡：机构名称、临床问题、同意条款和预填默认值必须可追溯至用户输入或明确的占位内容。
  • 范围关卡：明确本次采集范围内/范围外的事项；提交后的流程仅用一行说明，不制作完整计划。
  • 单一目的关卡：每个字段只询问一件事；拆分复合问题。
  • 去重关卡：附件中已有的数据 → 仅设置引用或“另行提供”复选框——不要要求再次完整录入。
  • 同意关卡：不得编造 HIPAA、GDPR 或治疗同意内容；应标记 
    NEEDS USER INPUT
    。
  • 长度关卡：内容溢出时，删除可选章节或移至后续表单；不要在蓝图中缩小字号。
常见失败模式
  • 写成规划文章或堆砌向导要点 → 改为带字段类型及作答空间意图的标签化字段。
  • 敏感问题排在基本联系信息之前 → 调整模块顺序。
  • 缺少说明或签名块 → 添加简要的提交说明和声明区意图。
  • 通用问卷（“请介绍一下你自己”）→ 替换为领域专属、具体的问题。
  • 复核步骤引入新问题 → 复核部分只复现此前章节。
质量检查清单
  • 已记录框架、页数预算、语气和需求审计（必须收集项与附件项）。
  • 章节结构及范围内/范围外事项明确；已解释删除项。
  • 每个字段都有类型、标签文本和作答空间意图；已标注条件式追问。
  • 同意项和法律内容已设为占位或注明来源；已列出假设与开放问题。
  • 设计意图涵盖整份表单的语气、层级、密度、节奏和品牌。

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 sections and form fields from the blueprint, apply design intent, verify, and export the submission-ready intake (typically fillable PDF or DOCX).
按照 k2f 技能，根据蓝图实例化章节和表单字段，应用设计意图，执行验证，并导出可直接提交的信息采集表（通常为可填写 PDF 或 DOCX）。