zach-seller-skill-creator

Name: zach-seller-skill-creator
Author: zach22-1999

123stars32forks

How to install zach-seller-skill-creator?

zach22-1999/amazon-skills/zach-seller-skill-creator

$npx -y skills add zach22-1999/amazon-skills --skill zach-seller-skill-creator

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# 卖家 Skill 创建器
2
3	这是一个中文版的 skill 创建器，基于 Anthropic 官方 `skill-creator` 重构，针对亚马逊卖家（AI 基础较弱但有丰富业务经验的用户）优化。
4
5	## 核心差异：6 问硬门禁
6
7	官方 `skill-creator` 上来就问"这个 skill 要做什么"。卖家用户经常给出空洞的答案（比如"帮我做关键词分析"），导致产出的 skill 只是一份说明书、没有业务深度。
8
9	本 skill 在官方流程前插入 6 个强制问题。这 6 个问题是硬门禁——任何一个为空或答得敷衍，不得进入写 SKILL.md 的阶段。
10
11	---
12
13	## 工作流总览
14
15	```
16	【阶段 0】6 问硬门禁 ← 卖家版新增
17	↓
18	【阶段 1】意图澄清（基于阶段 0 已收集结果）
19	↓
20	【阶段 2】调研补齐
21	↓
22	【阶段 3】写 SKILL.md 初稿
23	↓
24	【阶段 4】写测试用例（2-3 个）
25	↓
26	【阶段 5】并行跑 with-skill + 基线
27	↓
28	【阶段 6】评分 + HTML 可视化
29	↓
30	【阶段 7】根据反馈迭代改进
31	↓
32	（可选）描述优化 + 打包
33	```
34
35	你的工作是根据用户当前所处的阶段，引导他们推进。如果用户直接说"我不想搞这么多测试，随便写个 skill 就行"，可以跳过阶段 4-7，但阶段 0 的 6 问门禁不能跳过。
36
37	---
38
39	## 与用户沟通的风格
40
41	用户群体：亚马逊卖家。可能对代码、JSON、断言（assertion）、基准（benchmark）等术语不熟悉。
42
43	沟通规则：
44	- 默认用中文对话
45	- 术语第一次出现时配一句通俗解释（例："assertion——就是用来判断 skill 输出合不合格的具体标准"）
46	- 不要动辄写"必须 MUST、绝对 NEVER"这样的强硬指令，而是解释"为什么这样做"
47	- 读到用户有明显的技术背景信号（会聊脚本、Git、JSON），可以切换到更专业的表达
48
49	禁用词（继承工作区规则）：赋能、抓手、综上所述、一言以蔽之、多维度赋能。
50
51	---
52
53	## 【阶段 0】6 问硬门禁
54
55	阶段 0 的正式执行脚本在 `references/6问引导式流程.md`。先读它，再开始问。不要把 `references/6问模板.md` 当成用户填写入口发出去。
56
57	### 阶段 0 的主协议
58
59	- 必须顺序走 `Q1 → Q6`，一个主题走完再进入下一个
60	- 每个主题优先用选项题，再用 1 段短简答补具体信息
61	- 选项里要主动使用亚马逊卖家预设，帮助用户点选：
62	- 业务类型：自动化、风险监控、决策支持、团队交付
63	- 工具/数据源：Sorftime、领星、SIF、本地 Excel/CSV/TXT、飞书表格、人工粘贴
64	- 判断框架：BCG 健康阈值、异常阈值、趋势对比、优先级分层
65	- 不提供“整份 6 问模板发给用户填写”的入口
66	- 如果用户一上来贴长文，先拆回当前主题，继续逐层补问，不要直接视为阶段 0 完成
67
68	### 6 维答案到 SKILL.md 的映射
69
70	阶段 0 收集完后，把结果对应到 SKILL.md 的这些段落：
71
72	\| 阶段 0 维度 \| 映射到 SKILL.md 的哪里 \|
73	\|------------\|------------------------\|
74	\| Q1 业务目标 \| `## 业务背景` 段（解释 why） \|
75	\| Q2 现有做法 \| `## 当前工作流（人工版）` 段（基线对照） \|
76	\| Q3 具体步骤 \| `## Skill 工作流（自动版）` 段（主干指令，转成编号步骤） \|
77	\| Q4 方法论 \| `## 核心原则 / 踩坑规避` 段（对应官方的 principles 概念） \|
78	\| Q5 调用方式 \| YAML `description` 字段 + `## 触发场景` 段 \|
79	\| Q6 期望输出 \| `## 输出规范` 段 \|
80
81	### 硬门禁规则
82
83	采用“逐题门禁 + 阶段末总门禁”：
84
85	- 每一题结束时，先检查这一题是否已经具体到能落文档
86	- 任意一题出现以下情况，不得进入下一题，必须当场补问：
87	- 为空：用户跳过没回答
88	- 敷衍：答案只有一句话且不具体（例如 Q3 只回答“做数据分析”）
89	- 矛盾：Q2 说“没做过”，Q3 却列了成熟流程，需要澄清真实状态
90	- 只谈动作不谈判断：Q3 只有步骤顺序，没有任何“如果……则……”逻辑
91	- 只谈经验不谈规则：Q4 只有“看经验”“综合判断”，没有具体阈值、优先级或例外条件
92	- 只谈结果不谈落点：Q6 只说“给我报告”，没说保存到哪里或如何算完成
93
94	追问方式：引用用户的原话，指出哪里还不够具体，再给一个你想看到的粒度示例。
95
96	例外：用户明确说“我就想快速试试，先不管那么多”时，可以降级为只走 `Q1 + Q3 + Q6` 三个核心主题，但要明确告诉他：这样产出的 skill 更容易空、后面如果结果不满意需要回来补齐。
97
98	### 阶段 0 完成标志
99
100	当 6 个维度（或快速试试路径中的 3 个核心维度）都有可执行答案时，向用户复述一次（用 bullet list），让他确认。确认后才进入阶段 1。
101
102
103
104	---
105
106	## 【阶段 1】意图澄清
107
108	进入这一阶段的前提：阶段 0 的 6 维答案已经按引导式流程采集到位。
109
110	### 基于阶段 0 结果再补 4 个技术细节
111
112	官方 skill-creator 的标准 4 问，在这里作为补充：
113
114	1. 输出是否需要测试？有客观可验证输出的 skill（文件转换、数据提取、代码生成）适合做测试；主观输出的 skill（写作风格、设计）通常不用。根据 skill 类型给出建议，让用户决定。
115	2. 有没有现成的工具/脚本/MCP？如果用户提到过 Sorftime、领星、SIF 等 MCP，或者手头有 Python 脚本，让他说清楚 skill 里是否要直接复用。
116	3. 调用频率是每周、每天、还是一事一议？这影响是否需要做 description 优化。
117	4. 谁来用？只有自己用、团队共用、还是要发布出去？团队共用的话要考虑不同人表达触发语的差异。
118
119	### 如果对话历史里已经有答案
120
121	经常发生的情况：用户进入本 skill 之前，已经在聊天里演示过一遍手动流程（比如"上周你帮我分析了 BCG 的关键词，就按那个流程做"）。这时优先从对话历史抽答案：用过的工具、步骤顺序、用户的修正、观察到的输入输出格式。抽完后复述给用户确认，别让他从头再讲一遍。
122
123
124
125	---
126
127	## 【阶段 2】调研补齐
128
129	在阶段 0-1 的基础上，主动问这些事情：
130
131	- 边界情况：输入为空、数据缺失、API 失败时怎么办？
132	- 输入格式的具体例子：用户提供一个真实文件或示例粘贴过来
133	- 成功标准：什么样的输出算"对"？什么样的算"错"？
134	- 依赖项：用到哪些 MCP、哪些文件路径、哪些外部脚本？
135
136	如果环境里有可用的 MCP（比如 Sorftime、领星、SIF），并且对本 skill 的调研有帮助（找类似 skill、查文档、看最佳实践），可以派子 agent 并行调研。目的是带着信息回到用户，降低他的负担。
137
138	这一步的目标：把"写 SKILL.md 所需的事实"都收齐。等到真正动笔写 SKILL.md 时不用再反复问。
139
140
141
142	---
143
144	## 【阶段 3】写 SKILL.md 初稿
145
146	详细的写作规则见 `references/skill写作指南.md`。这里只讲关键动作。
147
148	### YAML frontmatter 必填字段
149
150	- name：skill 标识符（英文小写 + 连字符，例如 `keyword-rank-report`）
151	- description：触发的主要机制。必须包含"做什么 + 什么时候用"。推荐写得稍微"推一点"——Claude 现在有"倾向于不调用 skill"的毛病，描述写保守了触发不到。
152
153	反例（太保守）：
154	> 一个用来做关键词自然排名分析的 skill
155
156	正例（有推力）：
157	> 生成关键词自然排名分析报告。当用户提到"关键词排名""自然位排名""Sorftime 反查""查 ASIN 曝光"时调用，即使没明说"分析"也要主动触发。
158
159	### 正文结构（按阶段 0 的 6 维答案填）
160
161	```markdown
162	# [Skill 名称]
163
164	## 业务背景 ← 映射问 1：业务目标
165	## 当前工作流（人工版） ← 映射问 2：过去怎么做
166	## Skill 工作流（自动版） ← 映射问 3：具体步骤
167	## 核心原则 / 踩坑规避 ← 映射问 4：方法论
168	## 触发场景 ← 映射问 5：调用方式
169	## 输出规范 ← 映射问 6：期望输出
170	## 引用文件 ← 如果有 references/、scripts/、assets/
171	```
172
173	### 关键写法
174
175	- 用祈使句：不是"可以用脚本处理"，而是"用 `scripts/xxx.py` 处理"
176	- 解释 why：不要简单写"必须做 X"，写"做 X 是因为 Y，否则会 Z"
177	- 输出格式用模板：用 `## 报告结构` + 完整模板示范
178	- SKILL.md 正文控制在 500 行以内，超了就把细节拆到 `references/xxx.md`，正文只留"何时读"的指引
179	- 大型 reference 文件（>300 行）要有目录
180
181	### Skill 结构
182
183	```
184	skill-name/
185	├── SKILL.md (必需)
186	│ ├── YAML frontmatter
187	│ └── Markdown 正文
188	└── 可选资源
189	├── scripts/ - 固定/重复任务的可执行代码
190	├── references/ - 按需加载的文档
191	└── assets/ - 输出使用的素材（模板、图标、字体）
192	```
193
194	### 三层加载机制（理解这个能帮你写得更好）
195
196	1. 元数据（name + description）—— 永远在上下文里（~100 词）
197	2. SKILL.md 正文 —— skill 触发时才进入上下文（<500 行）
198	3. Bundled resources —— 按需加载（无限制，脚本可以不加载直接执行）
199
200	所以"常用的指令放 SKILL.md，罕用的细节放 references"。
201
202	### 多领域组织
203
204	当一个 skill 支持多套方案（比如

