Appearance
SillySpec vs 其他工具
为什么不直接用 Superpowers / OpenSpec / GSD？SillySpec 做了什么取舍？
三大工具介绍
Superpowers
Superpowers 是当前最火的 Claude Code 增强套件，以 Skills 插件形式提供 AI 行为规范。核心 skill 包括 brainstorming（需求探索）、writing-plans（精准规划）、subagent-driven-development（子代理执行）、test-driven-development（TDD 纪律）等 7 大流程。通过 HARD GATE 机制防止 AI 跳步骤。支持 Claude Code、Cursor、Codex、OpenCode 四种工具。
OpenSpec
OpenSpec 是 TypeScript 实现的 npm CLI 工具，专注规范的结构化管理。规范是结构化数据（TypeScript schema 校验），不是纯文本 prompt。支持 change 的 diff/merge，适配器模式支持 20+ AI 工具。明确支持棕地项目。有 verify 命令做规范一致性检查。
GSD（Get Shit Done）
GSD 以"上下文工程"为核心，解决 context rot（上下文窗口填满后质量下降）问题。核心机制：每个 Plan 开启独立子代理执行，200k token 纯净上下文，零累积垃圾。STATE.md 自动维护跨会话状态。支持 Claude Code、OpenCode、Gemini、Codex、Copilot、Cursor、Antigravity 共 8 种运行时。有多项目工作区（worktree/clone 隔离）。
SillySpec 的定位
SillySpec 取各家所长——Superpowers 的需求探索、OpenSpec 的变更管理、GSD 的上下文工程——串成一条完整的开发流水线，再加原创功能填补空白。
借鉴了什么
| 来源 | 借鉴能力 |
|---|---|
| Superpowers | brainstorming 方法论、HARD GATE、TDD 子代理执行 |
| OpenSpec | 变更管理（proposal→design→tasks）、规范沉淀（archive） |
| GSD | 棕地扫描（7 份文档）、STATE.md 自动状态管理、绿地深度提问 |
原创了什么
| 能力 | 说明 |
|---|---|
| 原型图分析 | brainstorm 直接贴截图，提取页面结构/表单字段/交互流程 |
| 大模块拆分 | 复杂需求按内容复杂度自动拆分多阶段，MASTER.md 管理全局 |
| 框架隐形规则扫描 | scan 检测多租户拦截器、逻辑删除、审计字段等，防 SQL 冲突 |
| 实体继承规范扫描 | scan 检测基类通用字段，防新建表漏列导致 Unknown column |
| 多项目工作区 | 前后端分离/小程序等多子项目统一管理，共享规范 |
| 多工具适配 | 一个模板适配 6 种 AI 工具（Claude/Cursor/Codex/OpenCode/OpenClaw） |
| prompt + shell 双重校验 | 确定性用代码，创造性用 AI |
详细对比
核心维度
| 维度 | Superpowers | OpenSpec | GSD | SillySpec |
|---|---|---|---|---|
| 类型 | Skills 插件 | npm CLI + TS | Skills 插件 | Slash Commands |
| 核心关注 | AI 行为规范 | 规范结构化 | 上下文工程 | 端到端流程 |
| 安装方式 | 插件市场 / 手动 | npm install | npx | 一个 shell 脚本 / PS 一行 |
| 流程串联 | ⚠️ 按 skill 链条触发 | ⚠️ 有但不强调 | ✅ phase 驱动 | ✅ init→...→archive |
| 绿地项目 | ⚠️ 有 brainstorm | ❌ 不支持 | ✅ new-project | ✅ init |
| 棕地项目 | ⚠️ 有 worktree 隔离但无代码扫描 | ✅ 支持棕地 | ✅ map-codebase | ✅ scan（交互式引导 + 三道防线） |
| 上下文管理 | ❌ 不管 | ⚠️ 建议清上下文 | ✅ STATE.md + 子代理纯净上下文 | ✅ STATE.md 自动维护 |
| 数据库防幻觉 | ❌ 不管 | ❌ 不管 | ⚠️ 扫描但无框架规则检测 | ✅ schema + 框架规则 + 基类字段 |
| 原型图/大模块 | ❌ 不管 | ❌ 不管 | ❌ 不管 | ✅ 分析 + 拆分 + MASTER.md |
| 多项目工作区 | ❌ | ❌ | ✅ worktree/clone 隔离 | ✅ 子项目管理 + 共享规范 |
| 多 AI 工具 | ✅ 4 种 | ✅ 20+ | ✅ 8 种运行时 | ✅ 6 种 |
| 规范复用 | ❌ | ✅ skills 生态 | ❌ | ✅ export 全局模板库 |
| 格式校验 | ✅ Hard Gate | ✅ TypeScript schema | ⚠️ XML 格式 + verify | ✅ shell 脚本 |
| 确定性 | 纯 prompt | TS schema 校验 | prompt + XML 格式 | prompt + shell 脚本 |
| 上手门槛 | 低 | 中 | 低 | 极低 |
各工具优缺点
Superpowers
优点：
- brainstorming 是最好的需求探索方法论
- HARD GATE 防止 AI 跳步骤
- 99.6K star，社区活跃
- 支持 4 种工具（Claude/Cursor/Codex/OpenCode）
缺点：
- 各 skill 独立，无完整的端到端流程串联
- 没有代码扫描能力，不了解现有项目
- 不管理上下文，长会话会丢失信息
- 不支持多项目工作区
OpenSpec
优点：
- TypeScript 实现确定性高，schema 校验严格
- 规范是结构化数据，支持 diff/merge
- 适配器模式支持 20+ AI 工具
- 明确支持棕地项目
缺点：
- 安装配置较重（Node.js 20+ + npm）
- 没有完整的开发流程串联
- 不管理上下文和状态恢复
- 不支持多项目工作区
- 不扫描框架隐形规则
GSD
优点：
- 上下文工程最强：STATE.md + 子代理纯净上下文
- 每个 Plan 独立子代理，200k token 零垃圾
- 8 种运行时，覆盖面广
- 有多项目工作区（worktree/clone）
- 有 verify-work 做阶段验证
缺点：
- 没有"大模块拆分"概念，一个 Phase 内不能迭代设计
- 不扫描框架隐形规则（多租户/审计字段等）
- 不支持原型图分析
- 流程按 phase 组织，但 phase 间设计不迭代
SillySpec
优点：
- 端到端流程串联 + 三道防幻觉扫描
- 原型图分析 + 大模块拆分（其他三个都没有）
- 框架隐形规则 + 实体继承规范扫描（其他三个都没有）
- STATE.md 每个命令自动维护
- 多工具适配 + 多项目工作区
- prompt + shell 双重校验
缺点：
- 确定性依赖 AI（prompt + shell），不如 OpenSpec 的 TS schema 严格
- 单人开发，生态不成熟
- 不支持插件扩展
- prompt 工程的固有限制（上下文窗口、模型差异）
该选哪个？
选 SillySpec 如果：
- 需要端到端完整流程，不想自己拼装
- 有原型图/大模块需要分析和拆分
- 项目有框架隐形规则（多租户、审计字段、实体基类等）
- 多工具或多项目场景
选 OpenSpec 如果：
- 需要多人协作 + 严格的 schema 校验
- 规范要作为结构化数据管理
- 需要 20+ AI 工具适配
选 GSD 如果：
- 上下文管理是第一优先级
- 需要多项目工作区（worktree 隔离）
- 项目大但模块边界清晰（不需要设计迭代）
选 Superpowers 如果：
- 只需要 brainstorming + TDD 增强
- 已有自己的流程，只缺 AI 行为规范
- 用 Cursor/Codex/OpenCode（Superpowers 都支持）