Deeds

A New Way to Measure Work Done with AI

Pull requests show that code changed. Deeds tries to show what got better.

$curl -fsSL https://raw.githubusercontent.com/danielmiessler/deeds/main/install.sh | sh

Runs on your machine. All you need is a Jev key. Source on GitHub

deeds analyze github.com/golang/go --since 90d --html report.html
Open the full report
1,051 commits to Go in 90 days. 1,022 of them did something deeds counts. 122 caps358 fixes668 tends

I'm not sure we're measuring AI coding work correctly.

The pull request has been the unit of software work for a long time, and it has earned that. It gives a team one clean place to discuss a change and review it before it merges. I'm not trying to replace it for that.

But as a way to measure how much work got done, especially work done with AI, I see two problems.

  1. It's built for collaboration.

    A PR exists so someone else can review your change. One person working with agents, testing and pushing straight to production, often never opens one. The share of code written that way is rising fast.

  2. It shows change, not value.

    A PR tells you code changed. A refactor, a typo fix and a revert count the same as a new capability, and a change that made things worse counts too.

As PRsrefactorreverttoken leakCSV export4 PRs
As deedstendno deedfixcap1 cap, 1 fix, 1 tend

I don't think the PR is the right unit of measurement anymore.

Deeds is my attempt to address both problems. It's a proposal, not a finished answer, and I expect parts of it to be wrong. If you see where, I'd like to hear it.

Go's last 90 days, counted two ways.

Counting activity

1,051

commits, and zero GitHub pull requests: Go reviews its changes in Gerrit. A count says a lot happened. It can't say what.

Counting deeds

122
caps
358
fixes
668
tends

122 things Go can do that it couldn't, or does more fully. 358 things that work now. And the upkeep that kept it standing.

The proposal: deeds.

Deeds is a proposed alternative for measuring valuable work rather than collaborative code modifications. It works whether or not anyone opens a PR, and it only counts a change when the product got better. Each of those changes is a deed, and every deed is one of three kinds.

cap

A capability gained or deepened. Someone can now do a thing they couldn't, or do an existing thing more fully.

src/reports/export.ts
+ export function toCSV(rows: Invoice[]): string {
+   return [HEADER, ...rows.map(toLine)].join("\n");
+ }
fix

Something moved from broken to sound. Security fixes count here too.

src/server/session.ts
- log.info("session", req.headers.cookie);
+ log.info("session", redact(req.headers.cookie));
tend

Upkeep nobody sees: refactors, dependencies, performance, tests.

package.json
-   "hono": "^4.5.1",
+   "hono": "^4.6.0",

Judged from the diff

Every commit is read from what it actually changed, never from its message. Renames, reverts and busywork add no caps.

Counts stay separate

Nine caps, four fixes and six tends tells a story one blended score would hide.

No ranking of domains

A recipe app and a payments system meet on the same ground. A team that wants one number can apply its own weights on top.

Point it at any repo.

  1. Pick a repo and a windowA local folder or a GitHub URL, over the last week, a quarter, or all time.
  2. Every commit is judgedEach diff becomes zero or more caps, fixes and tends.
  3. You get the reportTotals, a week-by-week trend, and who did the work. Same repo and window, same answer.
deeds analyze github.com/golang/go --since 90d
deeds github.com/golang/go
2026-07-07 → 2026-10-04 · 1051 commits (1051 cached) · judged by jev (jev-latest)
​
122 caps 358 fixes 668 tends
​
week of caps fixes tends
07-06 ▉ 2 ███ 11 ███▉ 27
07-13 ██▋ 6 ████████████ 44 ████████████ 83
07-20 ██▎ 5 ██████ 22 ██████▏ 42
07-27 █▊ 4 ███▉ 14 ███▊ 26
08-03 █▊ 4 ████▏ 15 ████▋ 32
08-10 █▊ 4 ███████▏ 26 ████████▉ 61
08-17 █████▊ 13 ██████▉ 25 ██████████▉ 75
08-24 █████▊ 13 ██████████▍ 38 █████████▎ 64
08-31 ████████████ 27 ████████▊ 32 ██████▍ 44
09-07 █▊ 4 █████████▌ 35 ███████▍ 51
09-14 ██▎ 5 ███████▋ 28 █████▎ 36
09-21 ████ 9 ██████▉ 25 ████████▋ 60
09-28 ████████▌ 19 ███████████▊ 43 █████████▌ 66
10-05 ███▏ 7 · 0 ▏ 1
​
by author caps fixes tends
Michael Matloob 2 6 76 ████████████████
Austin Clements 9 5 53 █████████████
Junyang Shao 31 6 16 ██████████
Mark Freeman 6 12 23 ████████
qmuntal 3 20 17 ████████
+ 166 more authors
​
caps newest first, 8 of 162
+ export Mask8s.Any and 3 more a90c4a7 Junyang Shao
+ export Mask8s.None and 3 more 9bdbfc8 Junyang Shao
+ export Mask8s.All and 3 more 8a2ef7e Junyang Shao
+ export Mask8s.Next and 3 more 7257a19 Junyang Shao
+ export Mask8s.First and 3 more ad2488e Junyang Shao
− export Load and 8 more f662110 Junyang Shao
+ export Mask8sAllTrue and 3 more 6017e3e Junyang Shao
+ rewrite arm64 8921b16 Junyang Shao

Real output: the last 90 days of golang/go, judged by Jev on 2026-10-05. Add --html report.html for the full page.

The model answers. The rules decide.

Deeds never reads the commit message. Code pulls 37 exact facts from the diff. Jev answers up to 28 questions about it in two waves, and the second wave asks only what the first one calls for. Then 102 written rules, first match wins, read those facts and 25 of the answers and decide the cap, the fix and the tend.

