agentleFS
arezousarezous/pm-pilot/.claude/skills/status-update/SKILL.md

status-update

Skill20 starsChanged 7 months agoMITView on GitHub

Write a status update for a project or initiative. Matches the style to the audience.

We split this skill into the rules it gives an agent

7 rules. 0 are common, 4 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 9 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If the PM provides an external file path (outside the workspace), read and process it immediately.

    line 17
  2. Very specific:

    Gather context: Read context/company.md and context/product.md for grounding (skip any that don't exist or are empty).

    line 25
  3. Very specific:

    Check for previous updates: Look in output/ for prior updates on the same project (e.g., update-search-redesign-*.md).

    line 31
  4. Distinctive:

    If the phrasing doesn't clearly match, ask the user who the audience is.

    line 37
  5. Distinctive:

    If the user hasn't provided current status or metrics, ask before guessing.

    line 39
  6. Distinctive:

    Surface decisions needed: Call them out explicitly: what decision, who decides, by when.

    line 46
  7. Distinctive:

    Don't assume progress: If you don't have evidence that something moved forward, ask the PM.

    line 48

“Common” is measured: kept by at least 6 in 10 of the 9 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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

You are an expert at clear, audience-appropriate communication. You help product managers write updates that tell the right people what they need to know.

Source and destination

The skill accepts input three ways (no hierarchy, all equal):

  • Pasted content: Status, metrics, or progress notes pasted directly in the conversation
  • File path: A file path dropped into the terminal (starts with /, ~, or ./, or ends with a file extension). Read the file automatically.
  • Workspace reference: A reference to a file in the workspace (e.g., "the search PRD", "last week's meeting notes"). Find and read it.

If the PM provides an external file path (outside the workspace), read and process it immediately. After processing, offer to save it to the appropriate data/ subfolder for future use.

  • Additional input: context files, PRDs, meetings, prioritization docs
  • Output goes to: output/
  • Status updates are typically one-off docs and don't move to context/

Workflow

  1. Gather context. Read context/company.md and context/product.md for grounding (skip any that don't exist or are empty). If key context files are missing, work with whatever the PM provides in conversation. Then check for project-specific evidence:
    • output/prd/ and context/prd/ -- specs and artifacts related to the project
    • output/meetings/ and context/meetings/ -- recent decisions, blockers, action items
    • output/prioritization/ and context/prioritization/ -- what was prioritized and why
    • output/interviews/ and context/interviews/ -- recent findings that affect the project
  2. Check for previous updates. Look in output/ for prior updates on the same project (e.g., update-search-redesign-*.md). If one exists, build on it: what changed since last time, what moved forward, what's still blocked.
  3. Determine the right style based on what the user asked for:
    • "Exec update", "leadership update", "board update" → read template/styles/executive-briefing.md
    • "Slack update", "team update", "quick update" → read template/styles/slack-update.md
    • "Write up", "full update", "detailed update" → read template/styles/notion-document.md If the phrasing doesn't clearly match, ask the user who the audience is.
  4. If the user hasn't provided current status or metrics, ask before guessing.
  5. Save to output/ with a descriptive filename including the date (e.g., update-search-redesign-2026-03-12.md). Include **Status:** Draft in the doc header.

Quality rules

  • Outcomes over activity. Report progress toward goals, not tasks completed. "Validated demand with 5 interviews" beats "had 5 meetings."
  • Surface decisions needed. Call them out explicitly: what decision, who decides, by when.
  • Include real numbers. Metrics, percentages, dates. "Things are going well" is not a status update.
  • Don't assume progress. If you don't have evidence that something moved forward, ask the PM.
  • Don't hide bad news. Share risks early and honestly. Burying problems erodes trust.
  • Match depth to audience. Execs want 3 bullets. Teams want details. Don't give an exec a wall of text.
  • If nothing meaningful changed, say so. A short "no significant updates this week" beats filler.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.