AI 编程 Agent 工作流项目调研：Superpowers、OpenSpec、Spec Kit、gstack 与 OMC

最近 GitHub 上出现了一批“增强 Claude Code / Codex / AI 编程助手”的项目：有的叫 skills framework，有的叫 spec-driven development，有的叫 team orchestration，有的包装成一套“虚拟工程团队”。它们看起来都在解决同一个问题：单个 coding agent 很容易直接开写、上下文漂移、缺少验收闭环，复杂任务越做越散。

但把源码拉下来完整看一遍后，会发现它们不是同一种东西。

我的判断是：

这类项目的本质不是“更好的 prompt 包”，而是在给 AI Coding Agent 补一层工程 harness：把需求澄清、规格约束、任务拆解、并行执行、验证修复、记忆学习和工具治理，从一次性聊天里抽出来，变成可复用的外部工作流。

本文调研的五个项目是：

• obra/superpowers：方法论优先的 agentic skills framework。
• Fission-AI/OpenSpec：面向 AI coding assistant 的轻量 Spec-Driven Development 框架。
• github/spec-kit：GitHub 官方的 Spec-Driven Development toolkit。
• garrytan/gstack：Garry Tan 风格的 Claude Code 产品团队工具栈。
• Yeachan-Heo/oh-my-claudecode：面向 Claude Code 的 team-first multi-agent orchestration。

本文基于 2026-05-25 的 GitHub 状态和本地源码快照。因为这些项目更新很快，后续 stars、目录和实现细节可能变化，下面的 commit 用作本文分析基线。

01 先给结论：它们分成三类

图 1：五个项目不是同一个赛道。Superpowers 更像方法论内核，OpenSpec/Spec Kit 更像规格驱动层，gstack/OMC 更接近运行时和团队编排。

这五个项目可以按两个维度理解：

• 规格约束强不强：是否要求先写 spec、plan、tasks、constitution、change proposal。
• 执行编排重不重：是否自己管理 worker、tmux、浏览器、健康检查、自动提交、重试和验证循环。

按这个维度拆开，大致是三类：

最容易误判的是 gstack。它 README 里强调 “23 opinionated tools”，像一个技能包；但源码里实际有 52 个 SKILL.md，还有 browse 浏览器运行时、CDP allowlist、安全锁、host-config 生成系统、团队模式和 GBrain 上下文查询。它已经不只是 prompt pack，而是偏“产品团队操作系统”。

另一个容易误判的是 OMC。它看起来像 Claude Code 的 slash command 增强包，但 src/team 里已经有比较完整的 runtime：worker allocation、heartbeat、restart、commit cadence、tmux session、worktree、merge orchestrator、event-driven monitor。它的重点不是“让 Claude 多几个命令”，而是让 Claude Code 变成可治理的多 Agent 团队。

02 Superpowers：方法论优先，强制 Agent 先使用技能

Superpowers 的定位最清楚：它不是要替代 Claude Code、Codex 或 Cursor，而是给这些宿主 Agent 安装一套软件开发方法论。

README 里直接写明：Superpowers 是 “complete software development methodology for your coding agents”，由一组 composable skills 和初始指令组成。它支持 Claude Code、Codex CLI/App、Factory Droid、Gemini CLI、OpenCode、Cursor、GitHub Copilot CLI 等宿主。

2.1 目录结构：核心几乎都在 skills 和 hooks

Superpowers 的源码很轻，主要目录是：

当前版本 5.1.0 的 .claude-plugin/plugin.json 把它描述成 “Core skills library for Claude Code: TDD, debugging, collaboration patterns, and proven techniques”。

它的技能数不多，但覆盖的是工程流程骨架：

2.2 核心机制：不是“建议使用技能”，而是“默认必须先找技能”

Superpowers 最关键的实现不在某个复杂 runtime，而在 hooks/session-start 和 skills/using-superpowers/SKILL.md。

hooks/session-start 会在会话开始时把 using-superpowers 的完整内容注入宿主上下文。这个 hook 会输出 Claude/Cursor/Copilot 兼容的 JSON context，让 Agent 一开始就知道：接下来做任务时要先检查 skill。

using-superpowers 里的规则非常强硬：只要有 1% 的概率某个技能适用，就要在任何回复或行动前先调用技能。它还规定了优先级：用户指令最高，process skills 优先于 execution skills，不能把技能当作参考资料扫一眼就算执行。