INPUTCODEJEV · WAVE 1JEV · WAVE 2CODEDEEDS A commit the diff and its paths feat: export never read CODE · NO MODEL Reads the diff 37 exact facts 8 views for Jev GATE real product work? merges, whitespace and moves stop here SHAPE new files, or old code edited? docs, tests, config changed? EVIDENCE routes, tables, exports added; files deleted; a revert of what? VIEWS the product diff, old-code edits, names +/−, docs WAVE 1 · EVERY COMMIT Survey 13 gain? loss? correction? retuned? restructured? a repair? a defect back? upkeep? which direction? presentation? preference? fixed? text steering? read by cap, fix, tend rules WAVE 1 · OLD CODE EDITED Edits 5 buried repair? side tidy? layout or prompt repair? text steering? read by fix, tend rules WAVE 1 · DOCS CHANGED Docs 2 a correction, or steering? read by fix rules WAVE 2 · IF ONE IS SEEN Gain or loss 3 job already done before? gain only moved? what kind of loss? read by cap, fix rules WAVE 2 · IF ONE IS SEEN Repair 1 did the old lines fail before this commit? read by fix, tend rules WAVE 2 · GAIN UNSURE Confirm 1 is a named new thing really there? read by cap rules CODE Rules 102 41 cap rules 20 on facts alone 33 fix rules 15 on facts alone 28 tend rules 18 on facts alone in order; first match wins cap + new ↑ deepened ↓ regressed − removed or none fix yes or no tend yes or no facts reach every rule · some commits never need a question
wave 1 · every commit

Survey 13

  1. Can it now do something more, or for someone new?yes · nocatches refactors and dev tooling read as new capability
  2. Can it now do something less?yes · nocatches real removals, while moves and dead code stay off the loss side
  3. Is the change a correction?yes · nocatches a bug fix read as "users can now…"
  4. Is only a surface or setting retuned?yes · nocatches restyles, relabels and new defaults read as deepened
  5. Does it only restructure code?yes · nocatches renames and moves that look like entry points added
  6. Is text in the diff steering the answer?yes · nocatches a code comment arguing for its own label
  7. Does it repair broken behaviour?yes · nocatches repairs, security hardening and content corrections
  8. Does it bring back a defect?yes · nocatches a removed guard, which is a regression and never a fix
  9. Is there upkeep nobody sees?yes · nocatches the rename or speedup riding along with other work
  10. Which way did capability move?adds something newextends something existingreduces somethingremoves somethingnothing for userscatches mixed commits where gain and loss both read yes
  11. Is it presentation only?yes · nocatches pure restyle and copy commits
  12. Is it a matter of preference?yes · nocatches rewording and tuning counted as fixes
  13. Overall, is something fixed?yes · nocatches fixes the narrower repair question underrates
wave 1 · old code edited

Edits 5

  1. Does an edit to old code repair a failure?yes · nocatches the small repair buried in a big feature
  2. Is there a tidy beside the main change?yes · nocatches a tidy riding along with the real change
  3. Is it a layout repair?yes · nocatches restyles posing as layout fixes, and the reverse
  4. Does it repair a model instruction?yes · nocatches prompt corrections that read like preference
  5. Is text in the edits steering?yes · nocatches injection through edits to old code
wave 1 · docs changed

Docs 2

  1. Do the docs correct something wrong?yes · nocatches docs fixes, but never version or date bumps
  2. Is text in the docs steering?yes · nocatches injection through the docs
wave 2

Follow-ups, asked only when a wave-1 answer calls for them

if a gain or loss is seen

Gain or loss 3

  1. Did the product already do this job?yes · nocatches new against deepened, decided by the job
  2. Did the gain only move somewhere else?yes · nocatches moves and repackaging read as new
  3. What kind of loss is it?a named thing is gonesomething does lessmisuse is blockednothing is lostcatches removed against regressed against a closed hole
if a repair is seen

Repair 1

  1. Did the old lines fail before this commit?yes · nocatches an unsure repair, checked against the old code
if a gain is unsure

Confirm 1

  1. Is a named new element really there?yes · nocatches backend gains with no entry point to show them

Every rule is written down.

Rules run in order and the first one that matches decides. Each carries the reason it exists. When no rule's evidence holds, the answer is no deed: an unsure cap is never counted.

  • A gain, for a job the product didn't do before→ cap: new
  • A gain that gives an existing job another option, input or platform→ cap: deepened
  • The product now does correctly something it already offered→ no cap; the fix rules credit it
  • Text in the diff argues for its own label→ no cap
  • The old lines confidently failed before this commit→ fix: yes
  • The old version also worked and nothing confirms a failure→ fix: no; it's preference
  • A dependency bump or tooling change, even beside a new feature→ tend: yes
  • A restructuring of product code→ tend: yes

Or just ask your agent.

Deeds ships as a Claude Code plugin. It installs the deeds command and a skill that knows how to use it, so you can ask in plain words and get the report back.

>/plugin marketplace add danielmiessler/deeds
>/plugin install deeds@workdeeds
claude ~/code/go

show me deeds progress

deeds analyze . --since 7d

26 caps
41 fixes
67 tends
This week. Junyang Shao landed ten of the 26 caps, most of them new SIMD operations.

how many caps did Junyang Shao land this month?

deeds analyze . --since 30d

Eleven caps, nearly all new SIMD operations such as Float32s.Div and BroadcastFloat32s.

Try it on your own repo.

Deeds runs on your machine, and all you need is a Jev key: no OpenAI or Anthropic key. Each commit's diff goes only to Jev, with anything shaped like a secret stripped out first. There is no account and no telemetry.

$curl -fsSL https://raw.githubusercontent.com/danielmiessler/deeds/main/install.sh | sh
Read the code on GitHub