k2f-policy-document

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

K2F Policy Document — AI-Native Aesthetic Design

K2F 政策文档——AI 原生美学设计

Purpose

目的

Teach agents to blueprint policy documents before layout: scannable rule architecture, plain-language layers for employees, and formal hierarchy—without inventing benefits, legal obligations, jurisdictions, or approval paths the user or HR/legal did not supply.

指导 Agent 在排版前规划政策文档：构建易于扫描的规则架构、面向员工的通俗语言层次和正式层级结构，同时不得虚构用户或 HR/法务未提供的福利、法律义务、管辖区域或审批路径。

Built on K2F

基于 K2F 构建

This skill produces policy 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 (sections, emphasis, tables)—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

使用场景

New or refreshed single-policy pages (PTO, remote work, expenses, conduct, travel, security, leave types).
Handbook sections that must read consistently with house style but stay findable on first scan.
Reformatting draft or pasted policy language into a publishable structure for HR or legal review.
Not for chat-only policy Q&A, AgentRC scoring policies, or counsel-grade contracts (use k2f-contract).

新建或更新的单一政策页面（PTO、远程办公、费用报销、行为规范、差旅、安全、各类休假）。
需要符合内部统一风格，同时便于员工首次快速浏览的员工手册章节。
将草稿或粘贴的政策语言重新编排为可供 HR 或法务审核的可发布结构。
不适用于仅通过聊天进行的政策问答、AgentRC 评分政策或律师级合同（请使用 k2f-contract）。

Workflow

工作流

Step 1. Generate the content_and_design.md

Step 1：生成 content_and_design.md

One blueprint pairing information architecture with design intent. Label blocks the k2f skill can map to sections, callouts, and emphasis later.

Sub-steps

Document frame — Policy title, document ID if user provided, effective date, version, policy owner (team/role), and applicability (entities, locations, employment types). State whether this is new, amendment, or supersedes prior text; link prior version only from user inputs.
Purpose & scope — Two short blocks: why the policy exists (one paragraph max) and who/when it applies. Cut narrative that repeats the title; flag
```
HR VERIFY
```
when scope crosses regions the user did not specify.
At-a-glance layer — Quick summary (3–5 bullets or one short paragraph): what employees must know before reading detail. This is the scan anchor—not a second copy of every rule.
Definitions — Only terms that change compliance meaning in this policy; omit dictionary glossaries.
Policy statements — Numbered rules: clear subject, modal verb (
```
must
```
/
```
may not
```
/
```
requires approval
```
), and outcome. One obligation per bullet; no mixed “policy + how-to” in the same bullet.
Procedures — Separate numbered flows: how to request, report, escalate, or document compliance (forms, systems, timelines from user only). Procedures reference rules; they do not restate them in prose.
Roles & responsibilities — Compact matrix or bullets: employee, manager, HR, IT, finance, legal—who does what at each step.
Exceptions & approvals — Who may grant exceptions, required documentation, and where records live. If unknown,
```
APPROVAL PATH — USER TO CONFIRM
```
.
Related policies & references — Cross-links and external regs only when user named them; no fabricated citations.
Enforcement & questions — Consequences or progressive discipline only if user supplied; otherwise
```
LEGAL/HR TO CONFIRM
```
. Who to contact for edge cases and a single questions channel.
Revision history — Table or list: version, date, summary of change, approver—placeholders marked TBD until user fills.
Design intent — Clarity over decoration:
- Tone: neutral, authoritative, plain language in summary; formal precision in numbered rules; no marketing or apology voice.
- Hierarchy: title and applicability first; at-a-glance and policy statements strongest; procedures and roles secondary; revision history tertiary.
- Density: moderate—short paragraphs, bullets for rules and procedures; tables for roles or thresholds when user provided numbers; avoid wall-of-text essays.
- Palette: restrained neutrals, high body contrast, minimal accent on must/may not, deadlines, and approval paths; WCAG AA; no stock imagery that competes with rules.

Rules & constraints

Source gate: mandatory or jurisdiction-specific language stays verbatim from user; mark all other drafts
```
FOR HR/LEGAL REVIEW
```
.
Honesty gate: no invented PTO days, dollar limits, legal citations, systems, or approver names.
Separation gate: rules in policy statements; steps in procedures; do not hide the rule inside a procedure paragraph.
Applicability gate: every obligation names who it binds; ambiguous geography → flag, do not assume US-default silently.
Single-topic gate: one policy subject per blueprint; split unrelated topics (e.g., travel vs. expenses) unless user explicitly wants a combined handbook chapter with named parts.

Common failure modes

Essay introduction with no at-a-glance → employees never find the rule.
Rules buried in FAQ narrative → extract imperatives into numbered policy statements.
Procedures before rules → reorder so “what” precedes “how.”
Duplicate quick summary and full section → summary stays short; detail lives below.
Generic AI handbook voice → replace with user terms, systems, and approvers or mark TBD.
Missing who to contact → edge cases bounce to informal channels.
Amendment without what changed in revision history → compliance tracking breaks.
Mixing employee-facing plain text with privileged legal analysis → keep external-facing tone only.

Quality checklist