这类设计的优点是明显的：

• Agent 不容易绕过流程直接开写。
• TDD、计划、评审、验证这些“慢动作”被制度化。
• 它不绑定具体模型，也不绑定具体 IDE。

缺点也同样明确：

• 它基本不管理运行时状态，复杂并行任务仍然依赖宿主能力。
• 技能触发质量高度依赖模型是否真的遵守 injected instruction。
• 对大型团队协作、worker health、自动恢复等问题覆盖有限。

2.3 TDD 和 subagent 是 Superpowers 的两个硬约束

test-driven-development/SKILL.md 的规则非常明确：没有失败测试，不写生产代码。流程是 RED、GREEN、REFACTOR，并且要求先看到测试失败，避免写“事后补测试”。

subagent-driven-development/SKILL.md 则把复杂任务拆给子 Agent：每个任务用 fresh subagent，隔离上下文，完成后要经过两阶段评审：先验收是否符合 spec，再评审代码质量。这个设计很实用，因为主 Agent 的上下文经常被计划、讨论和实现细节污染，子 Agent 可以降低上下文串味。

Superpowers 的本质可以概括成一句话：

它不试图拥有执行器，而是改造执行器的工作习惯。

如果你已经在用 Claude Code / Codex，并且最大问题是 Agent 太冲动、不会先写计划、不坚持测试，那 Superpowers 是最轻的增强层。

03 OpenSpec：轻量 SDD，把变更变成 artifact graph

OpenSpec 和 Spec Kit 都属于 Spec-Driven Development，但气质不同。

OpenSpec 更强调 “fluid not rigid”，适合棕地项目、渐进式改造和 AI coding assistant 的日常工作流。它不是强迫你一开始就建立一个完整规格体系，而是让你围绕一次 change proposal 建立可追踪的 artifacts。

3.1 CLI 和 profile：通过命令生成适配不同宿主

OpenSpec 是一个 TypeScript CLI，npm 包名是 @fission-ai/openspec，要求 Node >=20.19.0。入口在 src/cli/index.ts，用 Commander 定义命令：

src/core/init.ts 是初始化核心。它做几件事：

1. 校验项目目录。
2. 清理或迁移旧版结构。
3. 检测当前可用的 AI coding tools。
4. 创建 OpenSpec 目录和配置。
5. 根据 profile 生成对应工作流命令。

Profile 定义在 src/core/profiles.ts：

• core profile 默认安装 propose、explore、apply、sync、archive。
• custom profile 可以选择自定义 workflows。
• 全量 workflows 还包括 new、continue、ff、bulk-archive、verify、onboard。

这说明 OpenSpec 的设计不是把所有命令一股脑塞给用户，而是通过 profile 控制复杂度。

3.2 command-generation：同一套工作流，多宿主落地

OpenSpec 的一个关键模块是 src/core/command-generation/generator.ts。它把“工作流内容”和“宿主落地格式”拆开：

• 核心层生成 tool-agnostic command content。
• adapter 层把内容转成 Claude Code、Codex、Cursor 等宿主能识别的命令文件。

这和 Superpowers 的多插件目录类似，但 OpenSpec 更偏生成系统：同一套 workflow 可以被渲染到不同 agent 工具里。

3.3 ArtifactGraph：OpenSpec 的规格不是散文，而是依赖图

OpenSpec 最值得关注的是 src/core/artifact-graph/graph.ts。这里的 ArtifactGraph 把规格工作流抽象成 artifact dependency graph。

它提供几个核心能力：

这点很关键。很多所谓 spec 工具只是把需求写成 Markdown，OpenSpec 则把“文档产物之间的依赖关系”建模出来。这样 Agent 不只是读一堆文档，而是可以知道下一步该产出什么，哪些内容还不能开始。

3.4 OpenSpec 的适用场景

OpenSpec 的优势：

• 比 Spec Kit 轻，适合现有项目渐进接入。
• TypeScript CLI 更贴近前端/Node 项目生态。
• Artifact graph 让变更推进顺序更清楚。
• Profile 和 adapter 让多工具接入比较自然。

它的边界：

• 它主要治理规格和变更流程，不负责 worker runtime。
• 不像 OMC 那样处理 tmux worker、健康检查、自动重启。
• 对工程质量的强制性低于 Spec Kit 和 Superpowers 的 TDD 规则。

一句话总结：