People who liked this also viewed

6 picks

Type

zach-seller-skill-creator

123stars32forks

View on GitHub

How to install zach-seller-skill-creator?

zach22-1999/amazon-skills/zach-seller-skill-creator

$npx -y skills add zach22-1999/amazon-skills --skill zach-seller-skill-creator

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# 卖家 Skill 创建器
2
3	这是一个中文版的 skill 创建器，基于 Anthropic 官方 `skill-creator` 重构，针对亚马逊卖家（AI 基础较弱但有丰富业务经验的用户）优化。
4
5	## 核心差异：6 问硬门禁
6
7	官方 `skill-creator` 上来就问"这个 skill 要做什么"。卖家用户经常给出空洞的答案（比如"帮我做关键词分析"），导致产出的 skill 只是一份说明书、没有业务深度。
8
9	本 skill 在官方流程前插入 6 个强制问题。这 6 个问题是硬门禁——任何一个为空或答得敷衍，不得进入写 SKILL.md 的阶段。
10
11	---
12
13	## 工作流总览
14
15	```
16	【阶段 0】6 问硬门禁 ← 卖家版新增
17	↓
18	【阶段 1】意图澄清（基于阶段 0 已收集结果）
19	↓
20	【阶段 2】调研补齐
21	↓
22	【阶段 3】写 SKILL.md 初稿
23	↓
24	【阶段 4】写测试用例（2-3 个）
25	↓
26	【阶段 5】并行跑 with-skill + 基线
27	↓
28	【阶段 6】评分 + HTML 可视化
29	↓
30	【阶段 7】根据反馈迭代改进
31	↓
32	（可选）描述优化 + 打包
33	```
34
35	你的工作是根据用户当前所处的阶段，引导他们推进。如果用户直接说"我不想搞这么多测试，随便写个 skill 就行"，可以跳过阶段 4-7，但阶段 0 的 6 问门禁不能跳过。
36
37	---
38
39	## 与用户沟通的风格
40
41	用户群体：亚马逊卖家。可能对代码、JSON、断言（assertion）、基准（benchmark）等术语不熟悉。
42
43	沟通规则：
44	- 默认用中文对话
45	- 术语第一次出现时配一句通俗解释（例："assertion——就是用来判断 skill 输出合不合格的具体标准"）
46	- 不要动辄写"必须 MUST、绝对 NEVER"这样的强硬指令，而是解释"为什么这样做"
47	- 读到用户有明显的技术背景信号（会聊脚本、Git、JSON），可以切换到更专业的表达
48
49	禁用词（继承工作区规则）：赋能、抓手、综上所述、一言以蔽之、多维度赋能。
50
51	---
52
53	## 【阶段 0】6 问硬门禁
54
55	阶段 0 的正式执行脚本在 `references/6问引导式流程.md`。先读它，再开始问。不要把 `references/6问模板.md` 当成用户填写入口发出去。
56
57	### 阶段 0 的主协议
58
59	- 必须顺序走 `Q1 → Q6`，一个主题走完再进入下一个
60	- 每个主题优先用选项题，再用 1 段短简答补具体信息
61	- 选项里要主动使用亚马逊卖家预设，帮助用户点选：
62	- 业务类型：自动化、风险监控、决策支持、团队交付
63	- 工具/数据源：Sorftime、领星、SIF、本地 Excel/CSV/TXT、飞书表格、人工粘贴
64	- 判断框架：BCG 健康阈值、异常阈值、趋势对比、优先级分层
65	- 不提供“整份 6 问模板发给用户填写”的入口
66	- 如果用户一上来贴长文，先拆回当前主题，继续逐层补问，不要直接视为阶段 0 完成
67
68	### 6 维答案到 SKILL.md 的映射
69
70	阶段 0 收集完后，把结果对应到 SKILL.md 的这些段落：
71
72	\| 阶段 0 维度 \| 映射到 SKILL.md 的哪里 \|
73	\|------------\|------------------------\|
74	\| Q1 业务目标 \| `## 业务背景` 段（解释 why） \|
75	\| Q2 现有做法 \| `## 当前工作流（人工版）` 段（基线对照） \|
76	\| Q3 具体步骤 \| `## Skill 工作流（自动版）` 段（主干指令，转成编号步骤） \|
77	\| Q4 方法论 \| `## 核心原则 / 踩坑规避` 段（对应官方的 principles 概念） \|
78	\| Q5 调用方式 \| YAML `description` 字段 + `## 触发场景` 段 \|
79	\| Q6 期望输出 \| `## 输出规范` 段 \|
80
81	### 硬门禁规则
82
83	采用“逐题门禁 + 阶段末总门禁”：
84
85	- 每一题结束时，先检查这一题是否已经具体到能落文档
86	- 任意一题出现以下情况，不得进入下一题，必须当场补问：
87	- 为空：用户跳过没回答
88	- 敷衍：答案只有一句话且不具体（例如 Q3 只回答“做数据分析”）
89	- 矛盾：Q2 说“没做过”，Q3 却列了成熟流程，需要澄清真实状态
90	- 只谈动作不谈判断：Q3 只有步骤顺序，没有任何“如果……则……”逻辑
91	- 只谈经验不谈规则：Q4 只有“看经验”“综合判断”，没有具体阈值、优先级或例外条件
92	- 只谈结果不谈落点：Q6 只说“给我报告”，没说保存到哪里或如何算完成
93
94	追问方式：引用用户的原话，指出哪里还不够具体，再给一个你想看到的粒度示例。
95
96	例外：用户明确说“我就想快速试试，先不管那么多”时，可以降级为只走 `Q1 + Q3 + Q6` 三个核心主题，但要明确告诉他：这样产出的 skill 更容易空、后面如果结果不满意需要回来补齐。
97
98	### 阶段 0 完成标志
99
100	当 6 个维度（或快速试试路径中的 3 个核心维度）都有可执行答案时，向用户复述一次（用 bullet list），让他确认。确认后才进入阶段 1。
101
102
103
104	---
105
106	## 【阶段 1】意图澄清
107
108	进入这一阶段的前提：阶段 0 的 6 维答案已经按引导式流程采集到位。
109
110	### 基于阶段 0 结果再补 4 个技术细节
111
112	官方 skill-creator 的标准 4 问，在这里作为补充：
113
114	1. 输出是否需要测试？有客观可验证输出的 skill（文件转换、数据提取、代码生成）适合做测试；主观输出的 skill（写作风格、设计）通常不用。根据 skill 类型给出建议，让用户决定。
115	2. 有没有现成的工具/脚本/MCP？如果用户提到过 Sorftime、领星、SIF 等 MCP，或者手头有 Python 脚本，让他说清楚 skill 里是否要直接复用。
116	3. 调用频率是每周、每天、还是一事一议？这影响是否需要做 description 优化。
117	4. 谁来用？只有自己用、团队共用、还是要发布出去？团队共用的话要考虑不同人表达触发语的差异。
118
119	### 如果对话历史里已经有答案
120
121	经常发生的情况：用户进入本 skill 之前，已经在聊天里演示过一遍手动流程（比如"上周你帮我分析了 BCG 的关键词，就按那个流程做"）。这时优先从对话历史抽答案：用过的工具、步骤顺序、用户的修正、观察到的输入输出格式。抽完后复述给用户确认，别让他从头再讲一遍。
122
123
124
125	---
126
127	## 【阶段 2】调研补齐
128
129	在阶段 0-1 的基础上，主动问这些事情：
130
131	- 边界情况：输入为空、数据缺失、API 失败时怎么办？
132	- 输入格式的具体例子：用户提供一个真实文件或示例粘贴过来
133	- 成功标准：什么样的输出算"对"？什么样的算"错"？
134	- 依赖项：用到哪些 MCP、哪些文件路径、哪些外部脚本？
135
136	如果环境里有可用的 MCP（比如 Sorftime、领星、SIF），并且对本 skill 的调研有帮助（找类似 skill、查文档、看最佳实践），可以派子 agent 并行调研。目的是带着信息回到用户，降低他的负担。
137
138	这一步的目标：把"写 SKILL.md 所需的事实"都收齐。等到真正动笔写 SKILL.md 时不用再反复问。
139
140
141
142	---
143
144	## 【阶段 3】写 SKILL.md 初稿
145
146	详细的写作规则见 `references/skill写作指南.md`。这里只讲关键动作。
147
148	### YAML frontmatter 必填字段
149
150	- name：skill 标识符（英文小写 + 连字符，例如 `keyword-rank-report`）
151	- description：触发的主要机制。必须包含"做什么 + 什么时候用"。推荐写得稍微"推一点"——Claude 现在有"倾向于不调用 skill"的毛病，描述写保守了触发不到。
152
153	反例（太保守）：
154	> 一个用来做关键词自然排名分析的 skill
155
156	正例（有推力）：
157	> 生成关键词自然排名分析报告。当用户提到"关键词排名""自然位排名""Sorftime 反查""查 ASIN 曝光"时调用，即使没明说"分析"也要主动触发。
158
159	### 正文结构（按阶段 0 的 6 维答案填）
160
161	```markdown
162	# [Skill 名称]
163
164	## 业务背景 ← 映射问 1：业务目标
165	## 当前工作流（人工版） ← 映射问 2：过去怎么做
166	## Skill 工作流（自动版） ← 映射问 3：具体步骤
167	## 核心原则 / 踩坑规避 ← 映射问 4：方法论
168	## 触发场景 ← 映射问 5：调用方式
169	## 输出规范 ← 映射问 6：期望输出
170	## 引用文件 ← 如果有 references/、scripts/、assets/
171	```
172
173	### 关键写法
174
175	- 用祈使句：不是"可以用脚本处理"，而是"用 `scripts/xxx.py` 处理"
176	- 解释 why：不要简单写"必须做 X"，写"做 X 是因为 Y，否则会 Z"
177	- 输出格式用模板：用 `## 报告结构` + 完整模板示范
178	- SKILL.md 正文控制在 500 行以内，超了就把细节拆到 `references/xxx.md`，正文只留"何时读"的指引
179	- 大型 reference 文件（>300 行）要有目录
180
181	### Skill 结构
182
183	```
184	skill-name/
185	├── SKILL.md (必需)
186	│ ├── YAML frontmatter
187	│ └── Markdown 正文
188	└── 可选资源
189	├── scripts/ - 固定/重复任务的可执行代码
190	├── references/ - 按需加载的文档
191	└── assets/ - 输出使用的素材（模板、图标、字体）
192	```
193
194	### 三层加载机制（理解这个能帮你写得更好）
195
196	1. 元数据（name + description）—— 永远在上下文里（~100 词）
197	2. SKILL.md 正文 —— skill 触发时才进入上下文（<500 行）
198	3. Bundled resources —— 按需加载（无限制，脚本可以不加载直接执行）
199
200	所以"常用的指令放 SKILL.md，罕用的细节放 references"。
201
202	### 多领域组织
203
204	当一个 skill 支持多套方案（比如

People who liked this also viewed

6 picks

Type