Frame includes applicability, effective date, and new/amend/supersedes status.
At-a-glance layer stands alone; policy statements are numbered and imperative.
Procedures separated; roles and exception path present or marked TBD.
User-mandated text verbatim; no invented limits, citations, or contacts.
Related policies listed only from user inputs.
Design intent specifies tone, hierarchy, density, and emphasis for rules vs. procedures.

创建一份将信息架构与设计意图相配对的蓝图。对区块进行标注，以便 k2f skill 后续将其映射为章节、callout 和强调内容。

子步骤

文档框架——政策标题、用户提供的文档 ID、生效日期、版本、政策负责人（团队/角色）和适用范围（实体、地点、雇佣类型）。说明该政策是新增、修订还是取代先前文本；仅根据用户输入链接先前版本。
目的与范围——两个简短区块：政策存在的原因（最多一段）以及适用于谁/何时适用。删减重复标题的叙述；当范围涉及用户未指定的地区时，标记
```
HR VERIFY
```
。
概览层——快速摘要（3–5 个要点或一个简短段落）：员工在阅读细节前必须了解的内容。这是快速浏览的锚点，而不是每条规则的第二份副本。
定义——仅收录会改变本政策合规含义的术语；省略词典式释义。
政策声明——编号规则：明确的主体、情态动词（
```
must
```
/
```
may not
```
/
```
requires approval
```
）和结果。每个要点只包含一项义务；同一要点中不得混合“政策 + 操作方法”。
流程——独立的编号流程：如何申请、报告、升级上报或记录合规情况（表单、系统和时限仅来自用户提供的信息）。流程引用对应规则，不要以叙述形式重复规则。
角色与职责——使用紧凑矩阵或要点：员工、经理、HR、IT、财务、法务——各自在每个步骤中负责什么。
例外与审批——谁可以批准例外、需要哪些文档以及记录存放在何处。如果未知，标记
```
APPROVAL PATH — USER TO CONFIRM
```
。
相关政策与引用——仅当用户明确提及时才添加交叉链接和外部法规；不得编造引用。
执行与疑问——仅在用户提供后果或渐进式纪律处分时使用；否则标记
```
LEGAL/HR TO CONFIRM
```
。注明处理边界情况的联系人，并设置单一的问题反馈渠道。
修订历史——表格或列表：版本、日期、变更摘要、审批人；在用户填写前，占位项标为 TBD。
设计意图——清晰优先于装饰：
- 语气：摘要采用中性、权威、通俗的语言；编号规则保持正式且精准；不使用营销式或致歉式口吻。
- 层级：标题和适用范围置于最前；概览和政策声明最突出；流程和角色次之；修订历史为三级。
- 信息密度：适中——使用短段落；规则和流程采用要点形式；当用户提供数字时，角色或阈值使用表格；避免大段文字。
- 配色：采用克制的中性色和较高的正文对比度；仅对 must/may not、截止时间和审批路径使用少量强调色；符合 WCAG AA；不使用会与规则争夺注意力的图库图片。

规则与约束

来源约束：强制性措辞或特定司法辖区的措辞必须逐字沿用用户提供的内容；所有其他草稿均标记
```
FOR HR/LEGAL REVIEW
```
。
诚实约束：不得虚构 PTO 天数、金额限制、法律引用、系统或审批人姓名。
分离约束：规则应放在政策声明中；步骤应放在流程中；不要把规则藏在流程段落里。
适用范围约束：每项义务都应注明其约束对象；地理适用范围存在歧义时，应进行标记，不得默认为美国。
单一主题约束：每份蓝图只涵盖一个政策主题；除非用户明确要求包含具名组成部分的综合员工手册章节，否则应拆分无关主题（例如差旅与费用报销）。

常见失败模式

以长篇引言开场，却缺少概览 → 员工始终无法找到规则。
规则埋在 FAQ 叙述中 → 将强制要求提取为编号的政策声明。
流程先于规则 → 重新排序，让“是什么”先于“如何做”。
快速摘要与完整章节重复 → 摘要应保持简短；详细内容置于下方。
泛化的 AI 员工手册口吻 → 改用用户提供的术语、系统和审批人，否则标记为 TBD。
缺少联系人 → 处理边界情况时，问题会流向非正式渠道。
修订后未在修订历史中说明变更内容 → 合规追踪会中断。
将面向员工的通俗文本与受法律特权保护的法律分析混在一起 → 仅保留面向发布对象的口吻。

质量检查清单

框架包含适用范围、生效日期以及新增/修订/取代状态。
概览层能够独立理解；政策声明采用编号并以命令式表述。
流程与规则分离；角色和例外审批路径已列出或标记为 TBD。
用户强制要求的文本逐字保留；未虚构限制、引用或联系人。
相关政策仅依据用户输入列出。
设计意图明确说明语气、层级、信息密度，以及规则与流程各自的强调方式。

Step 2. Use the content_and_design.md and k2f skill to generate a K2F file and export to an appropriate file format.

Step 2：使用 content_and_design.md 和 k2f skill 生成 K2F 文件并导出为适当的文件格式。

Follow k2f to build the policy from the blueprint, apply design-intent roles, verify, and export for HR/legal review (typically PDF or DOCX).

按照 k2f 根据蓝图构建政策，应用设计意图中的各项要求，执行验证并导出，以供 HR/法务审核（通常为 PDF 或 DOCX）。