sprint-flow
- Repo stars 0
- Author updated Live
- Author repo skills-registry
- Domain
- Engineering
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @tomevault-io · no license declared
- Token usage
- Moderate
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- Python
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: sprint-flow
description: > Use when this capability is needed. | 单一入口 | 用户只需调用 /sprint-flow,自动串联全流程 | | 自动流水线 | 类似 autopl…
category: engineering
runtime: Python
---
# sprint-flow output preview
## PART A: Task fit
- Use case: > Use when this capability is needed. | 单一入口 | 用户只需调用 /sprint-flow,自动串联全流程 | | 自动流水线 | 类似 autoplan,自动执行多个阶段 | | 关键节点暂停 | APPROVED 确认、Gate 1 通过、Ship 确认、⚠️ Phase 4 必须人工 | | 承认 Emergent | 用户验收环节必须人工,无法自动化(78% 失败不可见) | | 复用现有 Skills | 不重新发明,整合调用现有体系 | runs entirely locally; runs on Python. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “核心原则 / 完整流程(默认无参数) / 暂停点设计(不是随时停,而是设计明确的暂停点)” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “> Use when this capability is needed. | 单一入口 | 用户只需调用 /sprint-flow,自动串联全流程 | | 自动流水线 | 类似 autoplan,自动执行多个阶段 | | 关键节点暂停 | APPROVED 确认、Gate 1 通过、Ship 确认、⚠️ Phase 4 必须人工 | | 承认 Emergent | 用户验收环节必须人工,无法自动化(78% 失败不可见) | | 复用现有 Skills | 不重新发明,整合调用现有体系 | runs entirely locally; runs on Python. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “核心原则 / 完整流程(默认无参数) / 暂停点设计(不是随时停,而是设计明确的暂停点)” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source mentions slash commands such as `/sprint-flow`, `/to-issues`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, run shell commands.
Start with a small task and check whether the result follows “核心原则 / 完整流程(默认无参数) / 暂停点设计(不是随时停,而是设计明确的暂停点)”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: sprint-flow
description: > Use when this capability is needed. | 单一入口 | 用户只需调用 /sprint-flow,自动串联全流程 | | 自动流水线 | 类似 autopl…
category: engineering
source: tomevault-io/skills-registry
---
# sprint-flow
## When to use
- > Use when this capability is needed. | 单一入口 | 用户只需调用 /sprint-flow,自动串联全流程 | | 自动流水线 | 类似 autoplan,自动执行多个阶段 | | 关键节点暂停…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “核心原则 / 完整流程(默认无参数) / 暂停点设计(不是随时停,而是设计明确的暂停点)” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "sprint-flow" {
input -> user goal + target files + boundaries + acceptance criteria
context -> 核心原则 / 完整流程(默认无参数) / 暂停点设计(不是随时停,而是设计明确的暂停点)
rules -> SKILL.md triggers / order / output contract
runtime -> Python | read files, write/modify files, run shell commands | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Sprint Flow Skill
核心原则
| 原则 | 说明 |
|---|---|
| 单一入口 | 用户只需调用 /sprint-flow,自动串联全流程 |
| 自动流水线 | 类似 autoplan,自动执行多个阶段 |
| 关键节点暂停 | APPROVED 确认、Gate 1 通过、Ship 确认、⚠️ Phase 4 必须人工 |
| 承认 Emergent | 用户验收环节必须人工,无法自动化(78% 失败不可见) |
| 复用现有 Skills | 不重新发明,整合调用现有体系 |
完整流程(默认无参数)
调用 /sprint-flow "[需求描述]" 后,自动执行以下流程:
Phase 0: THINK → brainstorming → ⚠️ HARD-GATE: 设计未批准 → 不可进入实现 → Design Document
Phase 1: PLAN → autoplan → ⚠️ (如有taste_decisions,暂停等用户确认)
→ delphi-review → ⚠️ (等待 APPROVED)
→ 自动生成 specification.yaml(无需独立 skill)
Phase 2: BUILD → ⚠️ GITHOOKS-GATE: 检查并安装 Git Hooks(缺失→阻断)
→ dispatching-parallel-agents (并行检测) + executing-plans (隔离执行)
→ test-driven-development (RED→GREEN→REFACTOR)
→ freeze (盲评隔离) → requesting-code-review → unfreeze
→ verification-before-completion → ⚠️ (验证失败超过 max 3)
→ MVP v1
Phase 3: REVIEW → delphi-review --mode code-walkthrough → test-specification-alignment
→ browse → ⚠️ (验证失败)
Phase 4: ⚠️ ⚠️ USER ACCEPTANCE → 必须人工验收 → Emergent Issues List
Phase 5: FEEDBACK → learn + retro(工程回顾)+ systematic-debugging(根因调试)
Phase 6: SHIP → finishing-a-development-branch (4 选项) → ship / land-and-deploy
→ canary → Sprint Summary
→ IF emergent issues → Sprint 2
暂停点设计(不是随时停,而是设计明确的暂停点)
| 暂停点位置 | 触发条件 | 用户操作 | 自动恢复条件 |
|---|---|---|---|
| Phase 0 | ⚠️ 设计未 APPROVED (HARD-GATE) | 根据反馈修改设计 | 设计 APPROVED 后继续 |
| Phase 1 | autoplan surfacing taste_decisions | 用户确认每个决策 | 确认后自动继续 |
| Phase 1 | delphi-review 未 APPROVED | 修复并重新评审 | APPROVED 后自动继续 |
| Phase 2 | 验证失败超过 max 3 | 用户决定修复或放弃 | 验证通过后自动继续 |
| Phase 2 | 成本超阈值 | 用户决定继续或暂停 | 用户确认后自动继续 |
| Phase 3 | browse 发现问题 | 回退 Phase 2(不暂停) | 验证通过后自动继续 |
| Phase 4 | ⚠️ 必须人工验收 | 用户实际使用后确认 | 用户确认后继续 |
| Phase 6 | finishing-a-development-branch | 用户选择 4 选项 (merge/PR/discard/keep) | 确认后自动继续 |
| Phase 6 | ship PR 创建(PR 路径) | 用户确认合并 | 合并后自动继续 |
各 Phase 调用的 Skills
Phase 0: THINK(需求探索与设计)
brainstorming(superpowers) — HARD-GATE: 设计未批准 → 不可进入实现- 输出: 结构化设计文档 → 直接作为 Phase 1 PLAN 的输入
- 替代原因: office-hours 的 YC 六问适合新产品方向验证,brainstorming 的"设计批准才可进入实现"机制更适合 sprint-flow 场景
Phase 1: PLAN(共识评审)
autoplan(gstack) — CEO → Design → Eng 自动流水线delphi-review— 多轮匿名评审直到共识to-issues— 将 APPROVED 的 PRD/spec 拆解为垂直切片 Issue(HITL/AFK + 依赖图 + effort 估算)- specification.yaml — 自动生成(含 User Stories 段)
条件分支逻辑:
- IF autoplan AUTO_APPROVED + 无 taste_decisions → 跳过 delphi-review
- IF autoplan NEEDS_REVIEW OR taste_decisions > 0 → 调用 delphi-review
- delphi-review APPROVED → 生成 specification.yaml(含 user_stories[]) → 调用 /to-issues 拆解为垂直切片 → slices-manifest.json → Phase 2 按 execution_order 执行
Phase 1→2: GITHOOKS-GATE(质量门禁安装检查)
执行时机: Phase 1 完全通过、准备进入 Phase 2 BUILD 之前.
必须执行: 运行 githooks/verify.sh 检查当前项目的 hooks 是否安装。
检查结果处理:
- ✅ 全部存在 → 直接进入 Phase 2 BUILD
- ❌ 部分/全部缺失 → 运行
githooks/install.sh安装(包括.git/hooks/pre-commit、.git/hooks/pre-push、githooks/adapter-common.sh、githooks/adapters/)- 如果 githooks/ 目录不存在于项目根目录(即当前项目不是 xgate) → 从 xgate 仓库拉取
githooks/目录结构 - 安装完成后再次
verify.sh确认
- 如果 githooks/ 目录不存在于项目根目录(即当前项目不是 xgate) → 从 xgate 仓库拉取
核心原则: 没有质量门禁的代码不可进入 BUILD 阶段。GITHOOKS-GATE 失败 → 不可编码。
Phase 2: BUILD(ralph-loop 默认 + TDD + 盲评 + 验证)
输入: slices-manifest.json(由 Phase 1 /to-issues 生成),按 execution_order 逐个执行。
默认模式: ralph-loop — 逐 REQ/切片 迭代构建。每个切片(REQ)dispatch 独立 subagent,干净上下文,全量回归测试。Token 节约 40-67%。参见 skills/ralph-loop/SKILL.md。
并行模式: 通过 --mode parallel 启用 dispatching-parallel-agents。仅分发无依赖的 AFK 切片(通过 dependency_graph 判定)。HITL 切片需人工确认后才可分发。
替代原 xp-consensus:使用 superpowers 成熟 skill 组合,保留关键行为(freeze 隔离、熔断回退、成本监控)。
| 步骤 | Skill | 说明 |
|---|---|---|
| -1 | hooks-install (githooks/scripts) |
githooks/verify.sh → 缺失则 githooks/install.sh |
| 0 | dispatching-parallel-agents (superpowers) |
检测可并行任务,并行分发独立子任务 |
| 1 | test-driven-development (superpowers) |
RED → GREEN → REFACTOR 铁律执行 |
| 2 | executing-plans (superpowers) |
在隔离 session 中执行计划,有 review checkpoint |
| 3 | freeze (gstack) |
锁定业务代码,盲评 agent 只能访问测试 |
| 4 | requesting-code-review (superpowers) |
独立 agent 盲评业务代码(隔离状态) |
| 5 | unfreeze (gstack) |
解锁业务代码 |
| 6 | verification-before-completion (superpowers) |
运行测试 + lint,证据优先 |
| 7 | 成本监控(sprint-flow 编排层) | 超阈值 BLOCK + 用户决策 |
关键行为保留(原 xp-consensus 17 状态机中的真实边缘情况):
| 原状态 | 新处理方案 |
|---|---|
CIRCUIT_BREAKER_TRIGGERED |
sprint-flow 编排层监控成本,超阈值 BLOCK + 用户决策 |
ROLLBACK_TO_ROUND1 |
verification-before-completion 失败 → 修复 max 3 次 → 仍失败 BLOCK |
GATE1_FAILED/GATE1_COMPLETE |
verification-before-completion 内置此区分 |
GATE2_RUNNING |
cso (gstack) — Phase 1-6 安全审计替代 |
SEALED_CODE_ISOLATION |
保留 freeze skill 调用 |
语言特定 TDD:通过 --lang 参数选择:
springboot-tdd/django-tdd/golang-testing
Phase 3: REVIEW + TEST(验证)
delphi-review --mode code-walkthrough— 多专家匿名代码走查(代替 cross-model-review)test-specification-alignment— 测试与 Spec 对齐验证browse(gstack) — 浏览器自动化测试k6/locust/gatling— 负载/压力测试(可选,后端项目)
负载/压力测试(可选)
- 适用项目:主要用于后端服务的压力测试 (k6/Locust/Gatling),Web 前端已有
benchmark技能覆盖 Core Web Vitals、加载时间和资源大小等性能指标 - Phase 3 技能注入:可根据项目类型自动选择合适的负载测试工具 (
k6for Go-based services,locustfor Python services,gatlingfor JVM-based services) - 集成方式:可作为 Phase 3 的可选扩展,在 code-walkthrough 之后执行,与基准测试形成完整性能验证链条
- 配置文件:通过
.sprint-load-test.yaml进行配置(待实现),包含并发用户数、持续时间、SLA 指标等参数 - 触发条件:后端项目可通过
--type backend-*自动启用,或通过--with-performance标志手动启用 - Web 项目补充说明:对于 Web 前端项目,现有的
benchmark技能已处理页面加载性能、Core Web Vitals 等前端性能指标;负载/压力测试主要针对服务器端承载能力
Phase 4: USER ACCEPTANCE(⚠️ 人工验收)
- 无 Skill — 必须人工
- ⚠️ MUST NOT be automated, skipped, or bypassed under any circumstances
- 即使用户说"赶时间"、"跳过验收"、"直接发布",也必须暂停等待用户确认
- 使用
@templates/emergent-issues-template.md检查清单
Phase 5: FEEDBACK CAPTURE(反馈捕获)
learn(gstack) — 模式记录retro(gstack) — 工程回顾:提交历史、工作模式、代码质量趋势systematic-debugging(superpowers) — 根因调试(反馈中的 bug 做根因分析,Iron Law:无调查无修复)
Phase 6: SHIP + DEPLOY(发布)
- ⚠️ GITHOOKS-GATE: 再次验证 hooks 完整性(Phase 2 的 TDD 编码已触发提交,SHIP 阶段还会再次提交)
- 运行
githooks/verify.sh→ 缺失 →githooks/install.sh→ 阻断直至修复
- 运行
finishing-a-development-branch(superpowers) — 结构化完成流:4 选项(merge / PR / discard / keep)ship(gstack) — 创建 PR(PR 路径时使用)land-and-deploy(gstack) — 合并部署canary(gstack) — 监控告警
Output Format (MANDATORY)
Sprint state is persisted as JSON in .sprint-state/sprint-state.json:
{
"id": "sprint-2026-04-26-01",
"phase": 0,
"status": "running|paused|completed",
"outputs": {
"pain_document": "docs/pain-document.md",
"specification": "specification.yaml",
"mvp": "mvp-v1/",
"review_report": "review-report.md"
},
"metrics": {
"tests_passed": 15,
"tests_failed": 0,
"coverage_pct": 85
}
}
Eval assertions check for: phase, status, outputs.specification, metrics.coverage_pct.
参数说明
默认用法(无参数)
/sprint-flow "开发访谈机器人,支持多轮对话"
# 自动执行 Think → Plan → Build → Review → Ship 全流程
# 关键节点暂停等待用户确认
--stop-at(执行到某阶段后停止)
/sprint-flow "开发访谈机器人" --stop-at plan
# → Think → Plan → 输出 specification.yaml → 停止
# 适用场景:先评审方案,后续手动决定是否继续
--resume-from(从某阶段继续)
/sprint-flow "继续 Sprint" --resume-from build --spec specification.yaml
# → 跳过 Think + Plan,直接从 Build 开始
# 适用场景:中断恢复,使用已有的 specification.yaml
--phase(只执行单个阶段)
/sprint-flow "评审代码" --phase review-only
# → 只执行 Phase 3 的评审
# 适用场景:单独验证某个阶段
--lang(指定项目语言)
/sprint-flow "开发用户认证模块" --lang springboot
# Phase 2 自动调用 springboot-tdd + springboot-verification
/sprint-flow "开发 REST API" --lang django
# Phase 2 自动调用 django-tdd + django-verification
/sprint-flow "开发并发任务调度器" --lang golang
# Phase 2 自动调用 golang-testing
--type(指定项目类型)
/sprint-flow "开发用户登录页面" --type web-nextjs
/sprint-flow "开发 REST API" --type backend-django
# 默认: 从项目文件自动检测
自动检测逻辑(按顺序检查):
| 检测条件 | 类型 |
|---|---|
package.json + next.config.js |
web-nextjs |
package.json + vite.config.ts + react 依赖 |
web-react |
package.json + vue 依赖 |
web-vue |
pubspec.yaml + flutter: |
mobile-flutter |
package.json + react-native 依赖 or ios/ + android/ |
mobile-react-native |
go.mod |
backend-go (可选 k6 负载测试) |
pom.xml |
backend-springboot (可选 gatling 负载测试) |
manage.py 或 pyproject.toml (django) |
backend-django (可选 locust 负载测试) |
| 无匹配 | backend-cli |
项目类型到 Skill 注入映射
| Phase | Backend (default) | Web Frontend | Mobile | Load/Performance Testing |
|---|---|---|---|---|
| Phase 0 (THINK) | brainstorming |
(同) | (同) | (通用) |
| Phase 1 (PLAN) | autoplan + delphi-review |
+ design-shotgun |
(同 web) | (同) |
| Phase 2 (BUILD) | TDD + blind-review | (同 backend) | + vercel-react-native-skills (RN) / flutter-review (Flutter) |
(同) |
| Phase 3 (REVIEW) | delphi-review --mode code-walkthrough + test-specification-alignment + k6 / locust / gatling |
+ qa + design-review + benchmark |
Flutter: flutter-test / RN: detox E2E |
k6/locust/gatling (补充 API 测试后的负载测试验证) |
| Phase 5 (FEEDBACK) | learn + retro |
(同) | (同) | (同) |
| Phase 6 (SHIP) | finishing-a-development-branch + ship |
(同) | + platform deploy (可选) | (同) |
| Browse | localhost:3000 |
部署 URL + 表单/交互 | Flutter Web / RN Web 测试 | (专用负载测试) |
Mobile 专属工具链:
- Flutter:
flutter analyze,flutter test,flutter build,pub publish - React Native:
metro,detox,jest,react-native run-ios/android
状态管理
Sprint State
Sprint State:
id: sprint-YYYY-MM-DD-NN
phase: [0-6] # 当前执行阶段
status: [pending, running, paused, completed, failed] # 统一状态
pause_reason: [none, wait_approved, wait_gate1, wait_uat, wait_ship, wait_user_confirm]
存储位置: <project-root>/.sprint-state/
├─ sprint-state.yaml # 当前 Sprint 状态
└─ phase-outputs/
├─ pain-document.md # Phase 0 输出
├─ specification.yaml # Phase 1 输出
├─ mvp-v1/ # Phase 2 输出
├─ review-report.md # Phase 3 输出
├─ emergent-issues.md # Phase 4 输出
├─ feedback-log.md # Phase 5 输出
└─ sprint-summary.md # Phase 6 输出
Sprint 2 自动触发机制
Sprint 结束时 (Phase 6 完成):
IF emergent_issues_count == 0 → sprint_completed,结束流程
IF emergent_issues_count > 0 → sprint_2_needed:
├─ IF emergent_issues 有 Critical → 自动启动 Sprint 2
├─ IF emergent_issues 仅 Major/Minor → 询问用户
└─ Sprint 2 Pain Document 自动从 emergent-issues.md 转化
使用示例
示例 1:完整流程
/sprint-flow "开发访谈机器人,支持多轮对话"
# 输出:
# Phase 0: brainstorming 需求探索 → 设计文档 → ⚠️ HARD-GATE: 等待用户 APPROVED
# 用户 APPROVED → 自动进入 Phase 1
# Phase 1: autoplan 发现 2 个 taste_decisions → ⚠️ 暂停
# 用户确认决策后 → delphi-review → Round 1 REQUEST_CHANGES
# 修复 → Round 2 APPROVED → specification.yaml
# Phase 2: TDD + freeze + review → verification → MVP v1
# Phase 3: cross-model-review APPROVED → browse QA 通过
# Phase 4: ⚠️ 用户验收 → 发现 1 个 Major emergent issue
# Phase 5: learn → 记录 → Sprint 2 Pain Document
# Phase 6: ship → PR → 用户确认合并 → canary 监控
# → Sprint Summary → 发现 emergent issue → 提示是否开始 Sprint 2
示例 2:中断恢复
# 第一次:执行到 Plan 后停止
/sprint-flow "开发用户认证模块" --stop-at plan
# → 输出 specification.yaml
# 第二次:三天后继续
/sprint-flow "继续开发" --resume-from build --spec docs/specification.yaml
# → 跳过 Think + Plan,直接从 Build 开始
示例 3:语言特定
/sprint-flow "开发 REST API" --lang django
# Phase 2 自动调用 django-tdd + django-verification
# Gate 1 包含 Django 特定的验证(migrations, linting, coverage)
示例 4:使用 --mode parallel(旧有并行模式)
/sprint-flow "修改单行配置" --mode parallel
# 小改动可使用旧有并行模式,一次 dispatch 完成
# 注意:默认 ralph-loop 模式已覆盖绝大多数场景
底层 Skills 保持独立
所有被调用的 Skills 保持独立可用:
- 用户可以直接调用
delphi-review单独评审 - 用户可以直接调用
test-driven-development单独执行 TDD - sprint-flow 只是自动串联调用,不替代底层 Skills
References
详细指令文件位于 @references/:
@references/phase-0-think.md— Phase 0 详细指令@references/phase-1-plan.md— Phase 1 详细指令@references/phase-2-build.md— Phase 2 详细指令@references/phase-3-review.md— Phase 3 详细指令@references/phase-4-uat.md— Phase 4 详细指令(人工)@references/phase-5-feedback.md— Phase 5 详细指令@references/phase-6-ship.md— Phase 6 详细指令
Templates
模板文件位于 @templates/:
@templates/pain-document-template.md— Pain Document 模板@templates/emergent-issues-template.md— Emergent Issues 检查清单@templates/sprint-summary-template.md— Sprint Summary 模板
研究证据
| 证据 | 来源 | 应用 |
|---|---|---|
| One-shot = 单次迭代执行 | Boris Cherny interview | Phase 2 设计 |
| 80% session 从 Plan Mode 开始 | Boris skill | Phase 1 设计 |
| Verification improves 2-3x | Boris #1 tip | Phase 3 设计 |
| Emergent requirements 无法消除 | Mike Cohn, Rafael Santos | Phase 4 人工设计 |
| 78% failures invisible | arXiv research | Phase 4 必要性证明 |
| Think → Plan → Build → Ship | gstack ETHOS | 整体流程设计 |
Source: boyingliu01/xgate — distributed by TomeVault.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review