project-status
Skill1 starsChanged 6 months agoMITView on GitHub
Generate a weekly Project Status Report covering all active epics and initiatives your team owns. Infers status from actual signals (PRs, issue closures, comments, board movement) rather than requiring manual DRI updates. Surfaces wins, risks, stale projects, and the week ahead. Best run Monday mornings.
12 other projects use a version of this.
Adopted by
Most recently taken up by
- eranw2000/claude-maintenance-skillstheir own version, first seen Nov 8, 2026
- desertcache/agent-ostheir own version, first seen Nov 1, 2026
- lautioliver/barrilete-kittheir own version, first seen Nov 1, 2026
- MrEddieO/claude-skillstheir own version, first seen Oct 20, 2026
- Tracebrain/mcptheir own version, first seen Oct 17, 2026
- Manshooo/astral-genesistheir own version, first seen Sep 25, 2026
Other versions12 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 12
- eranw2000/claude-maintenance-skills★ 8same name
- ozgurkarahan/ai-agent-memory★ 8same name
- lautioliver/barrilete-kit★ 6same name
- AJBcoding/claude-skill-eval★ 4same name
- korchasa/flowai★ 3same name
- Manshooo/astral-genesis★ 3same name
- Tracebrain/mcp★ 1same name
- desertcache/agent-os★ 0same name
- lhs157/claude-skills★ 0same name
- markbaindesign/bain-studio★ 0same name
2 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository30 other files it gives its agents.
- setupSkill
- enrich-prsSkill
- epic-cleanupSkill
- epic-overviewSkill
- oncall-reviewSkill
- sprint-managementSkill
- sprint-statusSkill
- team-activitySkill
- team-data-syncSkill
- direct-report-prepSkill
- interview-analysisSkill
- interview-prepSkill
- peer-prepSkill
- team-analysisSkill
- today-prioritiesSkill
- weekly-snippetSkill
- bus-factorSkill
- contribution-velocitySkill
- nine-boxSkill
- project-people-mapSkill
- review-cardsSkill
- review-cyclesSkill
- review-networkSkill
- team-health-reportSkill
- task-rolloverSkill
- context-checkSkill
- prep-my-daySkill
- initiative-breakdownSkill
- product-briefSkill
- technical-deep-diveSkill
The file
We split this skill into the rules it gives an agent
8 rules. 0 are common, 7 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 8 edited versions we read keep these.
7
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
Start of sprint: "sprint kickoff status"
- Very specific: line 37
All open issues labeled epic, initiative, or batch in the team repo
- Distinctive: line 38
All open issues with sub-issues (parent issues acting as epics)
- Distinctive: line 56
Trending field: if the project board has a trending/health indicator, read it
- Distinctive: line 92
Not necessarily bad (could be deprioritized), but worth acknowledging
- Distinctive: line 170
Be honest about unknowns: If there's no signal, say "no signal" rather than guessing.
- Distinctive: line 173
Flag load imbalance: If one person is DRI on 5 things and another on 0, note it.
- Distinctive: line 174
Don't repeat old news: Only wins from the last 7 days.
“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Project Status Report
Generate a signal-based project status report by reading actual GitHub activity across all active epics and initiatives your team touches. No manual updates required from DRIs; status is inferred from PRs merged, issues closed, comments posted, and board state changes.
When to use
- Monday mornings: "project status", "what's the state of everything"
- Start of sprint: "sprint kickoff status"
- Ad hoc: "where do things stand", "project health check"
Prerequisites
- Team roster (
team.json) with member logins and project assignments - GitHub CLI (
gh) authenticated with org access - Obsidian vault for output storage
- Access to the team's GitHub Project board (project number in
team.json)
Output
A vault note saved to a configurable location (e.g., Projects/Status Reports/YYYY-MM-DD.md) plus a conversational summary highlighting items that need attention.
Process
Step 1: Identify all active epics and initiatives
Query the team's issue tracker for:
- All open issues labeled
epic,initiative, orbatchin the team repo - All open issues with sub-issues (parent issues acting as epics)
- Issues assigned to any team member that have child tasks
Build the canonical list of "things the team is responsible for." This list should be stable week-to-week (projects don't appear/disappear frequently).
Step 2: Gather activity signals (last 7 days)
For each team member:
- PRs authored: merged and open, with repo and title
- PRs reviewed: to understand cross-pollination
- Issues closed: in the team repo
- Comments on epics: any DRI-posted status updates
For each epic/initiative:
- Sub-issue movement: how many sub-issues changed status (opened, closed, moved columns)
- PR activity: PRs that reference the epic or its sub-issues
- Comments: any status updates, decisions, or blockers posted
- Board status: current column (Planned, Doing, In Review, Done, Blocked)
- Trending field: if the project board has a trending/health indicator, read it
Step 3: Infer status per project
For each epic, assign an inferred status:
| Signal | Inference |
| PRs merged + issues closed this week | 🟢 Active, making progress |
| PRs open but not merged, reviews pending | 🟡 In flight, waiting on reviews |
| Sub-issues moved to Doing/In Review | 🟡 Work started, not yet landed |
| No activity, but sprint just started | ⚪ Not started yet (OK if early sprint) |
| No activity for 7+ days on a "Doing" epic | 🔴 Stale, needs attention |
| No activity for 14+ days | 🔴 No signal, flag for check-in |
| Blocked label or blocker comments | 🔴 Blocked, surface the blocker |
Step 4: Categorize into report sections
Group findings into:
Wins (last 7 days)
- Epics or milestones completed
- Significant PRs merged that close out sprint goals
- Anything that moved from "In Progress" to "Done"
In Flight
- Active work with PRs open or issues moving
- Note who's doing what and expected landing
At Risk
- Projects with no activity that should have some
- Things approaching deadlines with incomplete work
- Blocked items with no resolution path visible
No Signal
- Epics assigned to the team with zero activity in the window
- Not necessarily bad (could be deprioritized), but worth acknowledging
Week Ahead
- Items in "Planned" that should start this week
- Upcoming deadlines (compliance, a11y audits, customer commitments)
- Anything from the sprint goals not yet on the board
Step 5: Write the report
Report format
## Project Status — YYYY-MM-DD
**Sprint:** [Sprint name] (Day N of 14)
**Report window:** [start date] → [end date]
---
### 🟢 Wins
**[Project Name]** ([#epic](url)) — @dri
- What shipped, what closed, what's done
- Specific PRs/issues with links
---
### 🟡 In Flight
**[Project Name]** ([#epic](url)) — @dri
- Current state: what's open, what's being reviewed
- Expected: when it should land
---
### 🔴 At Risk
**[Project Name]** ([#epic](url)) — @dri
- Why it's flagged: no activity / approaching deadline / blocked
- Last activity: [date]
- Suggested action: [what needs to happen]
---
### ⚪ No Signal
**[Project Name]** ([#epic](url)) — @dri
- Last activity: [date]
- Note: [deprioritized? waiting on external? just quiet?]
---
### 📅 Week Ahead
- [ ] [Thing that should start or land this week]
- [ ] [Deadline approaching]
- [ ] [Sprint goal not yet on board]
---
### DRI Update Tracker
| Person | Projects Owned | Updated This Week | Stale |
|--------|:-:|:-:|:-:|
| @name | N | N | N |Step 6: Save and summarize
- Save the full report to the vault
- Present a brief conversational summary (5-8 lines) highlighting:
- Number of projects on track vs at risk
- Top 2-3 things that need your attention this week
- Any patterns (e.g., "nobody updated anything", "Brian is carrying 4 projects")
Content guidelines
- Infer, don't require. The whole point is that DRIs don't need to manually post updates; you read the signals and write the status.
- Be honest about unknowns. If there's no signal, say "no signal" rather than guessing.
- Keep it scannable. Bold project names, use emoji status indicators, keep descriptions to 1-2 lines per project.
- Credit people. Name who shipped what.
- Flag load imbalance. If one person is DRI on 5 things and another on 0, note it.
- Don't repeat old news. Only wins from the last 7 days. Prior wins live in older reports.
- Link everything. Epic numbers, PR numbers, issue numbers. Make it clickable.
Relationship to other skills
- weekly-snippet: The snippet is YOUR update to YOUR manager. This report is the team-wide project health view that feeds into the snippet.
- sprint-status: Sprint status is focused on the current sprint board. This covers ALL active work, including things not in the sprint.
- team-activity: Team activity is raw data (PRs, reviews, issues). This is the analyzed, narrativized version.
Cadence
Best used Monday mornings as a "state of the world" before the week starts. Can also be run mid-sprint or before leadership syncs. The Monday framing lets you ask: "what landed last week, and what needs to happen this week?"
Configuration
The skill needs to know:
- Team repo: where epics/issues live (e.g.,
org/team-repo) - Project board number: for sprint/status field data
- Vault output path: where reports are saved
- Epic labels: what labels identify epics in your repo (default:
epic,initiative,batch) - DRI field: how DRI is determined (default: issue assignee)
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

