skillify

其他 社区 v1.0.0
解读按原文结构重写,命令、链接、术语均保留;右侧可核对作者原始 SKILL.md

skillify 把 /scrape 跑出来的临时抓取沉淀为可复用 browser-skill——它有一份铁律合同:绝不把半成品 skill 写到磁盘。要么测试通过完整落地,要么 staged dir 直接丢弃。

设计思路

作者把 skill 化拆成 9 步,每一步都有 D 编号(决策点)。staged write 是核心机制——所有产物先写到一个 staged 目录,跑测试通过、用户审批通过,才用原子 rename 移到 ~/.gstack/browser-skills/,半路任意失败都靠 discardStaged 回滚。这样保证「我不会因为 skill 写到一半就让磁盘变脏」。

工作流

Iron contract — 永不把半成品 skill 写到磁盘;② Step 1 Provenance guard — 来源是不是合法的 /scrape 原型?;③ Step 2 提议 name + triggers——给 triggers: / description: / host: 起字段;④ Step 3 合成 script.ts(D2);⑤ Step 4 抓 fixture——把页面快照存下来当离线测试源;⑥ Step 5 写 script.test.ts——bun test 直接跑;⑦ Step 6 解析 canonical SDK path 并 read;⑧ Step 7 stageSkill 原子写入 staged dir,回 stagedDir 给后续;⑨ Step 8 $B skill test "<name>" --dir "<stagedDir>"(不支持 --dir 就 fallback cd "<stagedDir>" && bun test script.test.ts),失败可读输出修最多 2 次,再失败或环境问题就 discardStaged 并停下;⑩ Step 9 Approval gate D 询问用户是否真要 commit 到 <resolved-tier-path>

Approval gate 的用语

作者把这一步的 AskUserQuestion 写得非常细:明确告诉用户 yes 会做什么、no 会做什么、若选错的代价是多少(yes 会留个手动 $B skill rm <name> --global 才能删的 artifact;no 丢掉 ~30s 合成)、并给出 recommendation。

适合的场景

  • 同一类抓取要重复做:先用 /scrape 试通,再用 /skillify 沉淀
  • 团队希望把抓取脚本变成「可被 /scrape 自动命中」的资产
  • 有相对稳定的 fixture 网页(结构变化少)

不适合

  • 一次性、低频抓取:直接保留 /scrape 原型即可
  • 抓取结果对参数依赖很强且参数难定义为 args::先继续用 scrape 原型

配套

scrape(原型来源)、webapp-testing(同样基于 $B 但偏 QA)、setup-browser-cookies(要登录态时先跑)、write-a-skill / writing-skills(写 SKILL.md 的语调)。

流狐档案 作者与许可取自来源;运行、权限和网络为流狐检测或估算
流狐分类
通用
作者声明 Agent
未找到明确声明;不据此推断已兼容或已测试
静态检查
88 / 100 · 启发式扫描,不代表运行安全
作者 / 版本 / 许可
@garrytan · v1.0.0 · 未声明 license
流狐 Token 估算
较高消耗
流狐接入估算
需手动接入
是否需要外部 API Key
未发现要求
检测到的系统要求
macOS · Linux · Windows
底层运行要求
Node.js · Bun
检测到的文件与系统行为
  • 只读
  • 允许写入 / 修改
  • Shell 执行
检测到的网络行为
允许外网请求
安装命令数
无(仅作为资料)

档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。

需要注意: 未限定 allowed-tools,默认拥有全部工具权限。

输出预览 skillify.preview
# Writing Style (skip entirely if EXPLAINLEVEL: terse appears in the preamble echo OR the user's current message explicitly requests terse / no-explanations output)

- Gloss curated jargon on first use per skill invocation, even if the user pasted the term.
- Frame questions in outcome terms: what pain is avoided, what capability unlocks, what user experience changes.
- Use short sentences, concrete nouns, active voice.
- Close decisions with user impact: what the user sees, waits for, loses, or gains.
- User-turn override wins: if the current message asks for terse / no explanations / just the answer, skip this section.
- Terse mode (EXPLAIN_LEVEL: terse): no glosses, no outcome-framing layer, shorter responses.

讨论

基于 GitHub Discussions。登录 GitHub 即可参与讨论、点赞、订阅更新。