mcpField
K
k2f-checklist

k2f-checklist

github.com/suzheng文档处理3677 次安装2 周前更新
代码仓库

关于 k2f-checklist

k2f-checklist 指导 Agent 在排版前规划清晰、可验证的清单,适用于重复执行或时间紧迫的操作检查,并要求政策和阈值有用户输入作为依据。

主要功能

  1. 01规划清单结构与顺序
  2. 02编写可验证的单步条目
  3. 03审查范围与触发条件
  4. 04提供易读性设计指导
  5. 05遵循 K2F 导出流程

适用场景

  1. 01准备部署检查清单
  2. 02分组整理迁移就绪检查
  3. 03将运行手册整合为清单

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/suzheng/k2f --skill k2f-checklist

安装后在 Claude Code 中输入/k2f-checklist确认已加载。

详细介绍

K2F Checklist — AI 原生美学设计

目的

指导 Agent 在 content_and_design.md 中规划清单:需要核验的事项、如何对条目分组和排序,以及美学意图(易于浏览、复选框节奏、操作性语气)——不得臆造用户未提供的组织政策、合规关卡或阈值。

基于 K2F 构建

此技能将清单生成为 .K2F 包。按照 k2f 技能进行编写:解包或初始化工作区、编辑语义树、打包/验证并导出。K2F 让 Agent 专注于含义——分区、条目标签、勾选状态,而非坐标。

开始构建前,请安装核心技能:npx skills add suzheng/k2f --skill k2f。

适用场景

  • 用户需要反复运行,或在时间紧迫时运行一次的发布前、部署、迁移、活动、差旅或交接核验。
  • 将运行手册或尽调清单整合为一份可打印或可填写的清单。
  • 多工作流就绪情况核验,适合按分组分区而非使用平铺列表。

工作流

步骤 1:生成 content_and_design.md

为清单内容和设计意图编写一份统一蓝图。使用带标签的区块(标题栏、背景说明、分区、复选框行、触发条件、备注),便于 k2f 技能后续映射。

子步骤

  1. 清单框架 — 领域、执行者、一次性还是周期性使用,以及页数预算(通常每个阶段一页)。语气:平和严谨、时间紧迫的部署风格,或正式合规风格。

  2. 范围与需求审查 — 关卡、工具、风险、审批,以及决策标准(停止、回滚、升级处理)。未知项 → OPEN QUESTION 或 NEEDS USER INPUT;绝不臆造 SLA 或阈值。

  3. 信息架构(纳入 / 删除 / 合并) — 选择主要结构:

    • 按时间顺序划分阶段,适用于顺序很重要的情况(例如:预备 → 执行 → 收尾;计划 → 打包 → 出发)。
    • 按并行工作流划分,适用于团队独立推进的情况(财务、法律、运营)——每个分区独立完整。
    • 仅在必要时采用混合结构;以阶段标题搭配工作流子区块。 默认区块:
    • 标题与背景 → 清单名称、日期/版本占位项,以及用户提供的负责人或角色。
    • 使用方法(2–3 行):何时运行、预计耗时、“完成”的定义。
    • 核心分区 → 按主题分组,每组 4–12 项;优先使用动词 + 可观察结果(“发布分支上的 CI 通过”),而非主题(“测试”)。
    • 触发条件 / 例外情况 → 用户定义的回滚、停止发布或升级处理说明。
    • 可选附录说明 → 链接、工单 ID 或数据室引用——不得重复清单条目。 删除含糊的条目(“再次检查质量”)、跨阶段重复项、叙述性段落,以及不会影响既定目标的可选事项。
  4. 条目规范检查 — 每行一个操作,并且只对应一个可核验的完成状态;同级条目使用平行动词。仅在用户要求时添加优先级或负责人。将“如果是……”后续事项放在其上级条目下。

  5. 定制检查 — 仅根据用户输入或指定模板添加特定情境分区(迁移、标志、行业事项)。周期性使用时,保持分区顺序稳定。

  6. 设计意图 — 语气:直接;通过分区标签体现紧迫性,而非使用危言耸听的文案。层级:标题、背景,然后是分区标题和复选框行。密度:拆分过长且缺少区分的列表。节奏:每项一行;触发条件与常规条目分开。品牌:克制使用强调色;对比度适合打印。

记录假设(分区顺序、省略的可选项)和待解决问题(缺失的阈值、负责人或政策文本)。

规则与约束

  • 可验证性门槛:每项都能回答“如何判断已完成?”——如果不能,就重写或删除。
  • 真实性门槛:审批、环境、指标和法律步骤都必须能追溯到用户输入或明确标注的占位内容。
  • 范围门槛:说明此清单的范围内/范围外内容;清单后的工作流用一句话说明,而不是写成操作手册式长文。
  • 单一操作门槛:将复合条目(“审查、部署并通知”)拆成独立项目或有序子步骤。
  • 门槛顺序:按时间顺序排列的清单中,阻碍项(测试、审批、备份)必须放在不可逆步骤之前。
  • 文档持续维护门槛:仅在用户提出要求时说明状态跟踪意图;不要自行编造状态枚举。

常见失败模式

  • 把条目平铺成没有阶段或主题的长清单 → 按时间或工作流重新分组。
  • 前置条件尚未满足就列出后续事项(“暂存环境已验证”之前就写“部署到生产环境”)→ 按时间顺序重新排列主线。
  • 用户提及风险,却没有设置触发条件或回滚说明 → 添加触发条件章节,或标记为 NEEDS USER INPUT。
  • 使用通用模板而忽略用户的技术栈 → 仅加入用户提及的工具和门槛。
  • 用长篇说明取代可核查的条目 → 改为复选框条目,并附上简短的使用说明。
  • 在每个阶段重复检查项 → 仅在最早设置门槛的章节保留一次。

质量检查清单

  • 已记录框架、页数预算、语气和需求审查(门槛、工具、触发条件)。
  • 已明确选择 IA 结构(阶段、工作流或混合结构);已说明范围内/范围外内容及删减项。
  • 每项都是一个可验证操作,并采用平行表述;后续事项与其父项关联。
  • 已列出触发条件/停止条件,或标记为待补充;已列出假设与待解决的问题。
  • 设计意图涵盖整份清单的语气、层级、密度、节奏和品牌风格。
Step 2. 使用 content_and_design.md 和 k2f skill 生成 K2F 文件,并导出为合适的文件格式。

遵循 k2f skill,根据蓝图创建章节和复选框条目,应用设计意图,进行验证,并导出可执行的清单(通常为可填写的 PDF 或 DOCX)。

评论

支持 Markdown