Skill

Status report

Produce a weekly (or custom-window) project status report aggregating shipped work, in-flight items, blockers, and risks from Notion, Slack, and GitHub. Drafts only — publishing goes through confirmation.

npx claudepluginhub sitloboi2012/team-marketplace --plugin role-pgm

Tool Access

This skill uses the workspace's default tool permissions.

Preview

**Invocation: user only.**

SKILL.md

Similar Skills

cache-components

139.3k

Guides Next.js Cache Components and Partial Prerendering (PPR): 'use cache' directives, cacheLife(), cacheTag(), revalidateTag() for caching, invalidation, static/dynamic optimization. Auto-activates on cacheComponents: true.

cache-components

mcp-builder

124.2k

Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).

9 files

anthropics-skills-13

Stats

Parent Repo Stars0

Parent Repo Forks0

Last CommitApr 23, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

Status report

Invocation: user only.

Workflow

1. Scope

Parse $ARGUMENTS:

Project: specific project or "all" (default all active projects from the project tracker)
Window: this week, last week, a date range, or default to Mon→now

If "all" and there are >5 active projects, ask the user to pick or confirm.

2. Pull

For each project in scope, in parallel:

Notion: project page for current state, milestones with their status, owner changes.
Slack: project channel in the window. Surface: status-update-looking messages, anyone saying "blocked" / "waiting on" / "delayed" / "done".
GitHub (if available): merged PRs, open PRs >3 days old, linked issues closed.
Risk log: open risks tagged to this project.

3. Classify

For each project, produce:

Shipped this window — concrete outcomes, not activity ("launched export API" not "worked on export")
In flight — what's moving now, % complete if declared, owner, expected landing
Blockers — explicit blocks. Each needs: what, owner to unblock, how long it's been blocked
Risks — open risks from the risk log, severity ≥ Medium
Decisions needed — things waiting on a call from leadership or a peer team

A "blocker" is a specific thing stopping specific work. "Capacity" is not a blocker unless the capacity is missing for an identified reason.

4. Draft the report

# Status — <date range>

**TL;DR** <one sentence. Biggest signal. "On track except X." or "Two new blockers this week.">

## Project: <name>

**Owner:** <person>  ·  **Health:** 🟢 on track | 🟡 watch | 🔴 at risk

**Shipped this window**
- <item>

**In flight**
- <item> — <owner> — <% or "started/mid/wrapping"> — landing <date>

**Blockers**
- <blocker> — blocked <N days> — needs <owner to unblock>

**Risks**
- <risk> (<severity>) — <mitigation status>

**Decisions needed**
- <decision> — by <date>

---

[repeat per project]

## Cross-cutting notes
<anything that affects multiple projects>

Health rubric:

🟢 on track: no unresolved blockers, no risks at High+, pace matches plan
🟡 watch: one factor is off but recoverable this window
🔴 at risk: without intervention, we miss the next milestone

Be honest with the color. A green light that should be yellow is the worst kind of report.

5. Review and publish

Show the draft. Ask:

Any health calls the user disagrees with?
Anything confidential that should be scrubbed for this audience?
Destination: Notion (which page?) + Slack post (which channel?) + email (to whom?)

Publish only after approval. Use /team-core:draft-email flow for email.

Don't

Don't list every PR merged — report ships, not activity.
Don't flag a risk as mitigated without evidence.
Don't change a project's health color without noting why in "cross-cutting notes."