OpenSpec 是轻量 SDD 中间层：用最少的约束，把一次 AI 辅助变更从“聊天记录”升级成“可追踪 artifact graph”。

04 Spec Kit：GitHub 官方 SDD，阶段更硬，扩展体系更完整

Spec Kit 是 GitHub 官方推出的 SDD toolkit。它和 OpenSpec 的目标相似，但实现更偏“标准工作区 + 阶段命令 + 模板系统 + 扩展系统”。

4.1 Python CLI：把 .specify 变成项目内规格工作区

Spec Kit 的 Python 包是 specify-cli，要求 Python >=3.11。pyproject.toml 里可以看到它依赖 Typer、Click、Rich、PyYAML、platformdirs、pathspec、json5 等库，并把 templates、commands、scripts、extensions、workflows、presets 都打进 wheel。

入口在 src/specify_cli/__init__.py。它用 Typer 定义 CLI，默认 integration 是 Copilot，但通过 integration registry 支持多种 AI coding agent。

典型使用方式是：

1. specify init 初始化项目。
2. /speckit.constitution 写项目原则。
3. /speckit.specify 写功能规格。
4. /speckit.plan 生成技术计划。
5. /speckit.tasks 拆任务。
6. /speckit.implement 执行。

这一套比 OpenSpec 更像“严格流水线”。它要求用户先把项目原则和规格定下来，再让 Agent 实现。

4.2 模板命令：把 SDD 阶段固定成可调用动作

templates/commands/ 里核心命令包括：

Spec Kit 的设计思路很直接：把高质量软件开发过程的每个阶段变成 command template，让不同 Agent 工具都能调用。

4.3 Agent integration：不是复制 Markdown，而是按宿主生成命令

src/specify_cli/agents.py 里有 CommandRegistrar，负责把模板注册成不同宿主识别的命令文件。它支持 Markdown、TOML、YAML recipe renderer，并会把 repo-relative path 改写到 .specify/...。

Claude integration 在 src/specify_cli/integrations/claude/__init__.py。它会把命令安装成 .claude/skills 下的技能，并生成 speckit-* skill name，同时注入 frontmatter，比如 user-invocable、disable-model-invocation: false、argument hints 等。

这说明 Spec Kit 的重点不是“一个 CLI 自己执行所有事情”，而是把规格工作流投递给用户已有的 AI coding agent。

4.4 Workflow engine 和 extension manager：Spec Kit 的可扩展性比看起来更强

Spec Kit 不只有模板命令。src/specify_cli/workflows/engine.py 实现了一个 workflow YAML engine，负责：

• 解析 workflow YAML。
• 校验 step、input、schema version。
• 顺序执行 step。
• 管理 state persistence，支持 resume。
• 支持 branching、loops、fan-out/fan-in 这类控制流。

src/specify_cli/extensions.py 则实现 extension manager。Extension manifest 要有 schema_version、extension、requires、provides，命令名要求符合 speckit.{extension}.{command}。它还会校验 semver、兼容性、commands/hooks、别名和冲突。

这两个模块说明 Spec Kit 正在从“官方 SDD 模板”向“可扩展 SDD 平台”演进。

4.5 Spec Kit 的适用场景

Spec Kit 的优势：

• 官方项目，方向和概念更稳定。
• 阶段门清晰，适合团队统一流程。
• .specify 工作区天然适合长期维护规格。
• extensions、presets、workflow engine 给后续扩展留了空间。

它的边界：

• 对个人快速迭代来说偏重。
• 初始化后需要用户愿意维护 constitution/spec/plan/tasks。
• 它不解决多 worker 执行治理问题，还是依赖 Claude/Copilot/Codex 等宿主执行。

一句话总结：

Spec Kit 是更“制度化”的 SDD：它把需求、原则、计划、任务和实现阶段固定下来，牺牲一部分灵活性，换取可追踪和可协作。

05 gstack：不只是技能包，而是一个产品团队工作台

gstack 的 README 很有辨识度：它说自己是 Garry Tan 的 Claude Code setup，包含 CEO、Designer、Engineering Manager、Release Manager、Doc Engineer、QA 等角色。表面看，它像一个很 opinionated 的 prompt/skill collection。

但源码里实际比这个重很多。

5.1 技能规模：从产品判断到发布闭环

当前仓库里有 52 个 SKILL.md，包括：

