/zach-seller-skill-creator

name: zach-seller-skill-creator
description: 亚马逊卖家专用的 skill 创建器（中文）。当用户想把一个亚马逊运营/自媒体/日常工作流程变成可复用的 skill 时使用。触发场景包括但不限于：用户说"我想做一个 skill""把这个流程变成 skill""帮我写个自动化""优化我已有的 skill""给这个工作流做个自动化"，即使用户没用"skill"这个词，只要在描述"以后每次都这样做"的重复性工作时也应触发。本 skill 的核心差异：强制用户先回答 6 个业务问题（业务目标/过去做法/具体步骤/方法论/调用方式/期望输出）再进入创建流程，防止产出空洞 skill。Create new skills, improve existing skills, run evals and benchmarks — tailored for Amazon sellers with a Chinese-first workflow.

卖家 Skill 创建器

这是一个**中文版**的 skill 创建器，基于 Anthropic 官方 `skill-creator` 重构，针对亚马逊卖家（AI 基础较弱但有丰富业务经验的用户）优化。

核心差异：6 问硬门禁

官方 `skill-creator` 上来就问"这个 skill 要做什么"。卖家用户经常给出空洞的答案（比如"帮我做关键词分析"），导致产出的 skill 只是一份说明书、没有业务深度。

**本 skill 在官方流程前插入 6 个强制问题**。这 6 个问题是**硬门禁**——任何一个为空或答得敷衍，不得进入写 SKILL.md 的阶段。

---

工作流总览

【阶段 0】6 问硬门禁  ← 卖家版新增
    ↓
【阶段 1】意图澄清（基于阶段 0 已收集结果）
    ↓
【阶段 2】调研补齐
    ↓
【阶段 3】写 SKILL.md 初稿
    ↓
【阶段 4】写测试用例（2-3 个）
    ↓
【阶段 5】并行跑 with-skill + 基线
    ↓
【阶段 6】评分 + HTML 可视化
    ↓
【阶段 7】根据反馈迭代改进
    ↓
（可选）描述优化 + 打包

你的工作是根据用户当前所处的阶段，引导他们推进。如果用户直接说"我不想搞这么多测试，随便写个 skill 就行"，可以跳过阶段 4-7，但**阶段 0 的 6 问门禁不能跳过**。

---

与用户沟通的风格

用户群体：亚马逊卖家。可能对代码、JSON、断言（assertion）、基准（benchmark）等术语不熟悉。

沟通规则：

• 默认用中文对话
• 术语第一次出现时配一句通俗解释（例："assertion——就是用来判断 skill 输出合不合格的具体标准"）
• 不要动辄写"必须 MUST、绝对 NEVER"这样的强硬指令，而是解释"为什么这样做"
• 读到用户有明显的技术背景信号（会聊脚本、Git、JSON），可以切换到更专业的表达

禁用词（继承工作区规则）：赋能、抓手、综上所述、一言以蔽之、多维度赋能。

---

【阶段 0】6 问硬门禁

阶段 0 的正式执行脚本在 `references/6问引导式流程.md`。先读它，再开始问。**不要**把 `references/6问模板.md` 当成用户填写入口发出去。

阶段 0 的主协议

• 必须顺序走 `Q1 → Q6`，一个主题走完再进入下一个
• 每个主题优先用选项题，再用 1 段短简答补具体信息
• 选项里要主动使用亚马逊卖家预设，帮助用户点选：
• 业务类型：自动化、风险监控、决策支持、团队交付
• 工具/数据源：Sorftime、领星、SIF、本地 Excel/CSV/TXT、飞书表格、人工粘贴
• 判断框架：BCG 健康阈值、异常阈值、趋势对比、优先级分层
• 不提供“整份 6 问模板发给用户填写”的入口
• 如果用户一上来贴长文，先拆回当前主题，继续逐层补问，不要直接视为阶段 0 完成

6 维答案到 SKILL.md 的映射

阶段 0 收集完后，把结果对应到 SKILL.md 的这些段落：

