Superpowers-vs-GSD-深度拆解两大-Claude-Code-Skill-框架

Superpowers vs GSD：深度拆解两大 Claude Code Skill 框架

2026-03-30

参考 Tw93 的《你不知道的 Agent：原理、架构与工程实践》

0. 太长不读

本文从源码层面拆解 Claude Code 生态中两个很有代表性的 Skill / Workflow 框架——Superpowers（obra/superpowers）和 Get Shit Done（gsd-build/get-shit-done），覆盖架构设计、上下文工程、多 Agent 编排、状态管理、验证体系和工程哲学。

核心结论：

• Superpowers 是一套面向「工程纪律」的 Skill 框架，核心武器是 TDD + 子 Agent Review 循环，强调过程正确性，像一个严格的 Tech Lead。
• GSD 是一套面向「交付流水线」的 Meta-Prompting 框架，核心武器是 Wave 并行执行 + 多层验证管线，强调从 idea 到代码的端到端自动化，像一个全自动化的工程团队。
• 两者解决的核心问题一致：Context Rot（上下文腐化）和 Agent 偏航，但路径完全不同。

---

1. 一句话定位

维度	Superpowers	GSD
一句话	"Your coding agent just has Superpowers"	"No enterprise roleplay bullshit. Just gets shit done"
本质	可组合的 Skill 库 + 强制触发规则	Meta-Prompting 框架 + 状态机 + CLI 工具链
作者	Jesse Vincent（@obra）	TÂCHES（@gsd_foundation）
GitHub 热度	高	高
版本	v5.0.6	v1.30.0
许可	MIT	MIT

---

2. 架构对比：Skill 库 vs 工程流水线

Superpowers 的核心仍然很极简：以 Skill 库为中心，再用一个 SessionStart Hook 把入口 Skill 注入会话。只是从当前仓库来看，它已经不再是“只有 skills 和 hook”这么纯粹，也包含少量 commands 和 agent prompt。

superpowers/
├── skills/           # 14 个可组合 Skill
│   ├── brainstorming/SKILL.md
│   ├── test-driven-development/SKILL.md
│   ├── systematic-debugging/SKILL.md
│   ├── subagent-driven-development/SKILL.md
│   ├── writing-plans/SKILL.md
│   ├── verification-before-completion/SKILL.md
│   └── ...（共 14 个）
├── hooks/
│   ├── session-start      # 核心 hook：注入 using-superpowers Skill
│   ├── run-hook.cmd       # 跨平台 polyglot 脚本
│   └── hooks*.json        # hook 配置
├── commands/         # 少量显式命令入口
├── agents/           # 辅助 agent prompt
└── .claude-plugin/
    └── plugin.json        # 插件元数据

核心机制：SessionStart Hook 读取 using-superpowers/SKILL.md 内容，JSON 转义后注入 additionalContext。这个 Skill 里写死了一条铁律：

"If there's even 1% chance a skill applies, ABSOLUTELY MUST invoke it."

这意味着 Superpowers 的主要流程约束，仍然是靠 Skill 文本里的指令 驱动模型行为。它没有像 GSD 那样显式的持久状态机和重 CLI 工具层，整体上仍然更接近 Prompt / Skill-first 的设计。

GSD 的架构

GSD 是一个更重的分层工程系统：

