steel-skill-creator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Steel Skill Creator

Turn a recurring web task into an agent skill. The user describes the task and one set of example inputs. You drive the task end-to-end twice in a real Steel browser (once with the example inputs, once with mutated inputs), capture both traces through the Steel CLI, author a parameterized SKILL.md, install it, and verify it on a third input set.

The user does not provide a session ID. You generate both sessions yourself.

将重复的网页任务转换为Agent Skill。用户描述任务并提供一组示例输入。你将在真实的Steel浏览器中完整执行该任务两次（一次使用示例输入，一次使用修改后的输入），通过Steel CLI捕获两次操作的轨迹，编写参数化的SKILL.md，安装该Skill，并使用第三组输入进行验证。

用户无需提供会话ID，你需自行生成两个会话。

The principle this skill is built on

本Skill的设计原则

Steel agent traces are already 80% of a SKILL.md. They contain stable selectors prioritized by quality (testId → id → aria → name → CSS), accessibleNames for every clicked element, page boundaries, idle gaps that mark wait points, and parameter values inline as URL query strings and form inputs. Your job is mostly reading two traces side by side and writing the parts that aren't there yet: the goal, the parameter names, the success criteria, and the right Steel session configuration (stealth, proxy, credentials, profiles) for production replay.

The reason you generate both traces yourself: parameter extraction is reliable when you can diff two runs of the same flow with different inputs. Anything that differs at corresponding positions is a parameter; anything identical is an invariant. You can't get that from a single trace without guessing, and asking the user to record twice doubles their effort. Better that you do it.

Do not try to handle every edge case programmatically. Use your judgment. The references/ directory tells you what to look for; the rest is reading code and writing code.

Steel Agent的操作轨迹已经包含了SKILL.md所需内容的80%。轨迹中包含按优先级排序的稳定选择器（testId → id → aria → name → CSS）、每个点击元素的accessibleNames、页面边界、标记等待点的空闲间隔，以及作为URL查询字符串和表单输入内联的参数值。你的主要工作是将两个轨迹对比阅读，补全缺失的部分：目标、参数名称、成功标准，以及用于生产环境重放的正确Steel会话配置（隐身模式、代理、凭据、配置文件）。

你需要自行生成两个轨迹的原因：当你可以对比同一流程在不同输入下的两次运行结果时，参数提取会更可靠。对应位置中任何不同的内容都是参数；任何相同的内容都是不变量。仅通过单个轨迹无法确定参数，只能猜测，而让用户录制两次会增加他们的工作量，因此最好由你完成这项工作。

不要尝试通过编程处理所有边缘情况，请运用你的判断能力。references/目录会告诉你需要关注的内容；其余部分则需要你阅读和编写代码。

Prerequisites

前提条件

```
steel
```
CLI is installed and authenticated for browser driving.
The
```
steel-browser
```
skill is available — you'll use the same primitives (
```
steel browser start
```
,
```
navigate
```
,
```
snapshot
```
,
```
click
```
,
```
fill
```
,
```
wait
```
, etc.) to drive both recording sessions.
The task is described clearly enough that you can execute it. If the description is too vague ("automate my browsing"), ask for specifics before doing anything else.

已安装
```
steel
```
CLI并完成浏览器驱动的身份验证。
```
steel-browser
```
Skill可用——你将使用相同的原语（
```
steel browser start
```
、
```
navigate
```
、
```
snapshot
```
、
```
click
```
、
```
fill
```
、
```
wait
```
等）来驱动两次录制会话。
任务描述足够清晰，以便你可以执行。如果描述过于模糊（例如“自动化我的浏览操作”），请先询问具体细节再进行后续操作。

Workflow

工作流程

Step 1 — Gather task description and example inputs

步骤1 — 收集任务描述和示例输入

You need three things from the user:

Skill name — a kebab-case identifier (e.g.,
```
flight-price-probe
```
,
```
weekly-traffic-report
```
). If the user has not given one, propose one based on what the flow does and confirm.
One-line goal — what the skill is for, in the user's own words ("find cheapest direct flight between two airports on a given date range"). This becomes the basis of the generated skill's description.
One set of example inputs — concrete values that exercise the full flow. Not "search for flights"; "search SPU → FCO, depart 2026-06-13, return 2026-06-18". Be specific enough that you can actually execute the task without asking again.

