sprint-status

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Sprint Status

Sprint 状态

When running multiple Claude Code sessions in parallel, confusion is the enemy. This skill ensures every session identifies itself and every step reports its state.

并行运行多个 Claude Code 会话时，混淆就是最大的敌人。此 skill 确保每个会话都能表明自己的身份，并让每个步骤都报告其状态。

Session Identification

会话标识

Every response that involves a decision, plan, or significant action starts with orientation:

text

SESSION: my-app | branch: feat/auth | task: Add JWT refresh tokens

This takes one line. It costs almost nothing. It prevents the user from applying feedback to the wrong session.

每个涉及决策、计划或重要操作的响应，都以下列会话标识开头：

text

SESSION: my-app | branch: feat/auth | task: Add JWT refresh tokens

这只需一行，几乎不产生额外成本。它可以防止用户将反馈应用到错误的会话。

Detecting Parallel Sessions

检测并行会话

Check for sibling Claude Code processes:

bash

pgrep -af "claude" | grep -v "$$" | head -5

Or check for active worktrees:

bash

git worktree list 2>/dev/null

Or look for session markers (written by session-start.js / session-end.js):

bash

ls $TMPDIR/pro-workflow/sessions/ 2>/dev/null | tail -5

If multiple sessions are detected, always include the session identification header. If only one session is running, include it at task boundaries and before presenting options.

检查同级 Claude Code 进程：

bash

pgrep -af "claude" | grep -v "$$" | head -5

或者检查活跃的 worktree：

bash

git worktree list 2>/dev/null

或者查看会话标记（由 session-start.js / session-end.js 写入）：

bash

ls $TMPDIR/pro-workflow/sessions/ 2>/dev/null | tail -5

如果检测到多个会话，始终包含会话标识头。如果只有一个会话正在运行，则在任务边界以及向用户提供选项之前包含该标识。

Status Lines

状态行

End every major step with exactly one status line. No ambiguity.

每个主要步骤都必须恰好以一行明确的状态结束，不得存在歧义。

STATUS: COMPLETE

All work for the current step is done. Ready to commit, merge, or move to the next task.

text

STATUS: COMPLETE
  Changed: src/auth/refresh.ts, src/auth/refresh.test.ts
  Tests: 14 pass, 0 fail
  Ready to commit.

当前步骤的所有工作均已完成。可以提交、合并，或进入下一项任务。

text

STATUS: COMPLETE
  Changed: src/auth/refresh.ts, src/auth/refresh.test.ts
  Tests: 14 pass, 0 fail
  Ready to commit.

STATUS: COMPLETE_WITH_NOTES

Done, but flagging something the user should know about.

text

STATUS: COMPLETE_WITH_NOTES
  Changed: src/api/upload.ts
  Tests: 8 pass, 0 fail
  Notes:
    - Upload size limit is hardcoded to 10MB, should be configurable
    - No rate limiting on this endpoint yet (separate task)

Notes are for things that work but could be better. Not blockers — observations.

已完成，但需要向用户标明某个应注意的事项。

text

STATUS: COMPLETE_WITH_NOTES
  Changed: src/api/upload.ts
  Tests: 8 pass, 0 fail
  Notes:
    - Upload size limit is hardcoded to 10MB, should be configurable
    - No rate limiting on this endpoint yet (separate task)

备注用于记录目前可用但仍可改进的事项。这些不是阻塞项，而是观察结果。

STATUS: BLOCKED

Cannot proceed without user input or an external dependency.

text

STATUS: BLOCKED
  Blocker: Need database migration approved before writing the ORM layer
  Waiting on: DBA approval for schema change in migrations/0042_add_tokens.sql
  Can continue: Nothing else in this task until unblocked

在未获得用户输入或外部依赖的情况下无法继续。

text

STATUS: BLOCKED
  Blocker: Need database migration approved before writing the ORM layer
  Waiting on: DBA approval for schema change in migrations/0042_add_tokens.sql
  Can continue: Nothing else in this task until unblocked

STATUS: NEEDS_INFO

Missing context to make a good decision. Asking before guessing.

text

STATUS: NEEDS_INFO
  Question: Should refresh tokens expire after 7 days or 30 days?
  Impact: Changes token cleanup job schedule and storage requirements
  Default if no preference: 7 days (more secure, standard practice)

Always provide a sensible default so the user can say "go with the default" without context-switching into the decision.

缺少作出合理决策所需的上下文。先询问，而不是猜测。

text

STATUS: NEEDS_INFO
  Question: Should refresh tokens expire after 7 days or 30 days?
  Impact: Changes token cleanup job schedule and storage requirements
  Default if no preference: 7 days (more secure, standard practice)

