Skill 构建器（规格驱动）

要解决什么问题

自建 Agent Skill 时，常见痛点不是「写不出 SKILL.md」，而是没有上游规格就硬编、发布元信息在跨会话里被反复问命名与版本、交付物只有单文件缺少可进化的需求/方案看板，以及未经 with-skill 对比就上线导致误触发。

本技能定位在 need-to-skill-decoder 的下游执行者：输入应是《目标 Skill 规格文档》（需求本质、实现路径、可借鉴项目、约束、触发词）。规格缺失或含糊时，应回上游澄清，而不是从零访谈再造一套需求。

工作方式与交付物

流程复用 skill-creator 的三对话分离（Planner / Generator / Evaluator），并强制几项「施工方」约定：

• 阶段 1.5：一次性产出 publish-meta 表格（name、slug 带 chenlin- 前缀、displayName、summary、version、license、location），单次确认，禁止拆成四次追问。
• 阶段 2：编写 SKILL.md（description + when_to_use 字符上限、渐进披露 ≤500 行、明确「不用于」边界）；规格标注内容型时走 book-to-skill 分支（决策层 cheatsheet、索引切片读源，而非章节摘要）。
• 阶段 2.5：必种 REQUIREMENTS.md 与 SOLUTIONS.md，用规格信息首轮填充已做/待做/借鉴与 ADR，与 SKILL.md 一并打包。
• 阶段 3～4：设计真实场景测试 prompt，跑 eval 与用户评审；description 优化后 package_skill 打 .skill。
• 阶段 5（发布后）：评测结果可回流看板 Stream B。

设计宪章侧强调：验证权在人、对外不可逆动作默认「建议档」、每个 Skill 应能回答「帮用户养成什么好习惯」并在产物里嵌入下一步最小行动。

边界与依赖

• 前置：skill-creator、need-to-skill-decoder；借鉴 GitHub 项目时用 skill-seekers 取实现洞察，不整包搬运违许可证代码。
• 无 eval 环境：可跳过阶段 3，交付须标注「未经 eval 验证」。
• 质量标准：必须有上游规格、明确不用于边界、看板非空壳；禁止无规格从零编 Skill。