Back to Details

k2f-checklist

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

K2F Checklist — AI-Native Aesthetic Design

K2F 清单 — AI-native 美学设计

Purpose

用途

Teach agents to blueprint checklists in 
content_and_design.md
: what must be verified, how to group and sequence items, and aesthetic intent (scanability, checkbox rhythm, operational tone)—without inventing org policy, compliance gates, or thresholds the user did not supply.
教会 Agent 在 
content_and_design.md
中规划 清单：必须核验什么、如何对条目进行分组和排序，以及美学意图（可扫读性、复选框节奏、运营语气）——同时不得臆造用户未提供的组织政策、合规门禁或阈值。

Built on K2F

基于 K2F 构建

This skill produces checklists 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, item labels, check states—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

适用场景

  • Pre-launch, deploy, migration, event, travel, or handoff verification the user will run repeatedly or once under time pressure.
  • Consolidating runbooks or diligence lists into one printable or fillable checklist.
  • Multi-workstream readiness when grouped sections beat a flat list.
  • 用户会反复执行，或需要在时间压力下执行一次的上线前、部署、迁移、活动、旅行或交接核验。
  • 将 runbook 或尽调清单整合为一份可打印或可填写的清单。
  • 当分组章节优于平铺列表时，用于管理多个工作流的准备就绪状态。

Workflow

工作流

Step 1. Generate the content_and_design.md

步骤 1. 生成 content_and_design.md

Single blueprint for checklist content and design intent. Use labeled blocks (title band, context line, sections, checkbox rows, triggers, notes) the k2f skill can map later.
Sub-steps
  1. Checklist frame — Domain, who runs it, one-shot vs recurring use, and page budget (often one page per phase). Tone: calm procedural, time-critical deploy, or formal compliance.
  2. Scope & requirement audit — Gates, tools, risks, approvals, and decision criteria (stop, rollback, escalate). Unknowns → 
    OPEN QUESTION
    or 
    NEEDS USER INPUT
    ; never fabricate SLAs or thresholds.
  3. Information architecture (include / cut / merge) — Choose the dominant spine:
    • Chronological phases when order matters (e.g., Pre → Execute → Post; Plan → Pack → Go).
    • Parallel workstreams when teams advance independently (finance, legal, ops)—each section self-contained.
    • Hybrid only when needed; phase headers with workstream sub-blocks. Default blocks:
    • Title & context → checklist name, date/version slot, owner or role if supplied.
    • How to use (2–3 lines): when to run it, estimated time, what “done” means.
    • Core sections → themed groups with 4–12 items each; prefer verbs + observable outcome (“CI green on release branch”) over topics (“Testing”).
    • Triggers / exceptions → rollback, stop-ship, or escalation lines the user defined.
    • Optional appendix intent → links, ticket IDs, or data-room pointers—not duplicate checklist items. Cut vague items (“double-check quality”), duplicates across phases, narrative paragraphs, and nice-to-haves that do not gate the stated goal.
  4. Item contract pass — One action, one verifiable done state per row; parallel verbs across siblings. Add priority or owner only when requested. Pair “If yes…” follow-ups under the parent.
  5. Customization pass — Add context-specific sections (migrations, flags, sector items) only from user input or named templates. Keep stable section order for recurring use.
  6. Design intent — Tone: direct; urgency via section labels, not alarm copy. Hierarchy: title, context, then section heads over checkbox rows. Density: split long undifferentiated lists. Rhythm: one line per item; triggers separated from routine rows. Brand: restrained accent; print-friendly contrast.
Log assumptions (section order, omitted optionals) vs open questions (missing thresholds, owners, or policy text).
Rules & constraints
  • Verifiability gate: every item answers “how would I know it’s done?”—if not, rewrite or cut.
  • Truth gate: approvals, environments, metrics, and legal steps trace to user input or explicit stubs.
  • Scope gate: document in / out of scope for this checklist; post-checklist workflow is one line, not a runbook essay.
  • One-action gate: split compound rows (“review and deploy and notify”) into separate items or ordered sub-steps.
  • Gate ordering: blockers (tests, approvals, backups) appear before irreversible steps in chronological checklists.
  • Living-doc gate: note status-tracking intent only when requested; do not invent status enums.
Common failure modes
  • Flat laundry list with no phases or themes → regroup by time or workstream.
  • Items before prerequisites (“deploy to prod” before “staging verified”) → reorder chronological spine.
  • Missing triggers or rollback lines when user mentioned risk → add triggers section or flag 
    NEEDS USER INPUT
    .
  • Generic template ignoring user stack → inject only user-named tools and gates.
  • Essay instructions replacing checkable rows → convert to checkbox items plus a short how-to-use block.
  • Duplicate checks in every phase → keep once at the earliest gating section.
Quality checklist
  • Frame, page budget, tone, and requirement audit (gates, tools, triggers) documented.
  • IA choice (phases, workstreams, or hybrid) explicit; in/out scope and cuts explained.
  • Every item is one verifiable action with parallel wording; follow-ups tied to parents.
  • Triggers/stop conditions present or stubbed; assumptions vs open questions listed.
  • Design intent covers tone, hierarchy, density, rhythm, and brand for the full checklist.