始终提供合理的默认值，使用户无需切换上下文即可回复“采用默认值”。

Parallel Session Patterns

并行会话模式

Pattern 1: Feature + Tests

模式 1：功能与测试

text

Session 1: feat/auth       → implementing JWT refresh
Session 2: feat/auth-tests → writing test suite for auth module

Both sessions work on the same feature but don't touch the same files. Session 2 can start writing tests against the interface before Session 1 finishes the implementation.

text

Session 1: feat/auth       → implementing JWT refresh
Session 2: feat/auth-tests → writing test suite for auth module

两个会话处理同一项功能，但不会修改相同文件。Session 2 可以先根据接口编写测试，随后 Session 1 再完成实现。

Pattern 2: Independent Features

模式 2：独立功能

text

Session 1: feat/upload     → file upload endpoint
Session 2: feat/billing    → billing webhook handler
Session 3: fix/login-bug   → login redirect fix

Completely independent. Merge order doesn't matter.

text

Session 1: feat/upload     → file upload endpoint
Session 2: feat/billing    → billing webhook handler
Session 3: fix/login-bug   → login redirect fix

这些功能完全互不依赖，合并顺序无关紧要。

Pattern 3: Stacked Changes

模式 3：堆叠式变更

text

Session 1: feat/base-types → shared type definitions (must merge first)
Session 2: feat/api        → API layer (depends on Session 1)
Session 3: feat/ui         → UI layer (depends on Session 1)

Session 1 merges first. Sessions 2 and 3 rebase after. Flag the dependency in every status update.

text

Session 1: feat/base-types → shared type definitions (must merge first)
Session 2: feat/api        → API layer (depends on Session 1)
Session 3: feat/ui         → UI layer (depends on Session 1)

Session 1 先合并。Session 2 和 Session 3 随后执行 rebase。每次状态更新都要标明该依赖关系。

When to Report Status

何时报告状态

Event	Include Status?
File edit completed	No (too granular)
Test suite run	Yes, if pass/fail changed
Phase completed (research, plan, implement)	Yes
Presenting options to user	Yes (with session header)
Hitting a blocker	Yes, immediately
Before asking a question	Yes (NEEDS_INFO)
After committing	Yes (COMPLETE)
End of session	Yes (final status)

事件	是否包含状态？
文件编辑完成	否（粒度过细）
运行测试套件	是（如果通过或失败情况发生变化）
阶段完成（调研、规划、实现）	是
向用户提供选项	是（同时包含会话标头）
遇到阻塞项	是（立即报告）
提出问题之前	是（NEEDS_INFO）
提交之后	是（COMPLETE）
会话结束时	是（最终状态）

Sprint Dashboard

Sprint 仪表板

When the user asks for status across sessions, compile a sprint view:

text

SPRINT STATUS
  Session 1: feat/auth       STATUS: COMPLETE         (ready to merge)
  Session 2: feat/upload     STATUS: BLOCKED          (waiting on S3 creds)
  Session 3: fix/login-bug   STATUS: COMPLETE_WITH_NOTES (works, needs perf review)

当用户询问各会话的总体状态时，汇总 sprint 视图：

text

SPRINT STATUS
  Session 1: feat/auth       STATUS: COMPLETE         (ready to merge)
  Session 2: feat/upload     STATUS: BLOCKED          (waiting on S3 creds)
  Session 3: fix/login-bug   STATUS: COMPLETE_WITH_NOTES (works, needs perf review)

Anti-Patterns

反模式

Skipping the session header when multiple sessions are active
Using STATUS: COMPLETE when there are known issues (use COMPLETE_WITH_NOTES)
Burying the status line in a paragraph (put it on its own line, at the end)
Reporting status after every single edit (only at meaningful boundaries)
Not providing a default with NEEDS_INFO (forces the user to context-switch fully)
Saying "almost done" or "mostly working" instead of a concrete status

多个会话处于活动状态时跳过会话标头
存在已知问题时仍使用 STATUS: COMPLETE（应使用 COMPLETE_WITH_NOTES）
将状态行埋在段落中（应单独成行并放在末尾）
每次单次编辑后都报告状态（仅在有意义的边界报告）
NEEDS_INFO 时不提供默认值（会迫使用户完全切换上下文）
使用“差不多完成了”或“基本可用”之类模糊表述，而不是给出明确状态

Add to CLAUDE.md

添加到 CLAUDE.md

markdown

undefined

markdown

undefined

Sprint Status

Every decision and plan starts with: SESSION: project | branch | task End major steps with STATUS: COMPLETE | COMPLETE_WITH_NOTES | BLOCKED | NEEDS_INFO NEEDS_INFO always includes a sensible default. When parallel sessions are detected, always include session headers.

undefined

undefined