Sprint Status Snapshot

Stale Story Detection

After collecting status for all stories, check each IN PROGRESS story for staleness:

• Resolve the dates with one grep across the story set, not a read per story — a date is a single line, and opening every in-progress story to find it is the whole cost of this check:

  Grep pattern="\*{0,2}(Last Updated|Updated|last-updated|updated_at)\*{0,2}[[:space:]]*:" glob="production/epics/**/story-*.md" output_mode="content"

  That one pattern accepts every field-name variant. A story with no match has no date, which is not the same as being stale — report it as "never stamped" and do not compute an age for it.

The \*{0,2} wrappers are why this works at all. /create-stories emits > **Last Updated**: …, so a pattern requiring : immediately after the word matched no story ever written. Combined with the "no match = never stamped" rule directly above — which is correct in itself — the failure was completely silent: every in-progress story reported as never stamped, and stale-story detection never once fired. A bare Updated: anchor will regress it.

• Calculate days since that date using today's date.
• If the date is more than 4 days ago, flag the story as STALE. (4-day threshold accounts for weekends — a story last touched on Friday won't appear stale until Wednesday.)
• If no date field is found in the story file, note "no timestamp — cannot check staleness."
• If the story has no referenced file (inline task), note "inline task — cannot check staleness."

STALE stories are included in the output table and collected into an "Attention Needed" section (see Phase 5 output format).

Stale story escalation: If any IN PROGRESS story is flagged STALE (no progress in 4+ days), the burndown verdict is upgraded to at least At Risk — even if the completion percentage is within the normal On Track window. Record this escalation reason: "At Risk — [S] stale story(ies): [title] ([D] days)[, …]" — [S] is how many stories are STALE, and each is named with its own [D], the days since its own Last Updated date (not the oldest age, not an average).

4. Burndown Assessment

Calculate:

• Tasks complete (DONE or COMPLETE)
• Tasks in progress (IN PROGRESS)
• Tasks blocked (BLOCKED)
• Tasks not started (NOT STARTED or MISSING)
• Completion percentage: (complete / total) * 100

Assess burndown by comparing completion percentage to time consumed percentage:

• On Track: completion % is within 10 points of time consumed % or ahead
• At Risk: completion % is 10-25 points behind time consumed %
• Behind: completion % is more than 25 points behind time consumed %

If dates are unavailable, skip the burndown assessment and report "On Track / At Risk / Behind: unknown — sprint dates not found."

5. Output

Keep the output concise. The story status table is mandatory — do not truncate it. Aim for under 50 lines total; omit the Emerging Risks section if nothing notable was found. Use this format:

## Sprint [N] Status — [Today's Date]
**Sprint Goal**: [from sprint plan]
**Days Remaining**: [N] of [total] ([% time consumed])

### Progress: [complete/total] tasks ([%])

| Story / Task         | Priority   | Status      | Owner   | Blocker        |
|----------------------|------------|-------------|---------|----------------|
| [title]              | Must Have  | DONE        | [owner] |                |
| [title]              | Must Have  | IN PROGRESS | [owner] |                |
| [title]              | Must Have  | BLOCKED     | [owner] | [brief reason] |
| [title]              | Should Have| NOT STARTED | [owner] |                |

### Attention Needed
| Story / Task         | Status      | Last Updated   | Days Stale | Note           |
|----------------------|-------------|----------------|------------|----------------|
| [title]              | IN PROGRESS | [date or N/A]  | [N days]   | [STALE / no timestamp — cannot check staleness / inline task — cannot check staleness] |

*(Omit this section entirely if no IN PROGRESS stories are stale or have timestamp concerns.)*

### Burndown: [On Track / At Risk / Behind]
[1-2 sentences. If behind: which Must Haves are at risk. If on track: confirm
and note any Should Haves the team could pull.]

### Must-Haves at Risk
[List any Must Have stories that are BLOCKED or NOT STARTED with less than
40% of sprint time remaining. If none, write "None."]

### Emerging Risks
[Any risks visible from the story scan: missing files, cascading blockers,
stories with no owner. If none, write "None identified."]

### Recommendation
[One concrete action, or "Sprint is on track — no action needed."]

6. Fast Escalation Rules

Apply these rules before outputting, and place the flag at the TOP of the output if triggered (above the status table):

Critical flag — if Must Have stories are BLOCKED or NOT STARTED and less than 40% of the sprint time remains:

SPRINT AT RISK: [N] Must Have stories are not complete with [X]% of sprint
time remaining. Recommend replanning with `/sprint-plan update`.

Completion flag — if all Must Have stories are DONE:

All Must Haves complete. Team can pull from Should Have backlog.

Missing stories flag — if any referenced story files do not exist:

NOTE: [N] story files referenced in the sprint plan are missing.
Run `/story-readiness sprint` to validate story file coverage.

Collaborative Protocol

This skill is read-only. It reports observed facts from files on disk.

• It does not update the sprint plan
• It does not change story status
• It does not propose scope cuts (that is /sprint-plan update)
• It makes at most one recommendation per run

For more detail on a specific story, the user can read the story file directly or run /story-readiness [path].

For sprint replanning, use /sprint-plan update. For end-of-sprint retrospective, use /retrospective.