Skip to main content
ClaudeWave
ES, Spanish
Skill44k estrellas del repoactualizado 6d ago

receipts

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`.

Instalar en Claude Code
Copiar
git clone --depth 1 https://github.com/anthropics/claude-plugins-official /tmp/receipts && cp -r /tmp/receipts/plugins/receipts/skills/receipts ~/.claude/skills/receipts
Después abre una sesión nueva de Claude Code; el skill carga automáticamente.

SKILL.md

# /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.
    "gitUnavailable": true | undefined
    // There is deliberately NO activity/category breakdown of spend — no
    // "38% of your compute went to reading code". A turn's cost is ~90%
    // context handling, half of it re-reading what earlier turns added, so
    // charging it to whichever tool fired that turn is a modeling choice
    // rather than a measurement — and the choice decides the answer. Spend
    // appears once, per project, as byRepo[].pctSpend, which is stable
    // because it divides a real quantity by a real fact.
  },
  // Top 12 projects by pctSpend, already ordered biggest-first; the rest roll
  // into "(other repos)", whose
accessSkill

Manage Telegram channel access — approve pairings, edit allowlists, set DM/group policy. Use when the user asks to pair, approve someone, check who's allowed, or change policy for the Telegram channel.

agent-developmentSkill

This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.

build-mcp-appSkill

This skill should be used when the user wants to build an "MCP app", add "interactive UI" or "widgets" to an MCP server, "render components in chat", build "MCP UI resources", make a tool that shows a "form", "picker", "dashboard" or "confirmation dialog" inline in the conversation, or mentions "apps SDK" in the context of MCP. Use AFTER the build-mcp-server skill has settled the deployment model, or when the user already knows they want UI widgets.

build-mcp-serverSkill

This skill should be used when the user asks to "build an MCP server", "create an MCP", "make an MCP integration", "wrap an API for Claude", "expose tools to Claude", "make an MCP app", or discusses building something with the Model Context Protocol. It is the entry point for MCP server development — it interrogates the user about their use case, determines the right deployment model (remote HTTP, MCPB, local stdio), picks a tool-design pattern, and hands off to specialized skills.

build-mcpbSkill

This skill should be used when the user wants to "package an MCP server", "bundle an MCP", "make an MCPB", "ship a local MCP server", "distribute a local MCP", discusses ".mcpb files", mentions bundling a Node or Python runtime with their MCP server, or needs an MCP server that interacts with the local filesystem, desktop apps, or OS and must be installable without the user having Node/Python set up.

cardputer-buddySkill

Iterate on the Cardputer-Adv MicroPython app bundle (Claude Buddy, Snake, Hello) after the device is already provisioned via m5-onboard. Use when the user wants to add a new app, push a single changed .py without re-flashing, watch device serial logs, or run a one-shot REPL command. Trigger on "add an app", "push to the cardputer", "tail the device", "run on the device", or follow-up work after /maker-setup.

claude-automation-recommenderSkill

Analyze a codebase and recommend Claude Code automations (hooks, subagents, skills, plugins, MCP servers). Use when user asks for automation recommendations, wants to optimize their Claude Code setup, mentions improving Claude Code workflows, asks how to first set up Claude Code for a project, or wants to know what Claude Code features they should use.

claude-md-improverSkill

Audit and improve CLAUDE.md files in repositories. Use when user asks to check, audit, update, improve, or fix CLAUDE.md files. Scans for all CLAUDE.md files, evaluates quality against templates, outputs quality report, then makes targeted updates. Also use when the user mentions "CLAUDE.md maintenance" or "project memory optimization".