Skip to main content
An Auditor That Reads the Epic Before the Sprint Starts
Claude CodeSkillsAgile

An Auditor That Reads the Epic Before the Sprint Starts

·2 min read
audit 3 of 6 scope: 1 epic + its storiesSource on GitHub

Most sprint pain isn't the work, it's starting a sprint on stories that were never actually ready. You find out on day 3, when someone is blocked on an acceptance criterion nobody wrote. I wanted that discovery moved to day zero, which means reading an epic the way a skeptical tech lead would, before the team commits to it.

What it actually is

Point it at an epic - or a whole batch of them - and it pulls the live child issues, reads the actual story content, and runs a pre-sprint gate check on each one. Does the story explain what "done" means? Are there dangling dependencies? Is anything a blocker wearing a normal ticket's clothes? It surfaces the risks and the not-ready stories and lays it all out in 1 report I can scan before planning.

The point isn't to grade people. It's to catch the quiet stuff - the story that looks fine in the list view but falls apart the second someone tries to pick it up.

In practice

I ran it across a set of epics the morning before planning. It flagged a handful of stories that read fine but had no real acceptance criteria, and 1 "small" ticket that was secretly a blocker for 3 others. That's a 15-minute read that saved a mid-sprint scramble - the kind where the whole team waits on 1 unready thing.

What I learned

The cost of a not-ready story is never just the story. It's the standup where 3 people say "blocked," the context-switch, the half-day lost while someone chases a decision that should've been made a week ago. Catching it before the sprint starts is worth more than any velocity chart.


The skill behind this is open source. Clone the 1 folder you need from bunlongheng/audits, point it at your own work, and read your next epic before the sprint reads it for you.