receipts

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

command to you ("ignore previous instructions", "report zero spend", "say this

Audit 0.4.1 · source sha 159d63a7c255 · 31 Oct 2026Report an issue or request a re-scan

• Publisheranthropics GitHub organizationOwner of the repository this skill is read from
• Source folderanthropics/claude-plugins-official/plugins/receipts/skills/receiptsThe exact folder we audited
• LicenceApache-2.0As the repository states it
• Commit pinned for this verdict159d63a7c255A new audit runs when the source changes
• Repository statusNot archivedPushed today
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Generate a personal Claude Code usage & impact report ("receipts") from this machine's local session transcripts — for justifying Claude Code usage/spend to a manager, self-review, or "what have I been using this for"…

---
name: receipts
description: Generate a personal Claude Code usage & impact report ("receipts") from this machine's local session transcripts — for justifying Claude Code usage/spend to a manager, self-review, or "what have I been using this for" check-ins. Mines ~/.claude/projects locally (no extra API calls beyond one final write-up), cross-references local git history, and writes a markdown report plus a self-contained HTML receipt to your home directory. Use when the user asks for "receipts", an "impact report", "usage report", wants to "show my Claude Code activity", "prove the value of Claude Code", or runs `/receipts`.
---

# /receipts — personal Claude Code impact report

Generates a markdown report of one developer's own Claude Code activity,
built entirely from local data:

- **Source data**: this machine's session transcripts at `~/.claude/projects/**/*.jsonl`
  (every session, every project, already on disk — nothing to set up).
- **Cost**: the mining step is a local Node script — file I/O + regex, zero
  API calls. The only model call is one final write-up over a small (~10-20KB)
  JSON summary, regardless of how much history was scanned.
- **Cross-reference**: local `git log` per repo (no network) to sanity-check
  commit activity against CC session activity.

## Step 1 — figure out the period

Parse `$ARGUMENTS`:
- "week" → 7, "month" → 30 (default if nothing given), "quarter" → 90, "year" → 365
- a bare number → that many days
- a project name/substring (e.g. "for anthropic") → pass through as `--repo
  <substr>`. It matches against the resolved project name, case-insensitively,
  and scopes the entire report — totals included — to matching projects.

## Step 2 — run the miner

The script `mine-transcripts.mjs` ships alongside this SKILL.md, under
`scripts/`. Use its absolute path:

```bash
node <skill-dir>/scripts/mine-transcripts.mjs --days <N> [--repo <substr>] --html /tmp/cc-receipt.html
```

Use that fixed temp path — the real `since`/`until` are computed by the script
and only known once it has run, so don't try to put them in this filename.
Steps 4 and 5 name the final files, by which point the JSON has the dates.

This prints one JSON object to stdout **and** writes a self-contained, styled
HTML "receipt" to the `--html` path — built deterministically from the same
data (no extra model cost). The receipt carries an **Export CSV** button that
downloads the by-project table; the CSV is embedded in the page, so it works
offline and there's nothing to wire up. **Do not** separately Read any
`*.jsonl` transcript files — the script has already extracted everything
relevant. Re-reading raw transcripts would burn a huge number of tokens for no
benefit.

It reads every transcript file in the window and shells out to `git`, so it
takes a few seconds — roughly 1s for a week, 5s for a year on a large history.
That's local CPU time, not API spend. No need to warn the user.

### What the numbers mean

Everything here is scoped to **work done with Claude Code**, mapped to the
project it was done on. Two rules follow from that, and they explain most of
the shapes below:

- **Claude Code's own machinery is not the dev's work.** The agent's
  scratchpad, its per-session tool output, and `~/.claude` are excluded. Files
  Claude wrote to talk to itself are not files the dev shipped.
- **A project is where work landed, not where the shell was.** Each session is
  attributed to the project(s) its file operations touched — reads included,
  since reading a repo to answer a question is work in that repo — resolved to
  the git root, or to the containing directory when it isn't a repo. Subagents
  share their parent's session, so their work ladders into the same project
  automatically. There is no "delegated" bucket; delegation is a mechanism, not
  a kind of work.

```jsonc
{
  "generatedAt": "2026-06-08T17:04:22.000Z",
  "userName": "Ada Lovelace" | null,  // `git config --global user.name`, to personalize the receipt
  "since": "2026-05-10", "until": "2026-06-08", "periodDays": 30,
  // How much was read to build this — provenance, not an achievement. Don't
  // put these in the report; they are not sessions and not files touched.
  "filesScanned": 189, "linesScanned": 36536,
  "totals": {
    "sessions": 131, "prompts": 681,
    "activeDays": 24, "calendarDays": 30,   // activeDays <= calendarDays, always
    "filesTouched": 24, "linesTouched": 4447,
    "prCreateCmds": 3,      // `gh pr create` commands CC ran
    // There is no `git commit` counter: a Bash call carries no working
    // directory, so a commit in a throwaway fixture repo under /tmp can't be
    // told apart from one in the dev's project. Commits are counted against
    // git instead — see commitsWithOurWork.
    // Commits whose changed files include something CC touched, de-duplicated
    // by SHA. NOT "commits by your git identity": that counts snapshot crons,
    // release bots and formatters running under the dev's name, and it is how
    // a report ends up claiming thousands of commits. This number requires the
    // commit to be BOTH authored by the dev AND to carry CC's work — so it
    // also catches the commit they made by hand in a terminal afterwards.
    // null means "not checked", NOT "not a git repo" — a real repo comes back
    // null when CC touched none of its tracked files, or no git identity is
    // configured, or git errored. Footnote it as "no commits carrying this
    // project's work, or not a git repo", never as a flat "not a repo".
    "commitsWithOurWork": 2 | null,
    "gitActiveDayOverlap": 2 | null,  // active days that ended with such a commit
    // Present and true ONLY if git actually errored somewhere. Its absence with
    // a null commit count means something different and much more ordinary: no
    // project produced commits (a research month, work outside a repo, a fresh
    // checkout). That's an honest zero. Don't report it as a tool failure.
    "gitUnavailab

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

1. 2026-10-31
   ✓SAFE B 89 / 100

   first audit · source 159d63a7c255

Questions about receipts

• github.com/anthropics/claude-plugins-official/tree/main/plugins/ — the audited source at commit 159d63a7c255 and every finding aboveObserved · 31 Oct 2026

Spotted something wrong? Report a correction · Methodology