技能介绍

要解决的问题

手写 SKILL.md 的难点不在格式，而在需求没想清楚就落盘。一个 Skill 的核心是输入到输出的映射，很多作者起步时只说一句「想做个处理 PDF 的技能」，真正落笔写 name、description 和 Body 时才发现边界模糊、触发场景不清，产出要么过长挤占上下文，要么过短以至于模型不知道约束。这个技能把创作拆成四个阶段，用问答把 I/O、作用域、架构决策逐一确认后再写文件。

工作方式

主线是「先问清楚，再画蓝图，最后落盘校验」：

Phase 1 需求发现：依次澄清核心 I/O（用户会怎么说才会用到）、边缘场景与配套能力、成功标准（速度 / 质量 / 步骤数）、使用场景、技术方案、作用域（当前项目还是 skills/ 全局）、架构判断（单文件够不够，是否需要 references/ 或工具脚本）。
Phase 2 架构蓝图：先输出蓝图，用户确认后才写文件。确认选项刻意收窄为「对 / 改一处 / 不对重说」，避免开放式反馈来回拉扯。
Phase 3 工程化实现：直接在确认路径下创建文件，frontmatter 满足最低要求；命名遵循 ^[a-z0-9-]+$，推荐 processing-pdfs 这类动名词，Body 只写模型不知道的约束与步骤，且文件夹名等于 frontmatter 的 name。
Phase 4 校验与迭代：交付前打印自检表（frontmatter、name、description、目录名、体积等），任一项失败先修复再交付；随后用一个「典型触发提问」走查，按反馈调整 description 或 Body。

交互上优先使用宿主的结构化提问工具（如 AskUserQuestion），不可用时退化为普通聊天，一次一问并给出 2～4 个编号选项。

适用边界

它是纯文档型创作者，不生成 Python 脚本或二进制资源。架构判断阶段会提示你是否需要额外文件，但实现仍要自己补或换工具。它假设宿主具备读写文件能力；作用域默认偏向应用级 skills/，项目级需求需在发现阶段明确改掉。自检表替代脚本校验，意味着「通过」是人工核对的结果，不是自动化测试的背书。