agentleFS
BespokeWoodcraftStudioBespokeWoodcraftStudio/claude-worklog-skill/worklog/SKILL.md

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

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
  1. Distinctive:

    Run the bundled script (installed with this skill).

    line 26
  2. Very specific:

    If the project also uses a separate memory or knowledge system, link to it too (e.g.

    line 76
  3. Very specific:

    Start at docs/worklog/INDEX.md (one line per entry, grouped by day).

    line 81
  4. Distinctive:

    Run the project's recall step (if any) at task start.

    line 96
  5. Very specific:

    Don't hand-edit INDEX.md ids/timestamps — let the script manage them.

    line 101
  6. Distinctive:

    Don't paste large diffs or secrets into an entry.

    line 102
  7. Distinctive:

    Don't skip the entry on real work because "it's small" — the value compounds.

    line 103

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

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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
EOF

The 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.md ids/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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.