office-hours/SKILL.md 是一个典型例子。它不是简单说“帮用户头脑风暴”，而是要求用 YC Office Hours 的 forcing questions 判断需求现实、状态 quo、窄 wedge、未来适配，并把结果保存成 design doc。它还会查询 gbrain 的历史上下文，例如 prior sessions、builder profile、design doc history、eureka moments。

这说明 gstack 的 skills 不是孤立提示词，而是带上下文检索、配置、遥测、升级提示和项目学习记录的操作流程。

5.2 setup 和 host-config：跨宿主生成，不是手工拷贝

setup 是 Bash 脚本，支持 --host、--local、--prefix/--no-prefix、--team 等参数。它支持的宿主包括 Claude、Codex、Kiro、Factory、OpenCode、OpenClaw、Hermes、GBrain 等。

更关键的是 scripts/host-config.ts。它定义了 declarative HostConfig，描述不同宿主要怎么处理：

• frontmatter transformation。
• skill 文档生成。
• path rewrite。
• runtime root symlink/file。
• install linking strategy。
• safety validation。

也就是说，gstack 不是为 Claude Code 写死一套 Markdown，而是维护一套中间表示，再按宿主生成目标文件。

scripts/skill-check.ts 则做质量保障：检查所有 SKILL.md 命令、模板覆盖率、生成文件是否过期，并用 bun run scripts/gen-skill-docs.ts --dry-run 校验生成结果。这是典型的“提示词资产工程化”。

5.3 browse runtime：gstack 真正变重的地方

gstack 的 browse/ 目录非常值得看。它不是简单调用 Playwright，而是做了一套浏览器工具运行时，包括：

• browser manager。
• CDP bridge。
• cookie import。
• network capture。
• security sidecar。
• path security。
• stealth。
• token registry。
• terminal-agent-control。

browse/src/cdp-bridge.ts 的设计很典型：$B cdp <Domain.method> 通过 Playwright 的 newCDPSession() 发送 CDP 调用，但默认 deny。只有 cdp-allowlist.ts 里列出的 method 才允许，并且每个 method 带 scope 和 output 标记。

它还做了两层锁：

• tab-scoped method 获取 per-tab mutex。
• browser-scoped method 获取 global lock，阻塞所有 tab mutex。

并设置 5 秒 acquire timeout 和 CDP call timeout，避免 Agent 把浏览器 runtime 卡死。

这说明 gstack 对“工具调用安全性”和“并发可控性”的要求很高。它已经不是 prompt pack，而是在给 Agent 提供受控工具环境。

5.4 gstack 的适用场景

gstack 的优势：

• 覆盖产品、设计、工程、QA、文档、发布全流程。
• 技能质量有生成和校验体系。
• 浏览器 runtime 很实用，尤其适合前端、网页 QA、资料抓取。
• 对多宿主适配投入很深。

它的边界：

• opinionated 很强，不一定适合所有团队风格。
• 功能面大，学习和维护成本比 Superpowers 高。
• 多数技能仍依赖宿主 Agent 遵守流程；真正的 team runtime 不如 OMC 那么集中。

一句话总结：

gstack 是“产品团队化”的 Agent 工作台：它不只教 Agent 怎么写代码，还试图让 Agent 像一个完整创业公司团队那样思考、设计、验证和发布。

06 oh-my-claudecode：从命令增强走向 Team Runtime

oh-my-claudecode，简称 OMC，README 里说得很直接：Teams-first Multi-agent orchestration for Claude Code。

它不是单纯做几个 slash commands。源码里已经有 CLI、agents、skills、commands、team runtime、worker health、restart、auto-commit、tmux session、worktree、merge orchestrator 等模块。

6.1 资源结构：agents、skills、commands 三层

当前 OMC 的规模大致是：

CLI 入口在 src/cli/index.ts，用 Commander 实现 omc。默认模式会通过 tmux 启动 Claude Code；其他命令包括 launch、interop、ask、config、setup、team、wait、doctor-*、session-search、ultragoal、teleport 等。

6.2 team skill：五阶段流水线

skills/team/SKILL.md 是理解 OMC 的核心。它定义了 canonical team runtime：

team-plan -> team-prd -> team-exec -> team-verify -> team-fix

每个阶段都有默认 agent routing：

它还定义了 handoff convention：每个阶段结束前必须写 .omc/handoffs/<stage-name>.md，记录 decisions、rejected alternatives、risks、files、remaining。这样即使上下文压缩或 worker 重启，下一阶段也能读到关键决策。

