Most writing about automated status reports describes them. This post opens one. Generate Status Report is a public Claude skill, listed on Skills Directory in September 2026 with a security grade of A, and its full instructions are readable on GitHub under an MIT licence. Here is what it reads, what it calculates, where its thresholds come from, and what it cannot know, which is the part that decides whether you can trust its colours.
The skill's own description is a fair summary of the promise:
"...calculating metrics, identifying blockers, and summarizing progress with RAG indicators..." Generate Status Report, SKILL.md
That sounds like most of a Scrum Master's Friday. The question is how much of it survives contact with your project.
What is actually inside it
The skill is a five-step procedure written in plain English, around 1,250 words. Nothing in it is code. It tells Claude what to read, what to work out, and what to write.
| Step | What it tells Claude to do |
|---|---|
| 1. Read the artifacts | Look for PROJECT-CHARTER.md, BACKLOG.md, SPRINT-PLAN.md, WBS.md and earlier status reports, and work with whichever exist |
| 2. Calculate metrics | Velocity, sprint completion, backlog burn-down and cycle time for agile work; percent complete, schedule variance and effort variance for a work breakdown |
| 3. List blockers and risks | A table with severity, owner, status and the action required, cross-checked against the charter's risks |
| 4. Summarise | Three to five accomplishments with evidence, and three to five items planned for next period |
| 5. Assign RAG and write | Red, amber or green for schedule, scope, budget and quality, then the finished report with an executive summary and decisions needed |
Two details are better than most people expect. When the data is too thin to judge a dimension, the skill tells Claude to mark it grey for "insufficient data" and say what to collect next time, rather than guessing. And its list of common pitfalls includes "all green, all the time", warning that persistent green without evidence suggests the report is not honest. Someone who has sat through steering committees wrote that.
Run those three checks on this skill and the answers are specific. Its inputs are Markdown files with fixed names. Its schedule threshold turns amber at one to two weeks behind and red beyond two. Its budget threshold stays green within 5% of plan and turns red past 15%. Its failure rule is grey, not a guess.
"Our project lives in Jira, not in Markdown files."
None of my projects has a file called BACKLOG.md. Everything is in Jira and Confluence, like everyone else's.
That is the first thing the check finds, and it is the biggest. The skill was written for a project kept as files in a folder. It will adapt to whichever of its files exist, but it has no instruction for reaching into Jira on its own.
There are two honest routes. You can export the sprint into files with those names, which is clumsy but works today. Or you can connect Claude Code to Jira through an MCP server, and edit the skill's first step to read from that connection instead of from files.
"It's public and graded A. Can't I just install it?"
Someone has already built it, it passed a security scan, and it is free. Why would I read it first?
Because a security grade answers a different question. The A on Skills Directory is a security scan result. It tells you the file is not doing anything malicious. It does not tell you whether its thresholds match your organisation's, or whether its idea of amber is yours.
Those thresholds are the skill author's defaults, and on a two-week sprint they may be generous: under this skill, a team a week behind in a two-week sprint is amber, not red. Your sponsor may see it differently. The fix is small, because the licence is MIT and the rules are plain English. Copy the skill, change the numbers to your organisation's, and keep your own version.
"A skill can't know what is really going on in my project."
The real status of my project is in three conversations nobody wrote down. No file is going to tell it that.
Correct, and the skill half admits it. Its first pitfall is "report without data": every claim should trace to an artifact or a metric. That is a strength and a boundary at the same time. It means the skill will not invent a status. It also means anything that is not written down does not exist for it.
So it cannot know that a blocker is political, that the person named as owner will not act on it, or that the sponsor quietly changed priorities in a corridor on Tuesday. Those are the parts of a status report that need someone who was in the room.
The part worth keeping
A status report skill is not a black box. This one is a page of plain instructions: what to read, what to count, where the lines are, and what to do when data is missing. You can read it in less time than it takes to write one report by hand, and once you have read it you know exactly what its colours mean.
That is the habit worth keeping for every skill you are offered. Open it before you trust it.
For a second public example built the same way, Sdlc Reports produces iteration reports and executive summaries, and the same three checks apply. For what else is already available, see our earlier post on what is already in the skills marketplace.
Sources: Generate Status Report, SKILL.md on GitHub (MIT) | Skills Directory listing | Sdlc Reports listing | Anthropic, MCP. Read 2 October 2026; the skill may have changed since.
