worklog
Skill1 starsChanged 3 months agoMITView on GitHub
Append a structured entry to the project work journal (docs/worklog/) — a committed, cross-linked record of what was done, why, and how. Use at the END of every substantive response, in ANY repo, to capture the work; and to READ the journal (start at docs/worklog/INDEX.md) when getting up to speed on a project.
14 other projects use a version of this.
Adopted by
Most recently taken up by
- JibranMachiavelli/claude-worklogtheir own version, first seen Nov 8, 2026
- antass/antass-skillstheir own version, first seen Nov 1, 2026
- Vinay-R/vibe-engineering-templatetheir own version, first seen Nov 1, 2026
- Srltas/claude-skillstheir own version, first seen Oct 31, 2026
- rynbol/claude-skillstheir own version, first seen Oct 13, 2026
- dgilford/ai-science-toolkittheir own version, first seen Oct 1, 2026
Other versions14 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 14
- revfactory/skills★ 160same name
- dgilford/ai-science-toolkit★ 82same name
- tae0y/python-project-template★ 14same name
- antass/antass-skills★ 1same name
- bpappin/skills★ 1same name
- f-ewald/claude-skills★ 1same name
- ingeun92/claude-code-configs★ 1same name
- renicsemenov/claude-code-skills★ 1same name
- Hyosun-byte/worklog★ 0same name
- JibranMachiavelli/claude-worklog★ 0same name
4 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repositoryOne other file it gives its agents.
- CLAUDE.mdCLAUDE.md
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 4 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 12 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 26
Run the bundled script (installed with this skill).
- Very specific: line 76
If the project also uses a separate memory or knowledge system, link to it too (e.g.
- Very specific: line 81
Start at docs/worklog/INDEX.md (one line per entry, grouped by day).
- Distinctive: line 96
Run the project's recall step (if any) at task start.
- Very specific: line 101
Don't hand-edit INDEX.md ids/timestamps — let the script manage them.
- Distinctive: line 102
Don't paste large diffs or secrets into an entry.
- Distinctive: line 103
Don't skip the entry on real work because "it's small" — the value compounds.
“Common” is measured: kept by at least 6 in 10 of the 12 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
worklog
A work journal is the chronological, cross-linked record of what was done in a project, why, and how. It is committed to the repo, so it travels with the code and is the fastest on-ramp for a future session (human or AI) to understand how the project reached its current state — especially the "why is the code like this?" questions that source code alone never answers.
This skill is global and repo-agnostic: it works in any project. The journal lives
at docs/worklog/ in the current repo (one file per day + an INDEX.md map).
When to write an entry
At the end of each substantive response — after finishing a chunk of work (a fix, a feature step, a decision, a research finding). Trivial/conversational turns don't need one. If the user gives you a new task after you responded, that task gets its own entry when done. One entry per logical unit of work; several per day is normal.
How to add an entry
Run the bundled script (installed with this skill). The markdown body is read from stdin:
"$HOME/.claude/skills/worklog/scripts/worklog.sh" add \
--title "Short, specific title" \
--type feature|fix|refactor|docs|decision|chore|infra|design|research|note \
--status done|partial|blocked|wip \
[--tags "comma,separated"] <<'EOF'
### What
What was done, concretely.
### Why
The motivation / context / problem that prompted it. (The most valuable part for future
understanding — without the "why", a record loses its value as circumstances change.)
### How
The approach and key technical choices. Mention the main files/functions.
### Outcome
Status + how it was verified (build/tests/manual), or what's still open.
### Decisions & trade-offs (include when a real choice was made)
What was chosen, what was rejected, and why.
### Lessons / gotchas (include when something was non-obvious or a correction)
Anything a future session should know so it doesn't relearn the hard way. This is the
compounding payoff: the journal gets smarter every time a mistake is corrected.
### Follow-ups (include when there is unfinished/next work)
- [ ] …
### Links (include when related work exists)
[[WL-YYYY-MM-DD-NNN]] other entries · commit:<sha> · file paths
EOFThe script stamps the timestamp + a stable id (WL-YYYY-MM-DD-NNN), appends to today's
file, updates docs/worklog/INDEX.md, and prints the id. What / Why / How / Outcome
are required; the rest are included when relevant.
The target directory is the current repo's docs/worklog/ (resolved from
$CLAUDE_PROJECT_DIR, else the git root, else the cwd). Override with WORKLOG_DIR for
a non-repo or custom location.
Linking
- Another entry:
[[WL-2026-06-03-002]](just the id). - A commit:
commit:<sha>. - Code: a normal path like
src/server/auth.ts.
If the project also uses a separate memory or knowledge system, link to it too (e.g.
mem:<name> for a file-memory note, claude-mem:<id> for a claude-mem observation).
Reading the journal (getting up to speed)
Start at docs/worklog/INDEX.md (one line per entry, grouped by day). Open the day files
that look relevant; grep the entry id inside a day file for the full entry. For "why is
the code like this?" the worklog usually answers faster than reading source.
Where this fits (optional, if the project uses them)
The worklog is the agent-authored, curated narrative layer — Claude writes each entry automatically at the end of a response (it is not maintained by hand). It pairs well with, but does not require, other knowledge layers:
- Auto-captured session memory (e.g. claude-mem) — the automatic wide net; worklog is the curated highlights of the same history.
- Distilled fact memory (e.g. per-project memory files) — atomic durable facts.
- Code-structure graphs (e.g. graphify) — where/what the code is.
Run the project's recall step (if any) at task start; write a worklog entry at task end.
Don'ts
- Don't hand-edit
INDEX.mdids/timestamps — let the script manage them. - Don't paste large diffs or secrets into an entry; summarize and link the commit.
- Don't skip the entry on real work because "it's small" — the value compounds.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