┌─────────────────────────────────────────────┐
│                   USER                       │
│            /gsd:command [args]                │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│           COMMAND LAYER（50+ 个命令）         │
│    commands/gsd/*.md — 用户入口              │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│       WORKFLOW LAYER（50+ 个工作流）          │
│  get-shit-done/workflows/*.md — 编排逻辑     │
└────┬─────────────┬──────────────┬───────────┘
     │             │              │
┌────▼────┐  ┌─────▼────┐  ┌─────▼─────┐
│ Agent 1 │  │ Agent 2  │  │ Agent 3   │
│ (fresh) │  │ (fresh)  │  │ (fresh)   │
└────┬────┘  └─────┬────┘  └─────┬─────┘
     │             │              │
┌────▼─────────────▼──────────────▼───────────┐
│          CLI TOOLS LAYER                     │
│    gsd-tools.cjs + install.js                │
│    状态、配置、模板、验证、安全              │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│           FILE SYSTEM (.planning/)           │
│    PROJECT.md | ROADMAP.md | STATE.md        │
│    config.json | phases/ | research/         │
└─────────────────────────────────────────────┘

GSD 的独特之处在于它有一个 真正的 CLI 工具层。当前仓库里，除了 get-shit-done/bin/gsd-tools.cjs 这种运行时工具，还有一个体量很大的 bin/install.js 安装器，负责：

• 初始化上下文：node gsd-tools.cjs init <workflow> <phase>
• 模型选择：node gsd-tools.cjs resolve-model <agent-name>
• 状态更新：node gsd-tools.cjs state update
• 模板填充、安全验证、文件锁管理

这不是 Prompt 能做的事——这是确定性逻辑外化。

架构哲学总结

维度	Superpowers	GSD
控制方式	Skill / Prompt 驱动为主	Prompt + CLI 工具双轨
状态管理	无持久状态（靠 Git + 上下文窗口）	.planning/ 目录作为持久状态机
确定性逻辑	全部在 Prompt 里	外化到 Node.js CLI 工具
复杂度	约 166 个文件，3.9MB（本地快照）	约 458 个文件，12MB（本地快照）
扩展点	加 Skill，也可加少量 command / agent	加 Command + Workflow + Agent + CLI

---

3. 上下文工程：谁更会「喂」模型

Superpowers 的上下文策略：Lazy Loading

Superpowers 的上下文管理完全遵循 Skills 按需加载原则：

0. 常驻层：只有 using-superpowers 一个 Skill 通过 SessionStart Hook 注入，约几百 token
1. 按需加载：每个 Skill 通过 Skill 工具按需读取 SKILL.md 全文
2. 无运行时状态注入：不注入时间、配置、项目元数据

Skill 描述优化（CSO - Claude Search Optimization）：

Superpowers 对 Skill 的 YAML frontmatter description 字段有严格要求——只写触发条件，不写功能摘要。原因很具体：

"Descriptions that summarize workflow cause Claude to follow description instead of reading full skill."

如果 description 写成「TDD 工作流，包含 RED-GREEN-REFACTOR 循环」，模型会觉得自己已经知道该怎么做了，跳过读取完整 Skill。正确写法是「Use when about to implement any feature or bug fix」——这只是路由条件。

Token 预算：

• 高频加载的 Skill：< 200 words
• 普通 Skill：< 500 words
• 入门流程：< 150 words

GSD 的上下文策略：结构化注入 + 分层传播

GSD 的上下文管理要复杂得多，因为它有持久状态和多阶段流水线。

初始化时的上下文装载：

每个 Workflow 启动时，通过 gsd-tools.cjs init 加载一个 JSON 上下文包：

{
  "project": { "name": "...", "goals": "..." },
  "config": { "mode": "interactive", "model_profile": "balanced", ... },
  "state": { "current_phase": 3, "decisions": [...], "blockers": [...] },
  "phase": { "name": "用户认证", "goals": [...], "context_md": "..." },
  "research": { "stack": "...", "pitfalls": "..." },
  "plans": [{ "id": "03-01", "status": "pending", ... }]
}

上下文传播链：

PROJECT.md ─────────────────────────► 所有 Agent
REQUIREMENTS.md ────────────────────► Planner, Verifier, Auditor
ROADMAP.md ─────────────────────────► Orchestrator
STATE.md ───────────────────────────► 所有 Agent（决策、阻塞）
CONTEXT.md (per phase) ─────────────► Researcher, Planner, Executor
RESEARCH.md (per phase) ────────────► Planner, Plan Checker
PLAN.md (per plan) ─────────────────► Executor, Plan Checker

每个 Agent 只拿到它需要的文件，不多不少。「Dynamic Context Discovery：默认少给，只在需要时读取」。

XML 格式化：

GSD 的执行计划用 XML 结构化，这不是随便选的格式——Claude 对 XML 标签有天然的解析能力：

<task type="auto">
  <name>Create login endpoint</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    Use jose for JWT (not jsonwebtoken - CommonJS issues).
    Validate credentials against users table.
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login returns 200</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>

每个 task 自带验证命令和完成标准，Executor Agent 不需要「理解」全局目标，只需要精确执行。

上下文工程对比

维度	Superpowers	GSD
常驻 token 开销	极小（~几百 token）	中等（PROJECT.md + STATE.md）
加载策略	Lazy（Skill 工具按需读取）	结构化注入（CLI 工具预组装 JSON）
上下文格式	纯 Markdown	Markdown + XML + JSON
跨 Session 记忆	无内建状态机（需依赖外部记忆或文档文件）	STATE.md + HANDOFF.json
Agent 间传播	无显式机制	文件系统作为通信总线
Context Rot 防御	子 Agent 隔离上下文	每个 Agent 200K 全新窗口

---

4. 多 Agent 编排：Review 循环 vs Wave 并行

这是两个框架差异最大的地方。

Superpowers：Controller + Implementer + Reviewer

Superpowers 的核心编排模式是 subagent-driven-development：

Controller（主会话）
    │
    ├── 读取 Plan，提取所有 Task
    │
    ├── 对每个 Task：
    │   ├── 1. 派发 Implementer 子 Agent（全新上下文）
    │   ├── 2. Implementer 自审后报告状态
    │   │   ├── DONE → 进入 Review
    │   │   ├── DONE_WITH_CONCERNS → 评估后继续
    │   │   ├── NEEDS_CONTEXT → 补充信息重试
    │   │   └── BLOCKED → 升级处理
    │   │
    │   ├── 3. 派发 Spec Compliance Reviewer
    │   │   └── 有问题 → Implementer 修复 → 重新 Review
    │   │
    │   ├── 4. 派发 Code Quality Reviewer
    │   │   └── 有问题 → Implementer 修复 → 重新 Review
    │   │
    │   └── 5. 标记完成
    │
    └── 全部完成后：Final Code Reviewer

关键特点：

• 两阶段 Review：先验规格合规性，再验代码质量。顺序不能反。
• 模型选择策略：机械实现用便宜模型，集成任务用标准模型，架构 / Review 用最强模型。
• Controller 保持干净：Controller 永远不执行具体任务，只做调度和决策。子 Agent 的搜索、试错、调试过程不污染主上下文。

这是典型的 评估器-优化器 模式。

GSD：Wave 并行 + 多层验证管线

GSD 的执行模式更像工厂流水线：

Plan 依赖分析
    │
    ▼
┌──────────────────────────────────────┐
│  Wave 1（并行）                        │
│  ┌─────────┐  ┌─────────┐            │
│  │ Plan 01 │  │ Plan 02 │            │
│  │ Executor│  │ Executor│  ← 各自 200K 全新上下文
│  └────┬────┘  └────┬────┘            │
│       │  git commit │  git commit     │
│       └──────┬─────┘                 │
│              │                        │
│       pre-commit hook（一次）          │
└──────────────┬───────────────────────┘
               │
┌──────────────▼───────────────────────┐
│  Wave 2（并行，依赖 Wave 1）           │
│  ┌─────────┐  ┌─────────┐            │
│  │ Plan 03 │  │ Plan 04 │            │
│  └─────────┘  └─────────┘            │
└──────────────┬───────────────────────┘
               │
┌──────────────▼───────────────────────┐
│  Verifier（goals-backward 分析）      │
└──────────────┬───────────────────────┘
               │
┌──────────────▼───────────────────────┐
│  UAT（用户验收测试）                    │
└──────────────────────────────────────┘

GSD 的四层验证体系：

层	时机	Agent	检查内容
Plan Checker	执行前	gsd-plan-checker	8 个维度：需求覆盖、原子性、依赖序、文件范围、验证命令、上下文适配、缺口检测、Nyquist 合规
Executor Verify	执行中	gsd-executor	每个 task 自带 <verify> 命令（curl、测试调用等）
Verifier	执行后	gsd-verifier	从 Phase Goals 反向分析代码库是否交付
UAT	人工确认	用户	逐项确认可测试交付物

并行安全机制：

• 同一 Wave 内的 Executor 用 --no-verify 提交，避免 pre-commit hook 的 build lock 竞争
• Wave 完成后，Orchestrator 统一跑一次 git hook run pre-commit
• STATE.md 更新使用 O_EXCL 原子文件锁 + 抖动自旋等待，防止读-改-写竞态

编排对比

维度	Superpowers	GSD
Agent 类型	核心编排集中在实现者 + 两阶段 Reviewer	16+ 种（Researcher, Planner, Executor, Verifier, Debugger...）
并行粒度	Task 级（dispatching-parallel-agents）	Wave 级（Plan 依赖分组）
Review 机制	两阶段子 Agent Review 循环	四层验证管线（Plan Check → Executor Verify → Verifier → UAT）
并行安全	无显式机制（靠任务独立性）	文件锁 + --no-verify commit + Wave 同步
修复策略	Review 循环（发现 → 修复 → 重新 Review）	Node Repair（自动重试，最多 2 次）+ Debug Agent
上下文隔离	子 Agent 独立 messages[]	每个 Agent 200K 全新窗口

---

5. 工作流对比：交互式引导 vs 全流水线

Superpowers 的工作流：自然对话驱动

Superpowers 的工作流是隐式的——通过 Skill 之间的交叉引用和 using-superpowers 的路由规则串联：

用户说要做什么
    │
    ▼
brainstorming ──→ 设计文档 + 用户审批
    │
    ▼
using-git-worktrees ──→ 隔离工作区
    │
    ▼
writing-plans ──→ 实现计划（bite-sized tasks）
    │
    ▼
subagent-driven-development ──→ 实现 + Review
    │
    ▼
finishing-a-development-branch ──→ Merge/PR/保留/丢弃

没有显式的命令，没有阶段号，没有进度文件。Agent 根据上下文自动判断该触发哪个 Skill。用户体验是一段连续的对话。

brainstorming 的细节：

• 每次只问一个问题（不轰炸用户）
• 设计文档分段展示，每段都要用户确认
• 可选的 Visual Companion（浏览器端 UI 用于 mockup）
• 输出写入 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md

GSD 的工作流：显式命令驱动

GSD 的工作流是显式的——当前本地仓库里可见 50+ 个命令和 50+ 个 workflow 定义，每一步都有明确的输入和输出：

/gsd:new-project
    ├── Questions → Research(4 个并行 Agent) → Requirements → Roadmap
    │
    ▼
FOR EACH PHASE:
    /gsd:discuss-phase N  → CONTEXT.md
    /gsd:ui-phase N       → UI-SPEC.md（可选）
    /gsd:plan-phase N     → RESEARCH.md → PLAN.md（verified）
    /gsd:execute-phase N  → 代码 + commits + VERIFICATION.md
    /gsd:verify-work N    → UAT.md
    /gsd:ship N           → PR
    │
    ▼
/gsd:complete-milestone → 归档 + Tag
/gsd:new-milestone      → 下一轮

快捷模式：

• /gsd:quick：跳过完整规划，但保留状态追踪和原子提交
• /gsd:fast <text>：完全跳过规划，直接执行
• /gsd:next：自动检测当前状态，跑下一步

discuss-phase 的细节

GSD 在规划前有一个独特的 discuss-phase 步骤。ROADMAP 里每个阶段只有一两句话，不够执行。discuss-phase 根据阶段类型识别灰色区域：

• 视觉功能 → 布局、密度、交互、空状态
• API/CLI → 响应格式、参数、错误处理
• 内容系统 → 结构、语气、深度、流程

用户的偏好写入 CONTEXT.md，直接影响后续的 Research 方向和 Plan 决策。

还有一个 assumptions 模式：不问用户，而是先分析代码库，列出「我打算这么做」和「为什么」，让用户纠正不对的部分。

工作流对比

维度	Superpowers	GSD
触发方式	自动（Skill 路由）	显式命令
命令数量	很少，核心仍靠自动 Skill 路由	50+ 个
阶段管理	无（单一 Plan 维度）	多层级：Milestone → Phase → Plan → Task
进度追踪	无持久化	STATE.md + ROADMAP.md
会话恢复	无内建 pause/resume 状态机	/gsd:pause-work + /gsd:resume-work
快捷路径	显式捷径较少	quick / fast / next 三种快捷模式
需求管理	Design Doc（一次性）	REQUIREMENTS.md（v1/v2/out-of-scope 分级）

---

6. TDD 与质量保障

Superpowers 的 TDD：铁律级强制

TDD 是 Superpowers 的灵魂。不是建议，不是最佳实践——是不可违反的铁律：

"NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST."

test-driven-development Skill 里有一张「反理性化表」，列出 10+ 种常见借口和反驳：

你的想法	为什么是错的	该怎么做
"太简单了不需要测试"	简单代码出 bug 的时候最难发现	写测试
"先写代码再补测试"	测试会变成对实现的验证而不是对行为的定义	删掉已写的代码，先写测试
"这是 UI，不好测试"	行为可测，不测外观	测交互和状态
"赶时间"	不测试的代码后面花更多时间修	写测试

注意最狠的一条：如果你先写了代码再想起要 TDD，正确做法是删掉已写的代码，从测试开始。

这个 TDD 原则还被递归应用到 Skill 编写本身：

"Writing skills IS TDD for documentation."

RED: 用压力场景测试，Agent 在没有 Skill 时会违规 GREEN: 写最小 Skill 让 Agent 通过 REFACTOR: 堵住新发现的漏洞

GSD 的质量保障：多层自动验证

GSD 没有 Superpowers 那样的 TDD 铁律。它的质量保障策略是多层自动验证：

0. Plan 级验证（执行前）：Plan Checker Agent 检查 8 个维度，最多循环 3 次
1. Task 级验证（执行中）：每个 task 的 <verify> 命令
2. Phase 级验证（执行后）：Verifier Agent 从 Goals 反向检查
3. 人工验证（最终）：UAT 逐项确认

另外还有 Nyquist Validation（测试覆盖映射）——名字来自信号处理的 Nyquist 采样定理，意思是测试覆盖率要达到「足以捕获所有关键信号」的水平。gsd-nyquist-auditor Agent 只写测试文件，不改实现代码。

GSD 还有 Node Repair 机制：如果 Executor 的验证失败，自动重试修复，最多 2 次。超过预算就升级为 Debug Agent 处理。

质量保障对比

维度	Superpowers	GSD
TDD 强制度	铁律（删掉先写的代码）	无强制（Planner 可选 TDD 模式）
代码审查	两阶段子 Agent Review	Plan Checker + Verifier
验证层数	2 层（Review + Verification）	4 层（Plan Check → Verify → Verifier → UAT）
自动修复	Review 循环修复	Node Repair（自动重试）
Debug	systematic-debugging（4 阶段科学方法）	gsd-debugger（持久状态 + 假设追踪）
测试覆盖	靠 TDD 自然保障	Nyquist Auditor 补充测试

---

7. 状态管理：无状态 vs 持久化状态机

这是两个框架最根本的分歧。

Superpowers：无持久状态

Superpowers 没有像 GSD 那样的持久化状态机文件。它的「状态」更多存在于：

• 当前上下文窗口里的对话历史
• Git 仓库的 commit 历史
• docs/superpowers/specs/ 和 docs/superpowers/plans/ 下的设计文档和计划文件

Session 结束后，不会像 GSD 那样自动从统一状态机断点恢复。如果需要跨 Session 连续性，通常得依赖设计文档、计划文件或外部记忆工具。

好处是简单——没有状态同步问题，没有状态损坏风险，没有文件锁。 坏处是长任务连续性较弱——没有内建的暂停、恢复、进度状态编排。

GSD：.planning/ 作为持久化状态机

GSD 的 .planning/ 目录是一个完整的项目状态系统：

.planning/
├── PROJECT.md          # 项目愿景（不变）
├── REQUIREMENTS.md     # 需求（v1/v2/out-of-scope）
├── ROADMAP.md          # 阶段 + 状态追踪
├── STATE.md            # 活态记忆：位置、决策、阻塞、指标
├── config.json         # 工作流配置
├── HANDOFF.json        # 会话交接
├── research/           # 领域研究
├── phases/             # 每阶段的所有产物
│   └── XX-phase-name/
│       ├── XX-CONTEXT.md
│       ├── XX-RESEARCH.md
│       ├── XX-YY-PLAN.md
│       ├── XX-YY-SUMMARY.md
│       ├── XX-VERIFICATION.md
│       └── XX-UAT.md
├── quick/              # 临时任务
├── debug/              # 调试会话 + knowledge-base.md
├── threads/            # 持久上下文线程
└── seeds/              # 前瞻性想法

STATE.md 是系统的活态记忆，记录：

• 当前位置（阶段、状态）
• 已做决策（技术、架构）
• 阻塞及解决方式
• 指标（阶段完成数、提交行数）
• 会话笔记

每个重大步骤完成后，Orchestrator 通过 gsd-tools.cjs state update 更新 STATE.md。

会话恢复：/gsd:pause-work 生成 HANDOFF.json，/gsd:resume-work 从断点继续。这是 Tw93 文章中「Initializer + Coding Agent 模式」的实际实现。

---

8. 平台支持与安装

Superpowers

平台	安装方式
Claude Code	/plugin install superpowers@claude-plugins-official
Cursor	/add-plugin superpowers
Codex	手动 clone + symlink
OpenCode	手动配置 plugin JSON
Gemini CLI	gemini extensions install

安装后就是一个 plugin 目录，不需要外部依赖。

GSD

平台	安装方式
Claude Code	npx get-shit-done-cc@latest --claude
OpenCode	npx get-shit-done-cc@latest --opencode
Gemini CLI	npx get-shit-done-cc@latest --gemini
Codex	npx get-shit-done-cc@latest --codex
Copilot	npx get-shit-done-cc@latest --copilot
Cursor	npx get-shit-done-cc@latest --cursor
Windsurf	npx get-shit-done-cc@latest --windsurf
Antigravity	npx get-shit-done-cc@latest --antigravity

一个 npx 命令覆盖 8 个平台，支持交互式多选。安装器（bin/install.js）体量很大，负责处理所有平台差异：

• 工具名映射（Claude 的 Bash → Copilot 的 execute）
• Hook 事件名转换（PostToolUse → Gemini 的 AfterTool）
• Agent frontmatter 格式转换
• 路径规范化

至少从当前仓库的安装器复杂度和平台映射来看，GSD 在跨平台支持上做得更重、更系统。

---

9. Hooks 系统

Superpowers 的 Hooks：极简

从当前仓库看，Superpowers 有多个 hook 相关文件，但唯一核心行为 hook 仍然是 SessionStart：把 using-superpowers Skill 的内容注入会话上下文。

# hooks/session-start（简化版逻辑）
skill_content=$(cat "$PLUGIN_ROOT/skills/using-superpowers/SKILL.md")
escaped=$(echo "$skill_content" | json_escape)
echo "{"hookSpecificOutput":{"additionalContext":"$escaped"}}"

跨平台通过 run-hook.cmd 实现——一个 Bash/CMD polyglot 脚本，Windows 上自动找 Git for Windows 的 bash。

GSD 的 Hooks：五个功能 Hook

Hook	事件	功能
gsd-statusline.js	statusLine	状态栏：模型、当前任务、目录、上下文使用率
gsd-context-monitor.js	PostToolUse	上下文警告：≤35% WARNING，≤25% CRITICAL
gsd-check-update.js	SessionStart	后台检查新版本
gsd-prompt-guard.js	PreToolUse	扫描 .planning/ 写入中的 Prompt Injection
gsd-workflow-guard.js	PreToolUse	检测工作流外的文件编辑（可选）

statusline 的细节值得展开：

• 通过 stdin 读取 session JSON（模型、工作区、上下文窗口大小）
• 输出 ANSI 着色的状态栏（█░░░░░ 63%）
• 颜色编码：绿 (<50%)、黄 (<65%)、橙 (<80%)、红 (>80% + 骷髅 emoji)
• 向 /tmp/claude-ctx-{session_id}.json 写入 Bridge 文件，供 context-monitor 读取
• 3 秒 stdin 超时保护（防止 Windows/Git Bash 管道挂起）

context-monitor 的工作方式：

• 每次工具使用后触发
• 从 Bridge 文件读取上下文使用率
• 5 次工具调用的 debounce 间隔
• 严重度升级（WARNING → CRITICAL）跳过 debounce
• 检测是否在 GSD 工作流中（有无 .planning/STATE.md），提供不同的警告消息

prompt-guard 扫描的注入模式（12+）：

• "ignore all previous instructions"
• "forget your instructions"
• XML 标签注入（<system>, [SYSTEM], <<SYS>>）
• 不可见 Unicode 字符（零宽空格、零宽连接符等）

---

10. 配置系统

Superpowers：零配置

没有像 GSD 那样的集中式配置系统。主要行为由 Skill 文本定义，用户偏好更多通过宿主配置或项目约定文件覆盖。

GSD：深度可配置

.planning/config.json 提供完整的配置矩阵：

模型配置（per-agent 级别）：

Agent	quality	balanced	budget
gsd-planner	Opus	Opus	Sonnet
gsd-executor	Opus	Sonnet	Sonnet
gsd-phase-researcher	Opus	Sonnet	Haiku
gsd-verifier	Sonnet	Sonnet	Haiku

工作流开关：

设置	默认	作用
workflow.research	true	规划前做领域研究
workflow.plan_check	true	执行前验证 Plan
workflow.verifier	true	执行后验证交付
workflow.auto_advance	false	自动串联 discuss → plan → execute
workflow.nyquist_validation	true	测试覆盖映射
workflow.node_repair	true	验证失败自动修复
workflow.discuss_mode	discuss	discuss（访谈）/ assumptions（代码分析优先）

并行配置：

{
  "parallelization": {
    "enabled": true,
    "plan_level": true,
    "task_level": false,
    "max_concurrent_agents": 3,
    "min_plans_for_parallel": 2
  }
}

Git 分支策略：

策略	行为
none	提交到当前分支
phase	每个 Phase 一个分支
milestone	每个 Milestone 一个分支

全局默认存在 ~/.gsd/defaults.json，新项目自动继承。

---

11. 安全设计

Superpowers 的安全：靠 Skill 文本约束

• Git Worktree 安全检查：创建 worktree 前验证目录已被 .gitignore
• 不可逆操作确认：finishing-a-development-branch 的 Discard 选项需要用户输入 "discard" 确认
• 子 Agent 最小权限：不带 Skills 和 Memory，只给 Tooling、Workspace、Runtime

GSD 的安全：多层防御

自 v1.27 起，GSD 有完整的安全层：

0. 路径遍历防护：所有用户提供的文件路径验证在项目目录内
1. Prompt Injection 检测：security.cjs 集中扫描，Hook 层二次检测
2. Shell 参数验证：用户文本进入 shell 前做清洗
3. 安全 JSON 解析：畸形输入在破坏状态前被捕获
4. CI 就绪的注入扫描：prompt-injection-scan.test.cjs 扫描所有 Agent/Workflow/Command 文件

---

12. 适用场景

什么时候用 Superpowers

• 你是个有经验的开发者，知道自己要什么，需要 Agent 保持工程纪律
• 项目已有代码，需要在现有基础上增量开发
• 单个功能或 bug fix，不需要从零开始的项目规划
• 你重视 TDD，想让 Agent 严格遵守 RED-GREEN-REFACTOR
• 你想要自然对话式体验，不想记命令
• 你需要极低的学习成本——安装即用，不需要学习新概念

什么时候用 GSD

• 你是 Solo 开发者或小团队，要从 idea 到交付的全流程自动化
• 你在做新项目，需要从零开始的需求分析、研究、规划
• 项目规模大，需要阶段管理、里程碑追踪
• 你需要跨 Session 连续性——暂停、恢复、状态追踪
• 你追求最大化自动化——走开喝咖啡，回来看完成的代码
• 你使用多个 AI 编码工具，需要统一的框架跨平台工作
• 你想要精细控制——模型选择、并行度、工作流开关

---

13. 总结：两种工程哲学

维度	Superpowers	GSD
哲学	工程纪律 > 自动化	端到端自动化 > 过程纯粹性
隐喻	严格的 Tech Lead	全自动化工程团队
控制方式	Prompt 驱动（soft）	CLI 工具 + Prompt（hard + soft）
状态	无状态	持久化状态机
TDD	铁律	可选
Agent 数	核心模式较少，围绕实现与 review 展开	16+ 种角色
命令	很少，重自动路由	50+ 个
平台	5 个	8 个
配置	零配置	深度可配置
学习曲线	低（安装即用）	中（需要理解工作流）
适合	增量开发、功能迭代、有经验开发者	新项目、全流程自动化、Solo 开发

最终，选择哪个不取决于哪个「更好」，而取决于你的工作方式。如果你把 AI Agent 当作一个需要纪律约束的初级工程师——用 Superpowers。如果你把 AI Agent 当作一个可以全权委托的工程团队——用 GSD。

两者都在解决同一个核心问题：让 AI 编码 Agent 的输出从「偶尔能用」变成「稳定可靠」。路径不同，目标一致。

---

参考资料

0. obra/superpowers - Superpowers 核心仓库
1. gsd-build/get-shit-done - GSD 核心仓库
2. Superpowers: How I'm using coding agents - Jesse Vincent 的博客
3. Tw93, 你不知道的 Agent：原理、架构与工程实践
4. Anthropic, Introducing Agent Skills
5. OpenAI, Harness engineering: leveraging Codex in an agent-first world