这比普通“派几个子 Agent 干活”成熟很多。它处理的是多阶段、多角色、多轮验证中的上下文传递问题。

6.3 runtime-v2：事件驱动团队运行时

src/team/runtime-v2.ts 明确写着：它替代 polling watchdog，不再依赖 done.json 轮询。完成状态来自：

• CLI API lifecycle transitions。
• event-driven monitor snapshots。
• worker heartbeat/status files。

它保留 sentinel gate、circuit breaker、failure sidecars，并把 startTeam、monitorTeam、shutdownTeam、assignTask、resumeTeam 做成离散操作。

模块依赖也能看出 OMC 的工程重心：

• tmux-session.ts：创建 team session、spawn worker、pane liveness。
• monitor.ts：读 worker status、heartbeat、snapshot、shutdown ack。
• allocation-policy.ts：任务分配策略。
• worker-commit-cadence.ts：自动提交节奏。
• worker-health.ts：综合 heartbeat、tmux alive、audit log、task stats。
• worker-restart.ts：重启退避和最大重启次数。
• git-worktree.ts：worker 隔离 worktree。
• merge-orchestrator.ts：合并协调。

6.4 allocation policy：不是随机分配任务

src/team/allocation-policy.ts 负责把任务分配给 worker。逻辑不复杂，但很实用：

• 如果所有 worker 是同一角色，则按当前 load 做 least-loaded 分配，避免 worker-1 被塞满。
• 如果 worker 角色混合，则按 role match + load penalty 打分。
• exact role match 加分，无 role hint 时给中性分，当前 load 越高扣分越多。

这说明 OMC 的团队编排不是“开 N 个终端各自跑”，而是有明确的任务调度策略。

6.5 self-improve：OMC 的进化能力

OMC 还有一个 self-improve skill，设计目标是 autonomous evolutionary code improvement engine。

它的状态目录是 .omc/self-improve/topics/{topic_slug}/，包含：

它的 loop 很像小型进化系统：

1. 设定 goal、benchmark、harness。
2. research agent 生成研究 brief。
3. 多个 planner 并行提出 hypothesis plan。
4. architect 和 critic 审查计划。
5. 多个 executor 在 experiment worktree 里实现方案。
6. 运行 benchmark。
7. tournament selection 选择赢家。
8. git-master 合并赢家，归档输家。
9. 根据 plateau、target、circuit breaker 停止。

它还强调 sealed files：benchmark 代码不能被 loop 修改，防止 Agent 通过篡改评测来“变好”。这就是 harness engineering 的典型思路：能力提升不是靠模型自嗨，而是靠外部 benchmark、guardrail、worktree、history 和 tournament 形成闭环。

6.6 OMC 的适用场景

OMC 的优势：

• 真正把 Claude Code 多 Agent 团队化。
• 有 worker health、restart、commit cadence、handoff、verify/fix loop。
• self-improve 把 benchmark 和 tournament 引入 Agent 自改进。
• 对大型任务、并行任务、长时间任务更有价值。

它的边界：

• 复杂度最高，调试成本也最高。
• tmux、Claude Code、worker 状态文件等依赖让环境更重。
• 如果只是日常小改动，用 OMC 可能过度。

一句话总结：

OMC 是这几个项目里最接近“多 Agent 工程运行时”的项目，它解决的不是提示词质量，而是团队编排、状态治理和执行闭环。

07 横向架构对比

图 2：五个项目的架构分层。Superpowers 最轻，OpenSpec/Spec Kit 主要治理规格层，gstack 和 OMC 已经明显进入运行时和工具治理。

08 工作流对比：三种范式

图 3：三种主流范式：方法论技能流、规格驱动流、团队编排流。它们可以组合，但不要混成一个概念。

8.1 方法论技能流

代表：Superpowers、gstack。

主线是：

1. 用户提出任务。
2. Agent 先匹配 skill。
3. skill 强制进入 brainstorming / planning / TDD / review / QA。
4. 完成前必须验证。

这种模式最适合改造 Agent 的行为习惯。它轻、通用、容易安装，但对执行状态的掌控弱。

8.2 规格驱动流

代表：OpenSpec、Spec Kit。

主线是：

1. 先写需求、原则或变更提案。
2. 再生成规格和技术计划。
3. 再拆任务。
4. 实现后 archive / sync / analyze。