| 阶段 0 维度 | 映射到 SKILL.md 的哪里 | |------------|------------------------| | Q1 业务目标 | `## 业务背景` 段（解释 why） | | Q2 现有做法 | `## 当前工作流（人工版）` 段（基线对照） | | Q3 具体步骤 | `## Skill 工作流（自动版）` 段（主干指令，转成编号步骤） | | Q4 方法论 | `## 核心原则 / 踩坑规避` 段（对应官方的 principles 概念） | | Q5 调用方式 | YAML `description` 字段 + `## 触发场景` 段 | | Q6 期望输出 | `## 输出规范` 段 |

硬门禁规则

采用“逐题门禁 + 阶段末总门禁”：

• 每一题结束时，先检查这一题是否已经具体到能落文档
• 任意一题出现以下情况，不得进入下一题，必须当场补问：
• **为空**：用户跳过没回答
• **敷衍**：答案只有一句话且不具体（例如 Q3 只回答“做数据分析”）
• **矛盾**：Q2 说“没做过”，Q3 却列了成熟流程，需要澄清真实状态
• **只谈动作不谈判断**：Q3 只有步骤顺序，没有任何“如果……则……”逻辑
• **只谈经验不谈规则**：Q4 只有“看经验”“综合判断”，没有具体阈值、优先级或例外条件
• **只谈结果不谈落点**：Q6 只说“给我报告”，没说保存到哪里或如何算完成

追问方式：引用用户的原话，指出哪里还不够具体，再给一个你想看到的粒度示例。

**例外**：用户明确说“我就想快速试试，先不管那么多”时，可以降级为只走 `Q1 + Q3 + Q6` 三个核心主题，但要明确告诉他：这样产出的 skill 更容易空、后面如果结果不满意需要回来补齐。

阶段 0 完成标志

当 6 个维度（或快速试试路径中的 3 个核心维度）都有可执行答案时，向用户复述一次（用 bullet list），让他确认。确认后才进入阶段 1。

---

【阶段 1】意图澄清

进入这一阶段的前提：阶段 0 的 6 维答案已经按引导式流程采集到位。

基于阶段 0 结果再补 4 个技术细节

官方 skill-creator 的标准 4 问，在这里作为补充：

1. **输出是否需要测试？** 有客观可验证输出的 skill（文件转换、数据提取、代码生成）适合做测试；主观输出的 skill（写作风格、设计）通常不用。根据 skill 类型给出建议，让用户决定。 2. **有没有现成的工具/脚本/MCP？** 如果用户提到过 Sorftime、领星、SIF 等 MCP，或者手头有 Python 脚本，让他说清楚 skill 里是否要直接复用。 3. **调用频率**是每周、每天、还是一事一议？这影响是否需要做 description 优化。 4. **谁来用？** 只有自己用、团队共用、还是要发布出去？团队共用的话要考虑不同人表达触发语的差异。

如果对话历史里已经有答案

经常发生的情况：用户进入本 skill 之前，已经在聊天里演示过一遍手动流程（比如"上周你帮我分析了 BCG 的关键词，就按那个流程做"）。这时优先从对话历史抽答案：用过的工具、步骤顺序、用户的修正、观察到的输入输出格式。抽完后复述给用户确认，别让他从头再讲一遍。

---

【阶段 2】调研补齐

在阶段 0-1 的基础上，主动问这些事情：

• **边界情况**：输入为空、数据缺失、API 失败时怎么办？
• **输入格式的具体例子**：用户提供一个真实文件或示例粘贴过来
• **成功标准**：什么样的输出算"对"？什么样的算"错"？
• **依赖项**：用到哪些 MCP、哪些文件路径、哪些外部脚本？

如果环境里有可用的 MCP（比如 Sorftime、领星、SIF），并且对本 skill 的调研有帮助（找类似 skill、查文档、看最佳实践），可以派子 agent 并行调研。目的是带着信息回到用户，降低他的负担。

这一步的目标：**把"写 SKILL.md 所需的事实"都收齐**。等到真正动笔写 SKILL.md 时不用再反复问。

---

【阶段 3】写 SKILL.md 初稿

详细的写作规则见 `references/skill写作指南.md`。这里只讲关键动作。

YAML frontmatter 必填字段