If anything is missing or ambiguous, ask once, concisely. Don't drag the user through a long Q&A.

你需要从用户处获取三项信息：

Skill名称 — 短横线命名格式的标识符（例如
```
flight-price-probe
```
、
```
weekly-traffic-report
```
）。如果用户未提供，请根据流程功能提出一个名称并确认。
一行目标说明 — 用户对Skill用途的描述（例如“查找两个机场之间给定日期范围内的最便宜直飞航班”）。这将成为生成的Skill描述的基础。
一组示例输入 — 能覆盖完整流程的具体值。不能是“搜索航班”，而应是“搜索SPU → FCO，出发日期2026-06-13，返回日期2026-06-18”。描述需足够具体，确保你无需再次询问即可执行任务。

如果有任何信息缺失或模糊，请简洁地询问一次，不要让用户进行冗长的问答。

Step 2 — Confirm safety before recording

步骤2 — 录制前确认安全性

Before running the task even once, think about side effects:

Read-only flow (scraping, searching, reading reports, price lookups) → safe to run twice with different inputs. Proceed.
Side-effect flow (booking, paying, sending messages, submitting forms that trigger emails or charges, creating accounts, posting content) → stop and ask. Running this twice with arbitrary inputs could cost money, spam someone, or create real-world artifacts. Offer the user three options:
1. Use sandbox/test accounts/inputs for both runs.
2. Record once only, accept lower-quality parameterization (the generated skill will have to guess some parameters from heuristics rather than diff evidence), and clearly mark the skill as "single-trace draft" in its description.
3. Abandon the automation here and describe the steps in plain English as documentation rather than an executable skill.

Never silently run a side-effect flow twice. The user's trust is more important than the skill.

在首次运行任务之前，请考虑副作用：

只读流程（抓取、搜索、读取报告、价格查询）→ 可以安全地使用不同输入运行两次。继续执行。
有副作用的流程（预订、支付、发送消息、提交会触发邮件或收费的表单、创建账户、发布内容）→ 停止并询问用户。使用任意输入运行两次可能会产生费用、发送垃圾信息或创建实际的业务记录。为用户提供三个选项：
1. 对两次运行使用沙箱/测试账户/输入。
2. 仅录制一次，接受较低质量的参数化（生成的Skill将不得不通过启发式方法猜测某些参数，而非基于对比证据），并在其描述中明确标记为“单轨迹草稿”。
3. 在此处放弃自动化，改用纯英文步骤描述作为文档，而非可执行的Skill。

切勿在未告知用户的情况下运行有副作用的流程两次。用户的信任比Skill本身更重要。

Step 3 — Record trace #1 by driving the task yourself

步骤3 — 自行执行任务录制轨迹#1

Use the steel-browser primitives to perform the task end-to-end with the example inputs from step 1. Start a session (with the right configuration per

references/steel-primitives.md

), navigate, click, wait, extract — exactly the same patterns you'd use if you were running

/steel-browser

for the user.

Take screenshots and snapshots along the way to verify each step worked. If a step fails, debug it like you would in any normal Steel session — don't push through a broken state.

When the task reaches its success state (the data is extracted, the form is submitted, the confirmation page renders), stop the session. Save the session ID — you'll need it in step 5.

使用steel-browser原语，结合步骤1中的示例输入，完整执行任务。启动会话（根据

references/steel-primitives.md

配置正确的参数）、导航、点击、等待、提取——与你为用户运行

/steel-browser

时使用的模式完全相同。

在过程中截取屏幕截图和快照，验证每一步是否成功。如果某一步失败，请像在正常Steel会话中一样进行调试——不要在错误状态下继续执行。

当任务达到成功状态（数据已提取、表单已提交、确认页面已渲染）时，停止会话。保存会话ID——你将在步骤5中用到它。

Step 4 — Record trace #2 by replaying with mutated inputs

步骤4 — 使用修改后的输入重放并录制轨迹#2

Pick mutated inputs. For each example value from step 1, choose a sensible alternative that exercises the same flow:

