gstack skill 迁移现状：先分清入口、Adapter 和 Workflow

一句话：先说事实，不先下判断。gstack 当前在不同 runtime 上的状态不一样：OpenClaw 目前真正做成 native conversational skills 的是四个；Hermes host adapter 可以生成一整套 gstack skill entries；Codex 理论上接近 Claude Code 这类 repo coding harness，但本文不应把它写成已经实际完成、验证过的迁移目标。

当前事实

这件事是在一个很小的问题里露出来的：为什么一次 OpenClaw / gstack 接入里，看起来只有四个 OpenClaw native gstack skills？gstack 不是有 /qa、/review、/ship、/autoplan、/cso 等一整套工程技能吗？

答案不是“漏装了”，而是要区分 native skill migration、host adapter 生成入口、runtime asset 安装 和 production workflow 可执行性。

runtime	gstack 当前可确认状态	不能误读成
Claude Code	gstack 重工程 workflow 的原生宿主。`/review`、`/qa`、`/ship` 等技能按 Claude Code 的 repo 工位、工具和 session 语义设计。	不能推出其他 runtime 复制文件后就等价。
OpenClaw	gstack 为 OpenClaw 准备的 native conversational skills 目前是四个：office hours、CEO review、investigate、retro。	不能说 OpenClaw 已经 native 迁移了所有 gstack workflow。
Hermes	gstack 有 Hermes host adapter；当前 checkout 里生成了 54 个 `.hermes/skills/gstack-*` entries，并把路径/工具语义改写到 Hermes 语境。	不能把“entry 能出现”直接等同于“每个重 workflow 都 production-ready”。
Codex	Codex 在形态上接近 Claude Code，因为它也是 repo coding harness；理论上是可迁移方向。当前这篇文章不应声称 Codex 已经有可用 adapter / worker，或已经完成生产验收。	不能把理论相邻写成已经实际迁移完成。

四个层级

很多误会来自把四件事混成一件事。

第一层：native conversational skill。
这是 OpenClaw 里目前最清楚的层级。gstack 的 OpenClaw native skills 是 office hours、CEO review、investigate、retro。它们更像方法论：围绕想法、计划、根因、复盘组织对话。

第二层：host adapter 生成入口。
这是 Hermes 的重点。Hermes adapter 可以把 gstack skills 生成成 Hermes skill entries，例如 gstack-review、gstack-qa、gstack-ship 等，并把 Claude Code 语境里的路径和工具名改写到 Hermes 语境，比如 Hermes skills 目录、AGENTS.md、terminal、read_file、patch、delegate_task。

第三层：runtime asset。
入口出现以后，还要有共享 runtime root、bin、browse、design、浏览器运行时、bun 等资产。没有这些，skill 可以被选中，但 workflow 会在执行时断掉。

第四层：production workflow。
/qa、/review、/ship 不只是 prompt。它们会读 repo、看 diff、跑 shell、打开浏览器、改文件、生成测试证据、处理 git / PR。这个层级需要权限、工作目录、审批、证据回填和失败处理契约。

OpenClaw：四个 native skills

OpenClaw 这里最重要的事实是：native conversational skills 目前是四个。

gstack-openclaw-office-hours
gstack-openclaw-ceo-review
gstack-openclaw-investigate
gstack-openclaw-retro

这四个以对话、判断、计划审查、根因分析、复盘为核心，不要求一上来就进入 repo 工位执行 /ship。

这并不是说 OpenClaw 永远不能接 gstack workflow；只是说当前事实不是“OpenClaw 已经迁移了全部 gstack skills”。如果 OpenClaw 要承接 /review、/qa、/ship，需要另外定义入口、repo scope、执行 worker、权限审批和结果回填。

Hermes：入口层面可以迁移整套 gstack

Hermes 这里最重要的事实是：Hermes 不止能看到四个。

gstack 的 Hermes host adapter 可以生成一整套 Hermes skill entries。当前 checkout 里 .hermes/skills 下有 54 个 gstack-* 目录。Hermes Discord 侧也可以通过一个 /skill command 加 name autocomplete 暴露 skill catalog，而不是把几十个技能都塞进顶层 slash command。

用户看到的形态类似：

/skill
  name: review — Pre-landing PR review...
  args: <optional instruction>

所以从 入口迁移 来说，Hermes 的事实是“可以迁移很多，甚至近似整套 gstack skill catalog”。但从 重 workflow 执行 来说，还要继续检查 runtime asset、浏览器、repo 权限、approval、GitHub 权限和 evidence contract。

