Run this on a repository you have worked in for a while:
git log --author="$(git config user.email)" --since="6 months ago" \
--pretty=format:"%ad %s" --date=short
A few hundred lines. It is a more honest record of your work than any summary you would write, because you were not writing it for anyone.
What is actually in there
Where you spend time. Not where you think. Group by directory and the answer is usually surprising, and usually more concentrated than expected.
git log --author="you@example.com" --since="6 months ago" --name-only --pretty=format: \
| grep -v '^$' | cut -d/ -f1-2 | sort | uniq -c | sort -rn | head -20
Your actual ratio of new work to maintenance. Count messages starting with fix or containing "bug" versus those starting with add or implement. For most working developers the fix side is much larger than their mental model, which is why "I did not ship anything this week" is usually false.
The things you return to. Files with many commits over months are either central or a problem. Both are worth knowing.
Your rhythm. Commit timestamps by hour and day. Most people find they have two or three genuinely productive stretches a week and a lot of context switching around them.
The content angle
This is the material most developers say they do not have.
"Nothing interesting happened" is almost always a memory problem rather than a fact. Look at the log for a week you thought was empty and there will be three or four things you had forgotten, at least one of which was harder than it now looks.
The rewrite from log line to post is short:
fix: handle empty result set in export
becomes
Export worked on every test I wrote and broke on an empty result set, which produced a valid CSV with a header and no rows and a UI that showed a spinner forever. The bug was not in the export. It was that "zero rows" and "still loading" were the same state.
The log line is the pointer. The post is the thing you remembered when you saw it.
What it does not contain
Worth being honest about the limits.
Thinking time. A two hour design decision and a two minute typo fix look identical.
Work that did not land. Approaches you tried and abandoned leave no trace unless you committed them.
Collaboration. Reviews, pairing, unblocking someone. Invisible.
Why. The most valuable part of any change, and the part the history almost never has.
This is why a tool built on commit history has to stay descriptive. It knows what changed. It does not know why it mattered, and inferring the why is exactly where fabrication starts.
One suggestion
Read your own log for the last month, once. Not to write anything. Just to see it.
Most people come away with a corrected sense of what they actually did, and usually a more generous one.