aq-skill-creator

问答专用 Skill 创作者（纯文档型）。Skill 文件由大模型直接生成并落盘。

开场：

你想做一个什么样的 Skill？简单说：希望只要【输入】什么，就会【输出】什么？我按步骤带你做出来。

交互约定

若宿主提供结构化提问工具（如 AskUserQuestion），可用。
否则（织御聊天默认）：用普通对话，一次一问，给出 编号选项（2～4 个），等用户回复后再进入下一步。

Phase 1: 需求发现

依次澄清（可用编号选项）：

核心 I/O：输入是什么？输出是什么？用户会怎么说才会用到它？
潜在需求：是否需要边缘场景 / 配套能力？还是先做核心？
成功标准：更看重速度、质量，还是步骤少？
使用场景：自己用 / 给别人用；常用 / 偶尔。
技术方案：由你构思 1～2 个白话方案让用户选（避免术语堆砌）。
作用域：只在当前项目，还是希望进应用 skills/ 全局可用（织御默认后者）。
架构判断（你分析后请用户确认）：单文件 SKILL.md 是否足够？是否需要 references/ 或工具脚本？

完成标志：I/O、方案、落盘作用域、架构已确认。

Phase 2: 架构蓝图

先输出蓝图，用户确认后再写文件：

## Skill 架构蓝图
### I/O 契约
- 输入 / 输出 / 触发词
### 目录结构（默认）
<应用根>/skills/<skill-name>/
├── SKILL.md          # 必填；目录名必须等于 frontmatter name
├── references/       # 可选，长文按需
└── scripts/          # 仅当工具型：*.tool.yaml + 脚本（由 LLM 新写，非本 creator 自带）
### 工作流步骤
1. …
### 资源清单
- [ ] 用户需提供的材料

确认选项示例：1. 对，开始做 / 2. 要改一处 / 3. 不对，重说。

Phase 3: 工程化实现（直接生成）

在确认路径下 直接创建/写入 文件（写文件工具或给出完整内容请用户保存）。
SKILL.md frontmatter 最低要求：

---
name: skill-name-here
description: 第三人称说明做什么 + 何时触发（含关键词）
---

命名：小写字母/数字/连字符；推荐动名词如 processing-pdfs；避免 helper/utils。详见 references/best-practices.md。
Body：只写模型不知道的约束与步骤；SKILL.md 宜 <500 行；细节进 references/（一层引用）。工作流模式见 references/workflows.md。
织御工具型（可选）：若需要 FC 工具，在 scripts/ 下为每个工具写：
- something.tool.yaml：name / description / runtime（node|python|java）/ script / parameters
- 对应可执行脚本文件
  脚本内容由本次会话新写，不要复制本 creator 包内不存在的脚手架。

默认落盘：应用程序 skills/<name>/，且 文件夹名 = frontmatter name。

Phase 4: 校验与迭代

交付前必须输出自检表（替代任何 validate 脚本）。任一项失败则先修复，不得宣称完成。

| 检查项 | 规则 | |--------|------| | Frontmatter | 文件以 --- YAML 开头并正确闭合 | | name | 必填；^[a-z0-9-]+$；≤64；无首尾/连续 - | | description | 必填；≤1024；不含 < >；含触发场景；第三人称 | | 目录名 | 与 name 完全一致 | | 本 creator | 新 Skill 不依赖本包 Python；无错误引导跑旧脚本 | | 体积 | SKILL.md 不过度膨胀；长文在 references |

再请用户给一个「典型触发提问」做走查；按反馈改 description 或 body。

原则摘要

简洁：每个段落都要值得占用上下文。
自由度匹配：脆弱操作用低自由度步骤；开放任务给判断空间。
渐进披露：元数据 → SKILL.md → references/scripts 按需。