Codex：理论上可迁移，但不能写成已完成

Codex 的基本事实要更保守。

Codex 和 Claude Code 都属于 repo coding harness 这一类：它们都围绕 repo、文件读写、patch、terminal、测试、diff、git 状态和任务闭环工作。因此从模型上说，gstack 的重工程 workflow 理论上 比迁到 OpenClaw native conversational skill 更容易迁到 Codex。

但这篇文章不应该把 Codex 写成已经实际完成迁移。至少要区分：

有没有可用 adapter / 安装入口，而不只是理论上可以改写；
adapter 有没有被发布/安装到目标 Codex runtime；
目标 Codex runtime 里能不能发现 skill；
/review、/qa-only、/qa、/ship 是否实际跑通；
被 suppress 的 Codex second opinion / plan review / review army 是否有替代审查边界。

在这些验收完成前，Codex 只能写成：理论上可迁移、值得验证，但当前没有已确认可用的 adapter / worker 生产事实。

Claude Code：原生宿主事实

Claude Code 的事实也不要写成价值判断。更准确地说：gstack 的很多重 workflow 原本就是围绕 Claude Code 的工具和 session 语义写的。

例如：

/review 假设可以检查 diff、调用审查视角、输出 findings；
/qa 假设可以跑浏览器用户流、修 bug、验证回归；
/ship 假设可以处理 git 状态、测试、changelog、push、PR；
/autoplan 假设可以组织多视角计划审查。

这解释的是来源关系，不是“Claude Code 永远最好”的结论。

不要 port command，要 port contract

如果要让 /qa、/review、/ship 跨 runtime 变得真正可移植，我们需要定义的不是“所有地方都叫 /qa”，而是类似这样的 contract：

Task: review
Input:
  repo: <path or repo handle>
  base: <branch or commit>
  scope: <diff / files / PR>
Permission:
  read: allowed
  write: optional
  network: optional
  publish: requires approval
Evidence:
  findings: structured list
  commands_run: sanitized
  files_changed: list
  residual_risk: text
Output:
  markdown_summary
  machine_readable_result
  memory_or_session_backfill

Claude Code、Hermes、OpenClaw、Codex 都可以围绕这个 contract 做不同实现。但正文里应该先写已经确认的状态：OpenClaw 目前是四个 native conversational skills；Hermes 可以迁移 entry catalog；Codex 是理论迁移方向但不能写成已经完成；Claude Code 是 gstack 重 workflow 的原生来源宿主。

这样 migration 的对象就从“某个宿主的命令”变成了“跨宿主可理解的能力”。

这个观察为什么重要

今天很多人讨论 agent skills，会下意识把它们当成 prompt library。于是问题变成：哪个目录格式更标准？frontmatter 该怎么写？触发描述该怎么优化？

这些当然重要，但它们只是外壳。

更深的问题是：一个 skill 到底依赖了多少宿主能力？它是否声明了自己的 runtime assumptions？它的产物能否被别的 runtime 接收？它失败时证据在哪里？它是否知道自己是在短任务、长期 agent、gateway event、cron job 还是 repo session 里运行？

如果这些问题不回答，skill ecosystem 会变成一堆看起来相似、实则不可互操作的 Markdown 包。

如果这些问题回答清楚，skill 才可能变成 agent runtime 之间的协作协议。

一个判断标准

以后看到一个 skill，可以先问七个问题：

它的核心价值是思考方法，还是执行环境？
它需要哪些工具语义，而不仅是哪些工具名字？
它对 session 生命周期有什么假设？
它的产物应该被谁保存、审计、回填？
如果换一个 runtime，应该直接 native 化，还是 wrapper 调用，还是重写为 contract？
它只是需要一个入口，还是需要一个能承担风险的 execution worker？
如果迁到 Codex/Hermes/OpenClaw，哪些原本的外部审查、approval gate、证据回填会消失或改变？

这些问题比“能不能复制 SKILL.md”更接近真实工程判断。

结尾

Skill portability 的关键，不是把每个 slash command 都映射到每个 agent runtime。

这篇文章要先留下四个事实：OpenClaw 当前 native 迁移是四个；Hermes 入口层面可以迁移很多；Codex 理论上可迁移但不能写成已完成；Claude Code 是 gstack 重 workflow 的原生来源宿主。

后续的观点都应该作为 seed 生长，而不是抢在事实前面。