Date → different date in the same or adjacent month.
Search term → semantically different but well-formed (different airport, different product category, different person's name).
IDs → a different known-good ID.

Aim for different inputs, same intent. The goal is a trace that takes the same conceptual path so the diff isolates parameters cleanly.

Run the task again in a fresh Steel session using the mutated inputs. Same configuration, same starting URL, same logical sequence of actions.

If trace #2 diverges from trace #1 — hits a login wall trace #1 didn't, encounters a CAPTCHA, lands on a structurally different page — stop and investigate. Consult

references/steel-primitives.md

to decide whether to add Steel session options (stealth, proxy, captcha solving) or whether to escalate to the user. Do not paper over the divergence.

Save the second session ID.

选择修改后的输入。对于步骤1中的每个示例值，选择一个合理的替代值，以覆盖相同的流程：

日期 → 同一或相邻月份的不同日期。
搜索词 → 语义不同但格式正确的内容（不同机场、不同产品类别、不同人名）。
ID → 另一个已知有效的ID。

目标是输入不同，意图相同。这样轨迹将遵循相同的概念路径，以便通过对比明确分离出参数。

使用修改后的输入在新的Steel会话中再次运行任务。使用相同的配置、相同的起始URL、相同的操作逻辑顺序。

如果轨迹#2与轨迹#1出现分歧——遇到轨迹#1未出现的登录墙、验证码，或进入结构不同的页面——请停止并调查。参考

references/steel-primitives.md

决定是否添加Steel会话选项（隐身模式、代理、验证码解决），或是否需要告知用户。不要掩盖分歧。

保存第二个会话ID。

Step 5 — Fetch both traces

步骤5 — 获取两个轨迹

bash

node scripts/fetch_trace.mjs <session-id-1>
node scripts/fetch_trace.mjs <session-id-2>

The script calls

steel --json sessions traces <session-id>

, writes the normalized trace JSON to a temp file, and prints the path. The trace has events with

accessibleName

, selectors, page URLs, value fields, and timestamps — see

references/trace-anatomy.md

for what to look at.

bash

node scripts/fetch_trace.mjs <session-id-1>
node scripts/fetch_trace.mjs <session-id-2>

该脚本调用

steel --json sessions traces <session-id>

，将标准化的轨迹JSON写入临时文件，并打印文件路径。轨迹包含带有

accessibleName

、选择器、页面URL、值字段和时间戳的事件——请查看

references/trace-anatomy.md

了解详细内容。

Step 6 — Author the generated skill

步骤6 — 编写生成的Skill

You now have two traces. Read them together. The differences at corresponding positions are the parameters; the similarities are the invariants.

Consult these references in order:

```
references/trace-anatomy.md
```
— how to read each event and how to align two traces.
```
references/steel-primitives.md
```
— the decision tree for credentials, profiles, stealth, proxy, and CAPTCHA. This determines how the generated skill creates its Steel session.
```
references/skill-template.md
```
— the scaffold to fill in.

The generated skill depends on the

steel-browser

skill at runtime — it does not embed CLI commands inline. Every generated skill must include a

## Prerequisites

section (the template shows the exact wording) that points the user at

curl -fsS https://setup.steel.dev | sh

, which installs the steel CLI and the steel-browser skill. The body steps then describe intent in plain prose, with element names in italics; the executor translates that into

snapshot → click → fill → wait

sequences using steel-browser's primitives.

Selector choice for the generated skill, in priority order:

Element text or accessibleName (most resilient — survives most DOM rewrites).
```
data-testid
```
if present.
```
id
```
if present and looks intentional.
```
aria-label
```
or
```
name
```
.
CSS selectors as a last resort, never
```
:nth-of-type
```
chains unless nothing else exists.

Use

target.selector

as evidence for available selectors, but prefer a readable semantic step when the accessible name is specific enough. For example, write "Click the Direct only checkbox" instead of exposing a raw selector.

Name parameters by what they mean, not what they are.

depart_date

, not

param_2

. The model that will later use the generated skill is reading these names cold; clarity matters.

Write the goal in the imperative ("Find the cheapest direct round-trip price for {origin} → {destination} between {depart} and {return}"). Write success criteria in terms of what gets returned, not what gets clicked.

现在你有两个轨迹。将它们对比阅读。对应位置的差异部分就是参数；相同部分则是不变量。

按顺序参考以下文档：

```
references/trace-anatomy.md
```
— 如何读取每个事件以及如何对齐两个轨迹。
```
references/steel-primitives.md
```
— 关于凭据、配置文件、隐身模式、代理和验证码的决策树。这将决定生成的Skill如何创建Steel会话。
```
references/skill-template.md
```
— 用于填充内容的模板。

生成的Skill在运行时依赖

steel-browser

Skill——它不会内联CLI命令。每个生成的Skill必须包含

## 前提条件

部分（模板中显示了确切的措辞），引导用户执行

curl -fsS https://setup.steel.dev | sh

，该命令会安装steel CLI和steel-browser Skill。主体步骤用普通散文描述意图，元素名称用斜体标注；执行器会使用steel-browser的原语将其转换为

snapshot → click → fill → wait

序列。

生成的Skill选择选择器的优先级顺序：

元素文本或accessibleName（最具弹性——能适应大多数DOM重写）。
如果存在
```
data-testid
```
。
如果存在且看起来是有意设置的
```
id
```
。
```
aria-label
```
或
```
name
```
。
CSS选择器作为最后手段，除非没有其他选择，否则绝不使用
```
:nth-of-type
```
链式选择器。

使用

target.selector

作为可用选择器的证据，但当accessible名称足够具体时，优先使用可读性强的语义化步骤。例如，写“点击仅直飞复选框”而非暴露原始选择器。

参数名称应基于其含义而非类型命名。例如使用

depart_date

，而非

param_2

。后续使用该生成Skill的模型会直接读取这些名称，因此清晰度至关重要。

目标说明使用祈使语气（例如“查找{origin} → {destination}在{depart}和{return}之间的最便宜直飞往返价格”）。成功标准应基于返回内容而非点击操作来描述。

Step 7 — Install the skill

步骤7 — 安装Skill

bash

node scripts/install_skill.mjs <skill-name> --skill-md <path-to-generated-SKILL.md>

The script writes to

~/.claude/skills/<skill-name>/

and tells you the final path. Generated skills go system-wide by default so the user can invoke them from any project.

bash

node scripts/install_skill.mjs <skill-name> --skill-md <path-to-generated-SKILL.md>

该脚本会将Skill写入

~/.claude/skills/<skill-name>/

并告知你最终路径。生成的Skill默认会安装到系统级别，以便用户可以从任何项目中调用它们。

Step 8 — Verify by running the new skill

步骤8 — 通过运行新Skill进行验证

Pick a third set of inputs — distinct from both step 1 (example inputs) and step 4 (mutated inputs). Invoke the freshly-installed skill against those inputs in a fresh Steel session. Capture the resulting session ID, fetch trace #3.

选择第三组输入——与步骤1（示例输入）和步骤4（修改后的输入）均不同。在新的Steel会话中调用刚安装的Skill，使用这些输入。捕获生成的会话ID，获取轨迹#3。

Step 9 — Judge fidelity

步骤9 — 判断保真度

Read

references/llm-judge-rubric.md

. With the three traces, the generated skill source, and the inputs/outputs you've gathered, form a verdict:

Did trace #3 reach the same kind of success signal as traces #1 and #2?
Did the third inputs substitute cleanly into URLs and form values?
Were extra steps (cookie banners, modals) handled or did they break things?
Were any steps skipped, and if so, did that matter?

Do not run a structural diff. Form a judgment.

If the verdict is good: tell the user the skill is installed, where, and show one example invocation with concrete inputs.

If the verdict is mixed: show the user the diagnosis in plain English and offer to revise — usually the fix is one of: a wait point in the wrong place, a selector that was too specific, a parameter that should have been split into two, or a Steel session option that was missed.

阅读

references/llm-judge-rubric.md

。结合三个轨迹、生成的Skill源代码以及你收集的输入/输出，形成结论：

轨迹#3是否达到了与轨迹#1和#2相同的成功信号？
第三组输入是否能顺利替换到URL和表单值中？
额外步骤（Cookie横幅、模态框）是否得到处理，还是导致流程中断？
是否有步骤被跳过，如果有，是否影响结果？

无需进行结构化对比，只需形成判断。

如果结论良好：告知用户Skill已安装、安装位置，并展示一个使用具体输入的调用示例。

如果结论一般：用简单的英文向用户展示诊断结果，并提出修改建议——通常的修复方案包括：等待点位置错误、选择器过于具体、参数应拆分为两个，或遗漏了某个Steel会话选项。

Decision points: when to ask the user vs. proceed

决策点：何时询问用户 vs. 直接执行

Ask the user when:

The task description is vague enough that you'd have to invent the inputs (step 1).
The task has side effects you can't safely replay twice (step 2).
The first run hits a login flow on a site Steel credentials are not configured for. You need consent before storing credentials in the vault.
The replay in step 4 hits a CAPTCHA on a site the user is not on a paid Steel plan for, or a geo-block requiring a region they haven't authorized.
You cannot tell from the two traces whether something was a deliberate parameter or accidental noise (e.g., did the user scroll to position 437px on purpose, or was that incidental?).

Proceed without asking when:

Selector choice — use your judgment from the priority list.
Parameter naming — propose names, the user will rename them later if they want.
Wait point placement — idle gaps + page transitions are reliable signals.
Mutated input choice in step 4 — pick something reasonable and move on.
Whether to enable stealth/proxy/CAPTCHA on the generated skill — the decision tree in
```
references/steel-primitives.md
```
is unambiguous.

在以下情况下询问用户：

任务描述过于模糊，你不得不自行编造输入（步骤1）。
任务存在无法安全重复执行的副作用（步骤2）。
首次运行遇到Steel凭据未配置的登录流程。你需要获得用户同意后才能将凭据存储到密钥库中。
步骤4中的重放遇到验证码，而用户未订阅Steel付费计划；或遇到地理限制，需要用户未授权的地区代理。
你无法从两个轨迹判断某内容是故意设置的参数还是意外噪声（例如，用户是有意滚动到437px位置，还是偶然操作？）。

在以下情况下无需询问直接执行：

选择器选择——根据优先级列表运用你的判断。
参数命名——提出名称，用户之后可自行修改。
等待点位置——空闲间隔+页面跳转是可靠的信号。
步骤4中修改后的输入选择——选择合理的值继续执行。
是否在生成的Skill中启用隐身模式/代理/验证码——
```
references/steel-primitives.md
```
中的决策树已明确说明。

What to avoid

注意事项

Do not regex over trace JSON looking for parameters. Read the traces; reason about them. Two-trace diff is a mental operation, not a string-comparison operation.
Do not include trace IDs, session IDs, or timestamps in the generated skill. Those are artifacts of this compilation; they don't belong in the reusable skill.
Do not write a hundred-line SKILL.md. Generated skills should be lean — 40–80 lines of body. The Steel trace is the source code; the SKILL.md is the abstract.
Do not invent steps that weren't in either trace. If neither recording included "dismiss the cookie banner", the generated skill shouldn't pretend it did. If a banner shows up later in production, the verification pass will catch it.
Do not run a side-effect flow twice without user consent. This bears repeating.

不要通过正则表达式遍历轨迹JSON来查找参数。请阅读轨迹并进行推理。双轨迹对比是一种思维操作，而非字符串比较操作。
不要在生成的Skill中包含轨迹ID、会话ID或时间戳。这些是本次编译的产物，不属于可复用的Skill。
不要编写百行以上的SKILL.md。生成的Skill应简洁——主体部分40-80行即可。Steel轨迹是源代码；SKILL.md是抽象说明。
不要添加任何未在任一轨迹中出现的步骤。如果两次录制都未包含“关闭Cookie横幅”，生成的Skill不应假装有此步骤。如果生产环境中出现横幅，验证环节会发现问题。
不要在未获得用户同意的情况下运行有副作用的流程两次。这点需要再次强调。

Output

输出结果

A successful run leaves the user with:

A new skill at
```
~/.claude/skills/<skill-name>/
```
.
An example invocation they can copy-paste.
A short note on any caveats (e.g., "requires Steel credentials for foo.com to be configured; run
```
steel credentials create --origin https://foo.com
```
once before first use").
A one-line fidelity verdict from the verification pass.

成功执行后，用户将获得：

新Skill存储在
```
~/.claude/skills/<skill-name>/
```
。
一个可复制粘贴的调用示例。
关于注意事项的简短说明（例如“需要配置foo.com的Steel凭据；首次使用前请运行
```
steel credentials create --origin https://foo.com
```
”）。
验证环节给出的一行保真度结论。