agentleFS
Sign inStart free
me-cedricme-cedric/agent-compass/skills/delivery-digest/SKILL.md

delivery-digest

Skill3 starsChanged 27 days agoMITView on GitHub

Write the digest of what changed for the Product Owner or project manager, in plain language, with business impact and planning consequences and no code. Use for a stakeholder update, release notes or a delivery report.

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    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
  1. Distinctive:

    Never write these in the file:

    line 37
  2. Distinctive:

    If you cannot describe a change without one of these, write the business consequence.

    line 45
  3. Very specific:

    Write None. for an empty section.

    line 74

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

delivery-digest

Tell the person who owns the what and the when about the same change that impact-analysis tells to the developers. The digest gets forwarded to clients, steering committees and wikis. Write it so that forwarding is safe.

Read first

  1. The change: git diff --stat <base>...HEAD and git log <base>..HEAD. Ask for the base when it is missing.
  2. The developer note in {{DELIVERY_DIR}}/impacts/, if it exists. Reuse its findings.
  3. The requirements that the change serves, in {{OPENSPEC_DIR}}.
  4. The people affected: {{PERSONAS_FILE}} and {{DELIVERY_DIR}}/assignments.json.
  5. The cost frame, when planning moved: {{COSTING_DIR}}/*.json.

Translate, do not summarize

Each line answers "so what" for delivery. Group by feature, never by commit or file.

Instead ofWrite
A file or module nameThe feature or screen that the user sees
A refactor"No visible change. It lowers the risk of X." Or drop it.
An endpointThe action that it enables, and for whom
A migrationWhether there is downtime, and whether data is affected
A library bumpOnly if it changes behavior, cost or a compliance answer

Redaction

Never write these in the file:

  • Secrets, tokens, keys, connection strings, internal hostnames or IPs.
  • File paths, function names, stack traces, SQL or code.
  • A person's name next to a judgment. Name a profile, such as "Backend developer", unless the user asks for names.
  • Internal disagreements, or anything said in confidence.
  • Vulnerability detail. Write "a security fix was applied in <area>".

If you cannot describe a change without one of these, write the business consequence. Add "Technical detail available on request."

Output

Write {{DELIVERY_DIR}}/digests/<YYYY-MM-DD>-<slug>.md.

---
title: <one line that a PO recognizes>
date: <YYYY-MM-DD>
base: <base reference>
audience: product
---

# <title>

**In one sentence:** <text>

## What is now available
## What changed for users
## Scope and planning
| Item | Before | Now | Why |
## Decisions taken
## Waiting on
| What we need | From whom | Blocking | Since |
## Risks and watch points
## Not in this delivery
  • Write None. for an empty section.
  • List in "Scope and planning" only the rows where scope, priority, MoSCoW or effort moved.
  • Link a decision record by its title.
  • Explain a technical term in plain words the first time that you use it.
  • Give a number only when you can source it.
  • Count a feature as delivered only when it is wired and tested end to end. A ticked task is not proof.
  • Name a person or a role in each "Waiting on" row, never "the team".
  • Do not commit.

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.

Check your setup, free