sprint-status

スプリントのステータス

Claude Code のセッションを複数並行して実行していると、混乱が最大の敵になります。このスキルでは、各セッションが自分のセッションを識別し、各ステップで状態を報告するようにします。

セッションの識別

判断、計画、または重要な操作を伴うすべての応答は、状況説明から始めます。

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

これは1行で済みます。コストはほとんどかかりません。ユーザーが誤ったセッションにフィードバックを適用するのを防ぎます。

並行セッションの検出

兄弟関係にある Claude Code プロセスを確認します。

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

または、アクティブなワークツリーを確認します。

git worktree list 2>/dev/null

または、セッションマーカー（session-start.js / session-end.js によって書き込まれる）を探します。

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

複数のセッションが検出された場合は、必ずセッション識別ヘッダーを含めます。実行中のセッションが1つだけの場合は、タスクの区切りと選択肢の提示前に含めます。

ステータス行

大きなステップを終えるたびに、ステータス行を正確に1つ付けます。曖昧さをなくします。

STATUS: COMPLETE

現在のステップの作業がすべて完了しました。コミット、マージ、または次のタスクに進める状態です。

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

STATUS: COMPLETE_WITH_NOTES

完了しましたが、ユーザーに知らせるべき点があります。

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

ユーザーからの入力、または外部依存関係がないと先に進めません。

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

適切な判断を下すためのコンテキストが不足しています。推測せずに確認します。

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)

ユーザーがコンテキストを切り替えずに「デフォルトで進めて」と言えるよう、妥当なデフォルトを必ず提示します。

並行セッションのパターン

パターン 1：機能 + テスト

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

両方のセッションが同じ機能に取り組みますが、同じファイルには触れません。セッション 1 が実装を終える前に、セッション 2 はインターフェースを対象としたテストを書き始められます。

パターン 2：独立した機能

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

互いに完全に独立しています。マージの順序は問いません。

パターン 3：積み重ねた変更

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)

セッション 1 が先にマージします。その後、セッション 2 と 3 がリベースします。すべてのステータス更新で依存関係を明示します。

ステータスを報告するタイミング

イベント	ステータスを含める？
ファイル編集の完了	いいえ（細かすぎます）
テストスイートの実行	合否に変化があった場合は、はい
フェーズの完了（調査、計画、実装）	はい
ユーザーへの選択肢の提示	はい（セッションヘッダー付き）
ブロッカーの発生	はい、直ちに
質問する前	はい（NEEDS_INFO）
コミット後	はい（COMPLETE）
セッション終了時	はい（最終ステータス）

スプリントダッシュボード

ユーザーからセッションをまたいだステータスを尋ねられたら、スプリントの状況をまとめます。

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)

アンチパターン

• 複数のセッションがアクティブなのに、セッションヘッダーを省略する
• 問題が判明しているのに STATUS: COMPLETE を使う（COMPLETE_WITH_NOTES を使う）
• ステータス行を段落に埋め込む（独立した行にし、末尾に置く）
• 編集のたびにステータスを報告する（意味のある区切りでのみ報告する）
• NEEDS_INFO でデフォルトを提示しない（ユーザーに完全なコンテキスト切り替えを強いる）
• 具体的なステータスではなく、「もうすぐ完了」や「ほぼ動作している」と言う

CLAUDE.md に追加

## 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.