Superhuman 是一个从一开始就为 AI 智能体设计的开发生命周期。资料称，传统敏捷、瀑布、TDD 等方法围绕人类限制设计（并行有限、上下文切换成本、沟通开销、会议），而 AI 智能体没有这些限制，Superhuman 因此把工作拆解为带依赖图的子任务，按并行波次执行独立任务，在每一步强制测试优先验证，并用持久化看板跨会话记录一切。其模型包含 7 个阶段：INTAKE（信息采集）、DECOMPOSE（任务拆解）、DISCOVER（调研）、PLAN（计划）、EXECUTE（执行）、VERIFY（验证）、CONVERGE（汇合）。
【激活方式】技能被激活时，首次回复需先显示指定的 ASCII 艺术横幅，随后立即进入计划模式：若平台有原生计划模式（如 Claude Code 的 EnterPlanMode、Gemini CLI 的规划模式）则直接调用；若无，则在做出任何代码修改前完整完成 INTAKE 到 PLAN 的规划工作，并向用户呈现完整计划、获得明确批准后才进入 EXECUTE。
【会话恢复】若项目根目录已存在 .superhuman/board.md，技能会读取看板判断状态（进行中、阻塞、已完成），打印完成/进行中/阻塞/剩余任务的紧凑状态摘要，从最后一个未完成的波次继续，而不是从 INTAKE 重来；若代码库自上次会话后发生变化，会对照看板预期状态做快速差异检查并标记冲突。看板标记为已完成时，询问用户是开始新会话（把旧看板归档到 .superhuman/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）、测试运行器、Lint/格式化工具、构建系统、CI/CD、可用脚本、目录约定以及 codedocs（.codedocs.json）。若发现 codedocs 清单，会记录位置并设置 codedocs_available: true，同时立即读取 docs/OVERVIEW.md 与 docs/GETTING_STARTED.md，把技术栈、模块地图、入口点、开发命令等关键事实追加到看板的 Project Conventions 部分。
【适用与不适用】适用于：涉及 3 个以上文件或组件的多步功能开发；用户说“build this end-to-end”“plan and execute this”“break this into tasks”“sprint plan this”；任何需要计划、实现、验证的任务；绿地项目、大型重构或迁移；跨多系统的复杂缺陷修复。不适用于：单文件缺陷修复或错字更正、快速提问或代码解释、用户想在你的指导下手动完成的任务、纯研究或探索任务。
【关键原则】1）依赖优先拆解：每个任务是 DAG 中的节点而非扁平列表，依赖关系显式化，防止合并冲突、顺序错误和浪费。2）波次并行：依赖图同深度的任务构成一个波次，波次内全部并行，波次间串行。3）测试优先验证：每个子任务先写测试再实现，测试通过才算完成。4）持久状态：所有进度记录在项目根目录的 .superhuman/board.md，跨会话保留，支持恢复、审计和交接；用户需在 INTAKE 中选择看板是否纳入 git 跟踪。5）交互式信息采集：不假设，问题深度随复杂度缩放——简单任务 3 个问题，复杂任务 8-10 个，在写代码前提取需求、约束和成功标准。
【INTAKE 阶段】按复杂度提问：问题陈述、成功标准、约束为必问；中等和复杂任务追加现有代码、依赖关系；复杂任务再追问边界情况、测试策略、上线迁移、文档、优先级。此外必须询问看板是 git 跟踪还是 gitignore。结果写入 .superhuman/board.md。
【DECOMPOSE 阶段】把采集结果拆成原子子任务，每个含 ID（如 SH-001）、标题、描述、类型（code/test/docs/infra/config）、复杂度（S<50 行、M 50-200 行、L 200+ 行需再拆）、依赖列表。规则包括：测试任务与实现任务分离；基础设施/配置任务先于依赖它的代码；文档任务依赖其所记录的代码；目标 5-15 个子任务；每个任务图必须以三个强制尾部任务结束。复杂度预算会按 M 等量换算（1 L=3 M，1 S=0.5 M），超过 15 个 M 等量时提示用户范围可能过大，建议拆成多个会话。
【三个强制尾部任务】依次为：倒数第三，自代码评审——用 code-review-mastery 方法对全部改动做结构化评审，按安全 > 正确性 > 性能 > 设计 > 可读性 > 约定 > 测试自底向上执行，发现分级为 [MAJOR]/[MINOR]，立即修复全部 [MAJOR]，修复后重跑评审，直至无 [MAJOR]；倒数第二，需求验证——对照原始提示和 INTAKE 摘要逐项核验需求、成功标准、约束，未满足则回到 EXECUTE；最后，全项目验证——按顺序通过项目包管理器脚本运行测试、Lint、类型检查、构建，只运行已配置的项，任一失败需修复并重跑至全绿，否则不得将看板标记完成。
【图与波次】建图后检查无环，按深度分配波次：波次 1 为零依赖根任务，波次 N 的依赖都在前序波次。随后生成 ASCII 依赖图和波次分配表，呈现给用户并等待明确批准后才继续。资料中的示例展示了初始化、数据库、用户模型、认证模型、API 路由、认证端点、集成测试、API 文档等任务以及尾部评审、需求验证、全项目验证的依赖关系与波次划分。
【DISCOVER 阶段】在规划实现前对每个子任务做调研，该阶段可按波次并行。资料在此处截断，后续 PLAN、EXECUTE、VERIFY、CONVERGE 的详细步骤暂未提供，官方介绍文本也未提供；关于收费、价格、平台支持范围等事实暂未提供。