zach22-1999/zach-seller-skill-creator
亚马逊卖家专用的 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.
npx skills add https://github.com/zach22-1999/amazon-skills --skill zach-seller-skill-creator这是一个中文版的 skill 创建器，基于 Anthropic 官方 skill-creator 重构，针对亚马逊卖家（AI 基础较弱但有丰富业务经验的用户）优化。
官方 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）等术语不熟悉。
沟通规则：
禁用词（继承工作区规则）：赋能、抓手、综上所述、一言以蔽之、多维度赋能。
阶段 0 的正式执行脚本在 references/6问引导式流程.md。先读它，再开始问。不要把 references/6问模板.md 当成用户填写入口发出去。
Q1 → Q6，一个主题走完再进入下一个阶段 0 收集完后，把结果对应到 SKILL.md 的这些段落：
| 阶段 0 维度 | 映射到 SKILL.md 的哪里 |
|------------|------------------------|
| Q1 业务目标 | ## 业务背景 段（解释 why） |
| Q2 现有做法 | ## 当前工作流（人工版） 段（基线对照） |
| Q3 具体步骤 | ## Skill 工作流（自动版） 段（主干指令，转成编号步骤） |
| Q4 方法论 | ## 核心原则 / 踩坑规避 段（对应官方的 principles 概念） |
| Q5 调用方式 | YAML description 字段 + ## 触发场景 段 |
| Q6 期望输出 | ## 输出规范 段 |
采用“逐题门禁 + 阶段末总门禁”：
追问方式：引用用户的原话，指出哪里还不够具体，再给一个你想看到的粒度示例。
例外：用户明确说“我就想快速试试，先不管那么多”时，可以降级为只走 Q1 + Q3 + Q6 三个核心主题，但要明确告诉他：这样产出的 skill 更容易空、后面如果结果不满意需要回来补齐。
当 6 个维度（或快速试试路径中的 3 个核心维度）都有可执行答案时，向用户复述一次（用 bullet list），让他确认。确认后才进入阶段 1。
进入这一阶段的前提：阶段 0 的 6 维答案已经按引导式流程采集到位。
官方 skill-creator 的标准 4 问，在这里作为补充：
经常发生的情况：用户进入本 skill 之前，已经在聊天里演示过一遍手动流程（比如"上周你帮我分析了 BCG 的关键词，就按那个流程做"）。这时优先从对话历史抽答案：用过的工具、步骤顺序、用户的修正、观察到的输入输出格式。抽完后复述给用户确认，别让他从头再讲一遍。
在阶段 0-1 的基础上，主动问这些事情：
如果环境里有可用的 MCP（比如 Sorftime、领星、SIF），并且对本 skill 的调研有帮助（找类似 skill、查文档、看最佳实践），可以派子 agent 并行调研。目的是带着信息回到用户，降低他的负担。
这一步的目标：把"写 SKILL.md 所需的事实"都收齐。等到真正动笔写 SKILL.md 时不用再反复问。
详细的写作规则见 references/skill写作指南.md。这里只讲关键动作。
keyword-rank-report）反例（太保守）：
> 一个用来做关键词自然排名分析的 skill
正例（有推力）：
> 生成关键词自然排名分析报告。当用户提到"关键词排名""自然位排名""Sorftime 反查""查 ASIN 曝光"时调用，即使没明说"分析"也要主动触发。
# [Skill 名称]
## 业务背景 ← 映射问 1：业务目标
## 当前工作流（人工版） ← 映射问 2：过去怎么做
## Skill 工作流（自动版） ← 映射问 3：具体步骤
## 核心原则 / 踩坑规避 ← 映射问 4：方法论
## 触发场景 ← 映射问 5：调用方式
## 输出规范 ← 映射问 6：期望输出
## 引用文件 ← 如果有 references/、scripts/、assets/
scripts/xxx.py 处理"## 报告结构 + 完整模板示范references/xxx.md，正文只留"何时读"的指引skill-name/
├── SKILL.md (必需)
│ ├── YAML frontmatter
│ └── Markdown 正文
└── 可选资源
├── scripts/ - 固定/重复任务的可执行代码
├── references/ - 按需加载的文档
└── assets/ - 输出使用的素材（模板、图标、字体）
所以"常用的指令放 SKILL.md，罕用的细节放 references"。
当一个 skill 支持多套方案（比如 SP/SB/SD 广告），按变体拆：
ads-report/
├── SKILL.md (主干流程 + 选择逻辑)
└── references/
├── sp.md
├── sb.md
└── sd.md
Claude 只读需要的那份 reference。
写完 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 跑一下，你看合适吗？要不要加/减？
这一段是连贯动作，不要中间停。不要用 /skill-test 或任何其他的测试 skill，就按下面的流程做。
结果存放位置：<skill-name>-workspace/ 作为 skill 目录的同级目录。里面按迭代组织（iteration-1/、iteration-2/），每个测试 case 一个子目录（eval-0/、eval-1/）。不要一次建全，边做边建。
对每个测试 case 派两个 subagent——一个带 skill，一个不带。关键：这两个要在同一轮里同时派出，不要先跑 with-skill，等结果出来再跑 baseline。原因是让它们在差不多的时间完成，减少系统状态差异。
With-skill run：
执行以下任务：
- Skill 路径：<skill 路径>
- 任务：<eval prompt>
- 输入文件：<eval 附带的文件；没有就写 none>
- 输出保存到：<workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
- 要保存的输出：<用户真正在意的文件，比如 "the .docx file" 或 "the final CSV">
Baseline run（prompt 相同，但基线根据场景不同）：
without_skill/outputs/。cp -r <skill 路径> <workspace>/skill-snapshot/)，让 baseline subagent 指向快照，保存到 old_skill/outputs/。同时给每个 eval 写 eval_metadata.json（assertions 先留空）。给每个 eval 起有描述性的名字（基于测试内容，不要叫 "eval-0"），目录名也用这个名字。如果这次迭代用到新的或修改过的 prompt，需要为每个新 eval 目录都重建这些文件——不要以为会自动继承上一次迭代的。
{
"eval_id": 0,
"eval_name": "descriptive-name-here",
"prompt": "用户的任务 prompt",
"assertions": []
}
别干等。利用这段时间给每个测试 case 写量化断言并给用户解释。如果 evals/evals.json 里已有断言，也要 review 一遍再给用户解释。
好的断言特征：
写完后更新 eval_metadata.json 和 evals/evals.json。顺便告诉用户查看器里他会看到什么——两种东西：定性输出 + 定量 benchmark。
每个 subagent 完成时，你会收到一个通知，里面有 total_tokens 和 duration_ms。立刻保存到该 run 目录下的 timing.json：
{
"total_tokens": 84852,
"duration_ms": 23332,
"total_duration_seconds": 23.3
}
这是唯一能抓到这个数据的机会——过了通知就没了。一个一个处理，别想着攒一批再处理。
所有 run 跑完后做 4 件事：
派一个 grader subagent（或者你自己 inline 做）读 agents/grader.md 的指令，对每个 assertion 用 outputs 做判断。结果写到每个 run 目录的 grading.json 里。字段名必须是 text、passed、evidence（不是 name/met/details 等变体），因为 HTML 查看器依赖这三个精确字段名。
能脚本化验证的 assertion，写脚本跑而不是肉眼看——脚本更快、更可靠、跨迭代可复用。
在 zach-seller-skill-creator 目录下运行：
python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>
产出 benchmark.json 和 benchmark.md，包含每个配置的 pass_rate、用时、token 数（mean ± stddev 和 delta）。如果要手动生成 benchmark.json，schema 见 references/schemas.md。
摆放顺序：每个 with_skill 版本排在对应 baseline 前面，方便用户比对。
读 benchmark 数据，看有没有被均值掩盖的 pattern。参考 agents/analyzer.md 的"Analyzing Benchmark Results"部分，关注：
定性输出 + 定量数据一起看：
nohup python ~/.claude/skills/zach-seller-skill-creator/eval-viewer/generate_review.py \
<workspace>/iteration-N \
--skill-name "my-skill" \
--benchmark <workspace>/iteration-N/benchmark.json \
> /dev/null 2>&1 &
VIEWER_PID=$!
第 2 次及以后的迭代，加 --previous-workspace <workspace>/iteration-<N-1> 做对比。
无显示环境（Cowork / 远程）：用 --static <输出路径> 生成独立 HTML 文件，用户点 "Submit All Reviews" 时会下载 feedback.json。下载后把它放回 workspace 目录供下次迭代读取。
别自己造轮子写 HTML——用 generate_review.py 就好。
告诉用户类似这样的话：
> 我已经在你浏览器里打开了结果。有两个 tab：
> - Outputs — 每个 test case 点进去看输出，底下有文本框留反馈
> - Benchmark — 看定量对比
>
> 看完后来这边说一声就行。
Outputs tab（每次一个 test case）：
Benchmark tab：pass rate、时间、token 的统计概览，带 per-eval 细分和分析师观察。
导航用 prev/next 按钮或方向键。完成后点 "Submit All Reviews" 保存所有反馈到 feedback.json。
用户说完事了之后，读 feedback.json：
{
"reviews": [
{"run_id": "eval-0-with_skill", "feedback": "图表缺坐标轴标签", "timestamp": "..."},
{"run_id": "eval-1-with_skill", "feedback": "", "timestamp": "..."},
{"run_id": "eval-2-with_skill", "feedback": "完美，继续这样", "timestamp": "..."}
],
"status": "complete"
}
空反馈 = 用户觉得 OK。把改进精力集中在有具体吐槽的 test case 上。
最后别忘了杀查看器：
kill $VIEWER_PID 2>/dev/null
这是整个循环的心脏。测试跑了，用户审过了，现在要根据反馈把 skill 改好。
create_docx.py 或 build_chart.py，那就是强信号：把这个脚本内置到 skill（写一次放 scripts/，指令里告诉 skill 用它）。省下每次调用的重复造轮子。这一步挺重要的（我们在这儿创造价值哩），你的思考时间不是瓶颈——慢一点、想透。建议写一份 draft，然后换个视角重看、改进。真正站进用户的位置，理解他要什么。
改完之后：
iteration-<N+1>/，包括基线。without_skill（不加载 skill），跨迭代不变--previous-workspace <上一迭代目录>何时停：
当你需要对两个版本的 skill 做更严谨的对比（例如用户问"新版本真的比旧版好吗？"），有一套盲比对机制。详见 agents/comparator.md 和 agents/analyzer.md。
核心思想：把两个输出扔给一个独立 agent，不告诉它谁是谁，让它判质量；然后解盲再分析赢家为什么赢。
这是可选的、需要 subagent，多数用户用不到。人工审阅循环通常已经够用。
SKILL.md frontmatter 的 description 是决定 Claude 是否调用这个 skill 的主要机制。创建或改进 skill 后，可以主动问用户要不要做 description 优化。
做 20 个 eval queries——混合 should-trigger 和 should-not-trigger。存成 JSON：
[
{"query": "用户的 prompt", "should_trigger": true},
{"query": "另一个 prompt", "should_trigger": false}
]
查询必须真实具体，是 Claude Code 或 Claude.ai 用户会真的输入的东西。不要抽象请求，要有细节：文件路径、用户的背景、列名和数值、公司名、URL、一点背景故事。有的可以小写、有的可以有缩写或错别字、有的像日常口语。长度混合，关注边缘情况而不是显而易见的。
反例："格式化一下这份数据"、"从 PDF 提取文字"、"做个图表"
正例："我老板刚扔给我一个 xlsx 文件（在我下载目录里，叫 'Q4 sales final FINAL v2.xlsx' 之类的），她想让我加一列显示利润率百分比。我记得收入在 C 列、成本在 D 列"
要避免：不要让 should-not-trigger 显而易见地无关。"写个 fibonacci 函数"作为 PDF skill 的反例——太简单了，测不出任何东西。反例要真的棘手。
用 HTML 模板给用户看 eval set：
assets/eval_review.html__EVAL_DATA_PLACEHOLDER__ → eval items 的 JSON 数组（不要加引号——它是 JS 变量赋值）__SKILL_NAME_PLACEHOLDER__ → skill 名__SKILL_DESCRIPTION_PLACEHOLDER__ → skill 当前 description/tmp/eval_review_<skill-name>.html）并打开：open /tmp/eval_review_<skill-name>.html~/Downloads/eval_set.json——如果有重名（eval_set (1).json），取最新的这一步很关键——bad eval queries 会导致 bad description。
告诉用户："这个要跑一会儿——我在后台跑，过一会儿来看进度。"
把 eval set 存到 workspace，然后后台跑：
python -m scripts.run_loop \
--eval-set <path-to-trigger-eval.json> \
--skill-path <path-to-skill> \
--model <当前会话的 model id> \
--max-iterations 5 \
--verbose
--model 用当前会话的 model id（你的 system prompt 里有），这样触发测试匹配用户真实体验。
跑的同时，周期性 tail 一下输出，告诉用户跑到第几轮、分数如何。
这个脚本会自动做完整优化循环：把 eval set 分成 60% train + 40% held-out test，对当前 description 跑 3 遍（稳定性），用 extended thinking 让 Claude 基于失败案例提改进，每个新 description 在 train 和 test 上重评，最多 5 轮。结束时在浏览器打开 HTML 报告，返回 JSON（含 best_description——用 test 分数选而不是 train 分数，防过拟合）。
理解触发机制有助于写好 eval queries。Skills 在 Claude 的 available_skills 列表里展示 name + description，Claude 根据 description 决定要不要用。关键：Claude 只在自己不容易搞定的任务时才咨询 skill——像 "读这份 PDF" 这种简单一步就能办完的查询，即使 description 完全匹配也可能不触发，因为 Claude 用基础工具自己就能做。复杂、多步、专业的查询才会可靠触发。
所以你的 eval queries 应该有足够的实质内容让 Claude 觉得需要咨询 skill。过简的 query（"读文件 X"）是差的 test case——不管 description 多好都不会触发。
把 JSON 输出里的 best_description 更新到 skill 的 SKILL.md frontmatter。给用户看 before/after 和分数。
只在有 present_files 工具时跑。没有就跳过。有的话，把 skill 打包并把 .skill 文件交给用户：
python -m scripts.package_skill <path/to/skill-folder>
打包完，告诉用户生成的 .skill 文件路径，他可以安装到自己的环境。
核心流程相同（draft → test → review → improve → 循环），但因为没 subagent，机制要调整：
claude -p（只 Claude Code 有），跳过。package_skill.py 只要 Python 和文件系统就能跑，能用。--static <输出路径> 写独立 HTML，给用户一个链接点开。generate_review.py 生成 eval viewer 给人看。你要的是让人尽快看到例子！feedback.json，你读这个文件（可能要先申请访问）。run_loop.py / run_eval.py）在 Cowork 里能跑（它用 subprocess 调 claude -p，不用浏览器），但等 skill 稳定了、用户说 OK 了再做。agents/ 目录是给专业子 agent 的英文指令（Claude 派子 agent 时直接读，英文更稳）：
agents/grader.md — 如何用 outputs 评估 assertionsagents/comparator.md — 如何做盲 A/B 对比agents/analyzer.md — 如何分析一个版本为什么赢references/ 目录：
references/schemas.md — evals.json、grading.json 等的 JSON 结构（中文）references/6问引导式流程.md — 阶段 0 的唯一执行脚本（逐题引导 + 门禁校验）references/6问模板.md — 阶段 0 结果如何映射到 SKILL.md 的内部参考references/skill写作指南.md — SKILL.md 写作的完整规则与示例最后再重复一次核心循环：
遇到时记得把这些步骤加入 TodoList，避免漏掉。
祝创建顺利！
Take zach22-1999/zach-seller-skill-creator from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.