• **name**：skill 标识符（英文小写 + 连字符，例如 `keyword-rank-report`）
• **description**：触发的主要机制。必须包含"做什么 + 什么时候用"。**推荐写得稍微"推一点"**——Claude 现在有"倾向于不调用 skill"的毛病，描述写保守了触发不到。

反例（太保守）： > 一个用来做关键词自然排名分析的 skill

正例（有推力）： > 生成关键词自然排名分析报告。当用户提到"关键词排名""自然位排名""Sorftime 反查""查 ASIN 曝光"时调用，即使没明说"分析"也要主动触发。

正文结构（按阶段 0 的 6 维答案填）

# [Skill 名称]

## 业务背景           ← 映射问 1：业务目标
## 当前工作流（人工版）  ← 映射问 2：过去怎么做
## Skill 工作流（自动版） ← 映射问 3：具体步骤
## 核心原则 / 踩坑规避   ← 映射问 4：方法论
## 触发场景            ← 映射问 5：调用方式
## 输出规范            ← 映射问 6：期望输出
## 引用文件            ← 如果有 references/、scripts/、assets/

关键写法

• **用祈使句**：不是"可以用脚本处理"，而是"用 `scripts/xxx.py` 处理"
• **解释 why**：不要简单写"必须做 X"，写"做 X 是因为 Y，否则会 Z"
• **输出格式用模板**：用 `## 报告结构` + 完整模板示范
• **SKILL.md 正文控制在 500 行以内**，超了就把细节拆到 `references/xxx.md`，正文只留"何时读"的指引
• **大型 reference 文件（>300 行）要有目录**

Skill 结构

skill-name/
├── SKILL.md (必需)
│   ├── YAML frontmatter
│   └── Markdown 正文
└── 可选资源
    ├── scripts/    - 固定/重复任务的可执行代码
    ├── references/ - 按需加载的文档
    └── assets/     - 输出使用的素材（模板、图标、字体）

三层加载机制（理解这个能帮你写得更好）

1. **元数据**（name + description）—— 永远在上下文里（~100 词） 2. **SKILL.md 正文** —— skill 触发时才进入上下文（<500 行） 3. **Bundled resources** —— 按需加载（无限制，脚本可以不加载直接执行）

所以"常用的指令放 SKILL.md，罕用的细节放 references"。

多领域组织

当一个 skill 支持多套方案（比如 SP/SB/SD 广告），按变体拆：

ads-report/
├── SKILL.md (主干流程 + 选择逻辑)
└── references/
    ├── sp.md
    ├── sb.md
    └── sd.md

Claude 只读需要的那份 reference。

---

【阶段 4】写测试用例

写完 SKILL.md 初稿后，想 2-3 个**真实用户会说的**测试提示词——不是抽象的"格式化数据"，而是"我 BCG 的这个 ASIN 最近广告占比掉得厉害，你按我们之前那个报告模板帮我看下"。

把测试保存到 `evals/evals.json`。**这一步先只写 prompt，不写断言**——断言在阶段 6 跑测试的同时补。

{
  "skill_name": "example-skill",
  "evals": [
    {
      "id": 1,
      "prompt": "用户的任务 prompt",
      "expected_output": "期望结果的描述",
      "files": []
    }
  ]
}

完整 schema 见 `references/schemas.md`。

把测试用例发给用户看：

> 我想用这几个测试 case 跑一下，你看合适吗？要不要加/减？

---

【阶段 5】并行跑测试与基线

这一段是**连贯动作**，不要中间停。**不要**用 `/skill-test` 或任何其他的测试 skill，就按下面的流程做。

结果存放位置：`<skill-name>-workspace/` 作为 skill 目录的**同级目录**。里面按迭代组织（`iteration-1/`、`iteration-2/`），每个测试 case 一个子目录（`eval-0/`、`eval-1/`）。不要一次建全，边做边建。

Step 1：同一轮内同时派出 with-skill + baseline

对每个测试 case 派两个 subagent——一个带 skill，一个不带。**关键：这两个要在同一轮里同时派出**，不要先跑 with-skill，等结果出来再跑 baseline。原因是让它们在差不多的时间完成