评分明细
适用场景
gstack 快速入门：先用一个报告型任务认识工程技能合集
这是什么？适合谁？
gstack 是 Garry Tan 公开维护的软件工程技能合集，主要围绕 Claude Code 组织规划、设计、审查、测试和发布等工作。它不是另一款基础模型，也不是安装后就能独立工作的完整开发团队。
它把不同阶段拆成 /office-hours、/plan-eng-review、/review、/qa-only 等明确入口。价值在于让任务有角色、有范围和可交接的产物，而不是只用一句“帮我做完”覆盖整个过程。
适合已经会使用编码助手、希望补上需求讨论和质量检查的个人开发者、技术负责人。对完全不了解 Git、运行权限与模型费用的新手，建议先学会保存和检查代码变更，再接入这类可执行技能。
与 superpowers 这类工程方法论套件相比，gstack 的入口更明显地按产品、设计、QA、发布岗位划分；与 anthropics/skills 的通用技能示例库相比，它更聚焦软件交付。两者都是选择方向，不构成效果优劣的实测结论。
核验日期：2026-10-20。本文以官方 README为操作依据；功能和兼容等级可能随更新变化。
准备工作
- 准备已正常工作的 Claude Code、Git 和 Bun。
- README 推荐 Bun v1.4.2+，并说明 setup 拒绝低于 1.3.3 的版本；不要只看“命令存在”。
- Windows 还需要 Node.js。macOS、Windows 和 Linux 的可选功能依赖不同。
- 准备一个不含密钥与客户数据的测试项目，先提交或备份已有改动。
- 软件为 MIT 许可；宿主订阅、模型调用和可选外部服务费用另算。
- 浏览器测试只用本地页面或你明确获准测试的预览环境。
先确认环境，而不是直接把安装提示交给拥有全部权限的 Agent。
git --version
bun --version
Windows 用户还应检查 node --version。如果某个命令失败，先按该工具官方安装说明修复环境。
安装、配置与首次使用
第一步：审阅安装入口
官方 Claude Code 安装路径如下。在自己的可控设备中使用，并先阅读仓库的 setup 文件；不要对不认识的脚本直接授予管理员权限。
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack
./setup
这是官方给出的 shell 路径，不是 Windows 原生 PowerShell 通用语法。Windows 用户应使用项目支持的 shell，并按 README 补齐 Node.js 等依赖。
预期结果是 setup 输出安装结果。不能只根据克隆成功就断言全部技能和浏览器组件均可使用。
已有同名目录时不要覆盖，先确认它是否为你先前安装的版本。
第二步：核对宿主与安装状态
在安装目录执行官方状态入口。
./setup --status
README 区分 full、experimental 与 instruction-only。Claude Code 为 full；Codex、Cursor 等适配列为 experimental；Hermes 是 instruction-only，不会因为执行 --host hermes 就自动获得完整工具链。
选择其他宿主时，按 README 使用明确的 --host 参数，不要把 Claude 的斜杠命令原样套到所有客户端。
暂不启用团队模式。./setup --team 配合团队初始化会改变项目配置并涉及提交，属于单独决策，不是完成个人试用的必要条件。
第三步：完成一个只报告的首次任务
在测试项目中准备一条本地 CLI 命令或一个本地网页。优先使用 /qa-only，不要一上来运行会修复代码的 /qa 或会推送代码的 /ship。
在 Claude Code 会话中输入以下示例，替换为项目真实的本地测试入口。
/qa-only 检查这个测试项目文档中已有的本地示例。
只运行明确记录的本地命令，不访问外部服务。
核对有效输入、无效输入、退出码和输出内容。
只写报告，不修改源码、测试或 Git 历史。
每个结论列出命令、预期结果、实际结果和未覆盖项。
如果项目没有现成 fixture 或本地入口，先让 Agent 列出缺什么，不要让它临时连接真实业务系统充当测试样本。
成功判定：得到可复现的检查报告，并能逐条重跑其中命令；同时确认没有未经授权的产品代码改动。
git status --short
git diff --stat
报告缺少实际输出、只写“应该能工作”时，首次任务仍未完成。
常见踩坑
下面按官方功能边界整理排查方法，不代表本站亲历的故障记录。
踩坑 1：把所有 QA 命令当只读
- 现象：原本只想看报告，项目却出现修复与测试变更。
- 原因：README 的
/qa包含复现、补测试、修复与复验。 - 解决：首次用
/qa-only并明确只报告；结束后检查 Git diff。 - 依据：命令说明。
踩坑 2：把发布角色当普通检查工具
- 现象：任务开始同步分支、推送或创建 PR。
- 原因：
/ship的设计就包含交付动作，/land-and-deploy更涉及合并与部署。 - 解决：没有发布授权时不调用这两个入口，把审查与发布分开。
- 依据：官方 README。
踩坑 3：宿主能安装，却没有等效安全限制
- 现象：在另一款助手中同名安全技能不阻止危险操作。
- 原因：README 明确区分 hooks 强制执行与 advisory 提示。
- 解决：按宿主兼容表判断，不把提示词约束当操作系统权限隔离。
- 依据：宿主适配说明。
踩坑 4：安装完成却无法运行安全审查的全部组件
- 现象：
/cso报告某项 not assessed。 - 原因：它另有 Bun 编译能力与原生工具链前提，setup 可以安装其余部分。
- 解决：按缺失前提逐项补齐；未覆盖部分保留为未评估，不能改写成通过。
- 依据：安装要求。
踩坑 5：浏览器带入真实登录态
- 现象：测试助手能访问已有登录会话的数据。
- 原因：官方浏览器路径可以利用现有会话，另有 cookie 导入工具。
- 解决：用独立测试账号与预览数据；不要在首次任务导入生产 cookie。
- 依据：浏览器功能说明。
初级用法
1. 用 office-hours 讨论真正的问题
描述目标用户、当前替代方案与一个具体困难，请它先质疑需求假设。保留讨论文档，尚未确认前不转入实现。
2. 用 plan-eng-review 检查方案缺口
给出一个已限定范围的功能计划，核对架构、数据流、异常分支与测试条件。把开放问题明确列出，避免“计划很完整”的空结论。
3. 用 qa-only 建立可复现记录
只测一个本地入口，每个发现对应输入、实际输出与复现步骤。先证明报告有用，再扩大测试范围。
高级玩法
1. 把规划产物传给下一角色
按 /office-hours → /plan-ceo-review → /plan-eng-review 逐步收敛需求。每次给出上一阶段文档路径，避免每个角色重新猜背景。
2. 把审查和自动修复分为两个任务
/review 官方说明包含自动修复部分问题。需要只读评审时，应在任务授权中写明限制，并独立核对 diff；修复另开明确范围的任务。
3. 使用另一厂商意见时先核对认证
README 说明外部复核需要相应 CLI 已安装并登录。外部审者不可用时，应标为未获得独立意见，不把一次模型自审写成双审。
小技巧
- 首次只选一个入口，优先
/qa-only，不要把整条发布链写进同一请求。 - 将允许访问的 URL 和本地目录写进任务，降低浏览器误触范围。
- 保存
./setup --status输出，升级后对照宿主与安装路径。 - 给每条发现保留复现命令，而不只保留严重程度标签。
- README 的生产力数字属于作者自述，不作为你项目的速度或质量承诺。
常见问题 FAQ
Q1：免费开源是否意味着运行没有成本？
A：不是。仓库以 MIT 分发，宿主与模型服务仍按各自方案收费；外部复核也需要可用账号。见官方说明。
Q2：与 superpowers 应该同时安装吗？
A：不必。前者按岗位拆入口，后者强调工程方法。先选能补上你当前流程缺口的一套，避免让两套规划与审查流程重复执行。参见superpowers。
Q3：能直接在 Hermes 使用所有功能吗？
A：README 将 Hermes 标为 instruction-only：可复制 digest 或自行渲染技能，不能当作完整原生安装已验证。本文没有进行宿主运行认证。
Q4：只想看报告，能用 qa 吗？
A：优先 /qa-only；/qa 说明包含修复与补测试，两者不能互换。
Q5：运行 ship 就一定会正式上线吗？
A：不能这样理解。/ship 包含推送与开 PR，后续合并部署仍受项目自己的 CI、权限和审批约束。不要以技能的角色名称代替发布授权。
功能学习路径
- 学
office-hours时重点看需求如何变成设计文档，而不是追求一次把代码写完。 - 学
plan-eng-review时检查异常与测试条件能否回指到同一份需求。 - 学
qa-only时先验证报告可重放，再考虑/qa的修复闭环。 - 学
setup --status与宿主适配表，分清 full、experimental 和 instruction-only 的承诺边界。
资料边界
本文基于官方文档和公开资料整理，AI辅助生成，MagicNetWorld 尚未完成独立实测。安装、浏览器会话访问、修复和发布均需要用户按项目权限单独授权；声音、交互体验与实际交付质量未在本站验证。
参考链接
📊 评分与标签
核验口径：已按现行口径通过，待按新证据契约复核
评分说明
总分 8.7/10 · P_优选
这是基于公开资料的编辑判断，不是交付速度或缺陷检出率测试。核验日期：2026-10-20。评分依据可追溯至公开来源，每项分数均有明确理由和数据支撑。
📊 可观测社区指标（采集日期：2026-10-20）
- GitHub 公开 API：136,950 Stars、20,317 Fork；73 个开放事项，包含 PR，不能等同纯 issue 数。
- API 的 pushed_at 为 2026-10-19T20:55:00Z，北京时间 2026-10-20 04:55；距离核验不足三个月，不触发长期未更新提示。
- MIT 许可已核对。Stars 只说明关注规模，不证明真实使用、无刷星或功能质量。
📦 可安装性 2.1/2.5
- 官方提供 Git 克隆、
./setup和./setup --status，个人安装入口明确；Bun、Windows Node.js、部分原生工具链构成额外前提。来源：安装说明。 /cso有独立编译和工具链要求，其他组件安装成功不能代替它的可用性确认，因此不满分。来源：官方 README。- 竞品对比 1（superpowers）：同属工程技能套件，但侧重方法论安装与加载；gstack 额外涉及浏览器及编译组件，首次环境准备更重。来源：superpowers。
- 竞品对比 2（Anthropic Skills）：提供技能示例与插件使用说明；gstack 将安装与工程角色入口组合得更集中，但依赖也更多。来源：Anthropic Skills。
🎯 实用性 2.3/2.5
/office-hours、/plan-eng-review、/qa-only、/ship对应不同交付阶段，能形成文档与报告交接；这是一套覆盖较广的流程设计。来源：命令清单。/qa-only与/qa的报告/修复边界有区分，但/review、/ship等包含写入或推送动作，采用前仍需项目授权；本站未测试实际检出率。来源：官方 README。- 竞品对比 1（superpowers）：同样约束工程过程，gstack 的岗位命名使规划、设计和交付入口更易区分，不代表所有项目都需要两套流程。来源：superpowers。
- 竞品对比 2（Anthropic Skills）：覆盖更多通用任务形态，gstack 则在软件交付链内组织更具体的角色。来源：Anthropic Skills。
📖 文档质量 1.8/2.0
- README 给出依赖、安装、状态检查、宿主等级和命令差异，尤其说明外部复核 CLI 的认证条件。来源：官方文档入口。
- 文档同时包含生产力自述与较多可选路径，初学者仍需区分作者经历、功能设计与自己已经验证的结果，因此保留扣分。
- 竞品对比 1（superpowers）：其方法论组织更集中；gstack 角色更细，但初次选入口的阅读负担更大。来源：superpowers。
- 竞品对比 2（Anthropic Skills）：示例适合学习单个技能结构；gstack 的优势是软件交付上下游说明，而非替代全部技能规范。来源：Anthropic Skills。
👥 社区活跃 1.4/1.5
- 仓库关注规模较大，pushed_at 接近核验时刻，提供当前维护活动信号；不以关注数推断企业采用率。来源：公开 API。
- 未统计独立活跃贡献者、响应耗时或长期维护承诺，也不将 README 的作者交付数字作为本站结果。
- 竞品对比 1（superpowers）：两者均有公开仓库、issue 与贡献入口；没有同口径贡献者分析，不宣称 gstack 社区支持更强。来源：superpowers。
- 竞品对比 2（Anthropic Skills）：官方维护背景与个人开源项目的治理不同；本分数只描述可观测活动，不把二者品牌背书互换。来源：Anthropic Skills。
🔗 兼容性 1.1/1.5
- 官方明确区分 Claude Code full、若干宿主 experimental 与 Hermes 等 instruction-only，跨宿主并非等效运行。来源：宿主说明。
- 部分宿主只保留 advisory 安全提示，不提供同等 hooks 拦截；本站未执行跨平台认证，因此不按全平台完整支持给分。
- 竞品对比 1（superpowers）：同样需要按各宿主安装说明判断，不能只因都包含 Markdown 就认定零成本兼容。来源：superpowers。
- 竞品对比 2（Anthropic Skills）：可借鉴通用技能结构，但宿主支持与第三方工具依赖仍需分别核对。来源：Anthropic Skills。
🏷️ 标签说明
- 合集：包含多个规划、审查、QA 与交付技能，不是单一技能。来源：命令清单。
- 开源免费：MIT 分发；模型、宿主与可选服务成本不在免费范围内。来源：LICENSE。
- 软件工程：主要围绕需求、架构、测试、审查和交付组织工作。来源：README。
- Agent Skills：以可由编码助手加载的技能入口组织流程。来源：README。
局限与未实测声明
未安装执行 setup、浏览器或审查流程，未验证作者生产力数字、检出率及真实项目交付质量。所有功能属于官方文档描述，分数是公开资料下的编辑判断；高关注量不构成质量认证。
📋 来源核实
- 已核对：官方 README、MIT 文件、GitHub API。
- 对照资料：superpowers README、Anthropic Skills README。
- 核验日期：2026-10-20；安装、交互与运行效果尚未完成独立实测。