Super-Human 是面向 AI 智能体的开发生命周期，宣称从零为 AI 智能体设计，以替代围绕人类约束（并行度有限、上下文切换成本、沟通开销、会议）构建的 Agile、Waterfall、TDD 等传统方法。其核心思路是将工作分解为带依赖关系的子任务图，让无依赖任务并行执行，并在每一步强制测试优先验证，全部进度记录在可跨会话存续的持久看板上。
用途与激活
该技能在用户表达“plan and build”“break this into tasks”“build this feature end-to-end”“sprint plan this”等意图时触发，适用于需要“计划+实现+验证”的多步骤任务、触及 3 个以上文件或组件的功能开发、绿地项目、大型重构或迁移，以及跨多个系统的复杂缺陷修复。单文件缺陷修复或拼写更正、快速问答或代码解释、用户希望手动完成并仅需指导的任务、纯研究或探索任务不建议使用。
每次调用时，在输出任何其他内容之前必须显示指定的 ASCII 艺术横幅，以提示 Super-Human 模式已激活；随后立即进入计划模式。若平台有原生计划模式（如 Claude Code 的 EnterPlanMode、Gemini CLI 的 planning mode），需调用该机制；若无原生计划模式，则通过完整执行 INTAKE 到 PLAN 四个规划阶段来模拟，并在进入 EXECUTE 之前将完整计划提交用户显式批准。在用户批准计划且进入第 5 阶段之前，不应创建或修改任何文件。
会话恢复
若项目根目录已存在 .super-human/board.md，系统会读取看板并判断状态（进行中、受阻、已完成），打印已完成/进行中/受阻/剩余任务的紧凑摘要，从最后一个未完成的波次继续，而不是从 INTAKE 重启；若代码库自上次会话以来有变化（手动编辑、其他提交），会对照看板预期状态做快速差异检查并标记冲突。若看板标记为完成，则询问用户是归档旧看板到 .super-human/archive/ 并开启新会话，还是审查已完成工作。未经用户明确确认，不得清除已有看板。
代码库约定检测
在 INTAKE 开始前，自动扫描关键文件以检测项目约定，包括包管理器（package-lock.json、yarn.lock、pnpm-lock.yaml、bun.lockb、Cargo.lock、go.sum）、语言/运行时（tsconfig.json、pyproject.toml/setup.py、go.mod、Cargo.toml）、测试运行器（jest.config.、vitest.config.、pytest.ini、.mocharc.、测试目录模式）、Linter/Formatter（.eslintrc.、eslint.config.、.prettierrc.、ruff.toml、.golangci.yml）、构建系统（Makefile、webpack.config.、vite.config.、next.config.*、turbo.json）、CI/CD（.github/workflows/、.gitlab-ci.yml、Jenkinsfile）、可用脚本（package.json 的 scripts 段、Makefile 目标）、目录约定（src/、lib/、app/、tests/、tests/、spec/）以及 codedocs（.codedocs.json）。检测结果写入看板的“## Project Conventions”部分，并在后续阶段引用。若发现 .codedocs.json 清单，则记录其位置并设置 codedocs_available: true，同时立即读取 docs/OVERVIEW.md 和 docs/GETTING_STARTED.md，将技术栈、模块图、入口点、开发命令等关键事实追加到看板。
七个阶段
流程为 INTAKE → DECOMPOSE → DISCOVER → PLAN → EXECUTE → VERIFY → CONVERGE，对应收集上下文 → 构建 DAG 与波次 → 按任务研究 → 按任务细化 → 并行波次执行 → 测试与验证 → 合并与收尾。
INTAKE（交互式访谈）：按复杂度调整提问深度，简单任务约 3 个问题、中等约 5 个、复杂约 8-10 个。核心问题包括问题陈述、成功标准、约束；扩展问题包括现有代码、依赖；深度问题包括边缘情况、测试策略、上线/迁移/功能开关/向后兼容、文档更新、优先级。始终询问 .super-human/ 看板应纳入 git 跟踪（审计轨迹、跨机器恢复）还是 gitignore（本地工作状态）。答案写入看板。
DECOMPOSE（创建任务图）：将需求拆成原子子任务，每个子任务包含 ID（如 SH-001）、标题、描述、类型（code/test/docs/infra/config）、复杂度（S<50 行、M 50-200 行、L 200+ 行需拆分）、依赖任务 ID。目标是 5-15 个子任务；L 任务必须进一步拆分；若总规模超过 15 个 M 等量任务（1 L=3 M，1 S=0.5 M），需提示用户范围可能过大，建议拆成多个会话，用户可显式确认后覆盖。每个任务图必须以三个强制尾部任务结束：自我代码审查、需求验证、完整项目验证。随后构建有向无环图并分配波次：Wave 1 为无依赖根任务，Wave 2 的依赖全部在 Wave 1，依此类推；生成 ASCII 依赖图和波次表，等待用户显式批准。
DISCOVER（并行研究）：按波次并行研究每个子任务。若 codedocs 可用，先查 docs/INDEX.md 定位模块文档，读 docs/modules/<module>.md 获取公共 API、内部结构、依赖与实现说明，查 docs/patterns/ 的横切模式文档，用 docs/OVERVIEW.md 理解架构上下文；文档不足时再探索代码库，并标记文档陈旧。研究还包括查找现有模式/工具/约定、确定将创建或修改的文件、检查可复用函数/类型/组件、理解测试模式，必要时做网络研究；同时进行风险与假设标记。每个智能体将发现写入看板对应任务。
PLAN（执行计划）：为每个子任务明确要创建/修改的文件路径、测试文件路径（TDD，先写测试）、实现方式、可验证的验收标准、测试用例清单（正常路径、边缘情况、错误处理）。计划需引用 DISCOVER 中发现的可复用代码并遵守项目约定；若发现缺失依赖，需更新任务图并重新获得用户批准。
EXECUTE（基于波次的实现）：执行第一波前创建 git 安全网，确保更改已提交或暂存，在“## Rollback Point”记录当前提交哈希，以便灾难性失败时用 git reset --hard 回滚，并在标记不可恢复失败时提醒用户该哈希。每个波次内并行处理独立任务，每个任务按 TDD 红-绿-重构循环执行：先写测试（红），实现代码使测试通过（绿），必要时重构，最后把看板状态从 in-progress 更新为 verifying；等待波次内所有任务完成后再做波次边界检查（冲突解决、进度推进）。
VERIFY 与 CONVERGE：资料在此处截断，仅提及验证与合并收尾，具体步骤暂未提供。
关键原则与核心概念
五项原则为：依赖优先分解（每个任务是 DAG 节点而非扁平列表，依赖显式，避免合并冲突与顺序缺陷）、波次并行（同一深度任务同时执行，波次按序串行）、测试优先验证（每个子任务先写测试，测试通过才算完成）、持久状态（进度记录在 .super-human/board.md，跨会话恢复、审计与交接）、交互式 intake（不假设，按复杂度调整提问深度）。核心概念包括 7 阶段、任务图（DAG）、执行波次、看板（唯一事实来源）、子任务生命周期（pending → researching → planned → in-progress → verifying → done，另有 blocked 和 failed 重试分支）。
平台与限制
资料提到在 Claude Code 与 Gemini CLI 等平台上的计划模式集成，但未提供收费、定价、安装命令或具体平台支持范围等细节，这些信息暂未提供。输出中不得编造未提及的功能或效果。