I built DevRecap: an open-source Codex Skill that reconstructs what you actually worked on
After using coding agents more heavily, I kept running into the same problem:
At the end of the week, I could remember the commits, but not the full story of what I had actually worked on.
Git is great at recording code history, but developer work is bigger than Git history.
A lot of useful context lives elsewhere:
investigations that did not result in a commit;
failed approaches;
debugging sessions;
incomplete features;
tests that failed before a fix;
work performed inside Codex or Claude Code sessions;
decisions that only become obvious when you look at several pieces of evidence together.
That led me to build DevRecap.
What DevRecap does
DevRecap reconstructs developer work from explicitly authorized local sources, including:
Codex session history;
Claude Code session history;
read-only Git evidence.
It then turns that evidence into structured activities and workstreams that can be used to generate:
daily standups;
weekly reviews;
sprint recaps;
project handoffs;
performance review notes;
“help me remember what I did” reports.
The important part is how the system separates facts from writing.
The core rule
The main design principle behind DevRecap is:
AI writes the narrative. DevRecap determines the facts.
The factual layer reconstructs activities, status, evidence and workstreams.
The AI layer only transforms those structured facts into readable prose.
That separation matters because otherwise it is very easy for an AI-generated report to overstate what actually happened.
For example:
Edited auth.ts
does not necessarily mean:
Completed authentication feature
Likewise:
Investigated PDF generation failure
does not mean:
Fixed PDF generation
DevRecap tries to keep that distinction explicit.
Evidence-backed status
A few rules are intentionally conservative:
a file edit is not automatically a completed feature;
an investigation is not automatically a shipped fix;
unfinished work stays unfinished;
blocked work stays blocked;
completion claims need supporting evidence.
When possible, DevRecap correlates multiple signals, such as:
session intent
- file edits
- passing tests
- Git commit
That gives the report more confidence than simply summarizing a transcript.
The pipeline
The current flow looks roughly like this:
Codex / Claude / Git
↓
DevRecap factual runner
↓
Activities + Evidence + Workstreams
↓
Host AI writes the report
↓
DevRecap validates claims and IDs
↓
Editorial HTML report
The coding agent acts as the writing layer.
DevRecap remains responsible for factual reconstruction and validation.
Privacy model
DevRecap is explicit-invocation only.
It does not run background watchers or silently monitor your work.
Local sources must be authorized by the user before collection.
Git access is read-only.
The idea is to make local development history useful without turning the tool into employee monitoring software.
Example usage
After installation, you can invoke the Skill and simply ask:
$devrecap
Help me remember what I worked on this week.
Or:
$devrecap
Me ajuda a lembrar tudo que trabalhei nas últimas duas semanas.
Quero um relatório detalhado em português.
The result is a report organized around meaningful work fronts instead of a raw list of commits.
Typical sections include:
Executive summary
Main focus
Confirmed deliveries
Investigations
In progress
Raw evidence remains available when you want to inspect why DevRecap classified something a certain way.
Installing DevRecap
DevRecap is now available in the OpenAI Plugins Directory.
With Codex:
codex plugin add devrecap@openai-curated
Then run:
$devrecap
There is also a GitHub marketplace installation path for development versions.
Open source
DevRecap is open source:
https://github.com/jquinteiroo/devrecap
The project is still early, and external feedback is especially valuable now.
I am particularly interested in hearing from developers who use coding agents frequently:
Does the reconstruction match how you remember your work?
Which types of activity are missed?
Which signals would make completion detection more reliable?
What would make the resulting report useful in your actual workflow?
The goal is not to make a developer look busier.
The goal is to make the record of their work accurate, useful and easy to present.
Top comments (0)