这种模式最适合“需求和实现必须可追踪”的项目。它能显著降低 AI 乱改，但要求用户愿意维护规格资产。

8.3 团队编排流

代表：OMC，部分 gstack。

主线是：

1. Lead Agent 分析任务。
2. 建 team，分配 worker。
3. worker 并行执行。
4. verifier / reviewer 检查。
5. 失败进入 fix loop。
6. 状态落盘，支持 resume/cancel/restart。

这种模式适合大型任务，但复杂度最高。它不是为了“让一次回答更好”，而是为了让 Agent 能长时间、多角色、可恢复地工作。

09 如果要选，怎么选？

9.1 个人日常 coding

优先选 Superpowers。

原因很简单：它轻、跨宿主、方法论约束强。你不需要引入一套新目录结构，也不需要学习完整 SDD。它最适合解决“Agent 不先想清楚、不写测试、做完不验证”的问题。

如果你做前端、网页 QA 或产品原型很多，可以叠加 gstack 的 browse、qa、design-review。

9.2 中大型项目，需要规格沉淀

优先选 Spec Kit 或 OpenSpec。

如果你希望流程更硬、更团队化，选 Spec Kit。它的 constitution/spec/plan/tasks 更适合团队统一标准。

如果你希望轻量接入现有项目，选 OpenSpec。它更 fluid，artifact graph 的设计也更适合渐进式推进变更。

9.3 长任务、多 Agent、并行执行

优先看 OMC。

OMC 的价值不在命令多，而在 runtime：worker allocation、health、restart、handoff、verify/fix loop、commit cadence。这些是长任务真正会遇到的问题。

但要接受它的复杂度。小任务不值得上 OMC。

9.4 产品/设计/发布全流程

看 gstack。

gstack 最适合“我想让 Agent 帮我从 idea 到设计、实现、QA、发布一路推进”的场景。它的 office-hours、design、review、qa、ship、document-release 这些技能组合起来，覆盖面比其他项目更偏产品团队。

但它 opinionated 很强。如果你只想要中立的工程流程，Superpowers 或 Spec Kit 更稳。

10 更深一层：这些项目共同说明了什么？

这五个项目有一个共同趋势：

AI Coding 的竞争点，正在从“模型会不会写代码”，转向“模型外部有没有可靠的工程 harness”。

这里的 harness 包括：

• 任务入口：用户的自然语言如何变成可执行目标。
• 规格层：需求、原则、计划、任务如何落盘。
• 执行层：Agent 如何分工、隔离、并行、恢复。
• 工具层：浏览器、shell、MCP、CDP、文件系统如何安全暴露。
• 验证层：测试、benchmark、review、security、QA 如何闭环。
• 记忆层：项目经验、失败教训、历史决策如何复用。
• 治理层：权限、遥测、状态、取消、恢复、自动提交如何管理。

Superpowers 把重点放在“行为规范”；OpenSpec 和 Spec Kit 把重点放在“规格资产”；gstack 把重点放在“产品团队工作流和工具环境”；OMC 把重点放在“团队运行时和自我改进”。

这也是为什么这些项目不是互斥关系。更合理的组合是：

• Superpowers 作为基础工程习惯层。
• OpenSpec 或 Spec Kit 作为规格层。
• gstack 提供产品/设计/浏览器/QA 能力。
• OMC 在确实需要多 Agent 长任务时作为执行编排层。

但不要一开始全装。AI workflow 的复杂度也会反噬。对个人博客、个人项目或小团队来说，最好的路径通常是：

1. 先用 Superpowers 解决基本工程纪律。
2. 需求复杂后引入 OpenSpec 或 Spec Kit。
3. 前端和产品验证需要真实浏览器时引入 gstack。
4. 只有长任务、并行任务、自动验证失败循环真实出现时，再引入 OMC。

11 总结

这几个项目表面上都在“增强 Claude Code”，但源码里体现的是五种不同工程选择：

如果只选一个，我会按任务规模选：

• 小任务和个人项目：Superpowers。
• 需求复杂但执行不重：OpenSpec。
• 团队协作和长期规格：Spec Kit。
• 产品体验和前端验证：gstack。
• 大型并行任务和长时间自治：OMC。

最终更重要的不是哪个 star 多，而是你到底缺哪一层 harness。缺工程纪律，就补 skills；缺需求契约，就补 spec；缺执行治理，就补 runtime。把问题定位清楚，比盲目叠工具更重要。