使用单一蓝图承载清单内容与设计意图。采用带标签的区块（标题带、上下文行、章节、复选框行、触发条件、备注），供 k2f skill 后续映射。
子步骤
  1. 清单框架 — 明确领域、执行者、单次或重复使用场景，以及 页数预算（通常每个阶段一页）。语气可为冷静且程序化、时间紧迫的部署风格，或正式的合规风格。
  2. 范围与需求审计 — 门禁、工具、风险、审批，以及 决策标准（停止、回滚、升级处理）。未知项 → 
    OPEN QUESTION
    或 
    NEEDS USER INPUT
    ；绝不捏造 SLA 或阈值。
  3. 信息架构（纳入 / 删除 / 合并） — 选择主导主线：
    • 顺序重要时采用 按时间划分的阶段（例如：准备 → 执行 → 事后；规划 → 打包 → 上线）。
    • 团队独立推进时采用 并行工作流（财务、法务、运营）——每个章节自成一体。
    • 仅在确有需要时采用 混合模式；以阶段标题配合工作流子区块。 默认区块：
    • 标题与上下文 → 清单名称、日期/版本占位符，以及已提供的负责人或角色。
    • 使用方法（2–3 行）：何时执行、预计用时，以及“完成”的含义。
    • 核心章节 → 每组包含 4–12 个条目的主题分组；优先使用 动词 + 可观察结果（“发布分支上的 CI 状态为绿色”），而非主题名称（“测试”）。
    • 触发条件 / 例外情况 → 用户定义的回滚、停止发布或升级处理项。
    • 可选附录意图 → 链接、ticket ID 或数据室位置指引——不要重复清单条目。 删除模糊条目（“再次检查质量”）、跨阶段重复项、叙述性段落，以及不会阻挡既定目标达成的非必要项。
  4. 条目契约检查 — 每行仅包含一个动作和一个可验证的完成状态；同级条目使用并列动词。仅在用户要求时添加优先级或负责人。将“如果……”的后续项置于对应父项之下。
  5. 定制检查 — 仅根据用户输入或指定模板添加特定场景的章节（迁移、功能开关、行业项目）。重复使用时保持章节顺序稳定。
  6. 设计意图 — 语气：直接；通过章节标签而非警示性文案传达紧迫性。层级：标题、上下文，然后是章节标题，最后是复选框行。密度：拆分冗长且无差别的列表。节奏：每个条目一行；触发条件与常规条目分开。品牌：克制的强调色；适合打印的对比度。
分别记录 假设（章节顺序、省略的可选项）和 开放问题（缺失的阈值、负责人或政策文本）。
规则与约束
  • 可验证性关卡：每个条目都要回答“我怎么知道它已经完成？”——否则重写或删除。
  • 真实性关卡：审批、环境、指标和法务步骤必须可追溯至用户输入或明确的占位内容。
  • 范围关卡：记录此清单的 范围内 / 范围外 内容；清单后的流程仅用一行说明，不要写成冗长的 runbook。
  • 单一动作关卡：将包含多个动作的行（“审查、部署并通知”）拆分为独立条目或有序子步骤。
  • 关卡排序：在按时间排列的清单中，阻断项（测试、审批、备份）应位于不可逆步骤之前。
  • 动态文档关卡：仅在用户要求时说明状态跟踪意图；不要自行创造状态枚举。
常见失败模式
  • 没有阶段或主题的平铺式杂乱清单 → 按时间或工作流重新分组。
  • 条目先于前置条件（“部署到生产环境”出现在“预发布环境已验证”之前） → 按时间顺序重排主线。
  • 用户提到风险时却缺少触发条件或回滚项 → 添加触发条件章节，或标记 
    NEEDS USER INPUT
    。
  • 忽略用户技术栈的通用模板 → 仅加入用户明确指定的工具和门禁。
  • 用大段说明替代可勾选条目 → 转换为复选框条目，并添加简短的使用方法区块。
  • 每个阶段都重复检查 → 仅在最早的门禁章节保留一次。
质量检查清单
  • 已记录框架、页数预算、语气和需求审计（门禁、工具、触发条件）。
  • 已明确 IA 选择（阶段、工作流或混合模式）；说明了范围内/范围外内容及删减项。
  • 每个条目都是一个措辞平行的可验证动作；后续项与父项关联。
  • 已提供触发条件/停止条件或为其设置占位；已分别列出假设与开放问题。
  • 设计意图覆盖整份清单的语气、层级、密度、节奏和品牌。

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 checkbox items from the blueprint, apply design intent, verify, and export the runnable checklist (typically fillable PDF or DOCX).
遵循 k2f，根据蓝图实例化章节和复选框条目、应用设计意图、执行验证，并导出可直接使用的清单（通常为可填写的 PDF 或 DOCX）。