log-entry
Skill0 starsChanged 22 days agoMITView on GitHub
Manually add an entry to the daily work log (~/.claude/daily-log.md, or $CLAUDE_DAILY_LOG). Use when doing non-code work that the automatic work logger won't capture: meetings, emails, research, decisions, blockers, or anything you want in your daily summary. Trigger on "/work-logger:log-entry", "/log-entry", "/log", "log this", "add to daily log", or when the user says something like "note that I did X" or "record that".
In this repositoryOne other file it gives its agents.
- daily-logSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 26
Read $ARGUMENTS — this is the raw description of what to log.
- Distinctive: line 27
If it is empty, ask the user what they want to log and stop.
- Very specific: line 31
Not about code (meeting, email, admin) → General.
- Distinctive: line 33
Check today's log for an entry that already says the same thing:
- Distinctive: line 39
If it is already there, tell the user and stop.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/log-entry — Manual Daily Log Entry
Append a manual entry to the daily work log. The log file lives at
$CLAUDE_DAILY_LOG if set, otherwise ~/.claude/daily-log.md.
When this fires
The user types /work-logger:log-entry <description> or says "log this", "add to my log", etc.
The $ARGUMENTS variable contains what they want logged.
What to do
- Read
$ARGUMENTS— this is the raw description of what to log. If it is empty, ask the user what they want to log and stop. - Determine which project this belongs to:
- Code work in the current directory → the current directory's name (
basename "$(pwd)"). - Clearly about a different project → that project's name.
- Not about code (meeting, email, admin) →
General.
- Code work in the current directory → the current directory's name (
- Clean it up into a concise, specific one-liner. Keep a leading
⚠️for blockers. Check today's log for an entry that already says the same thing:
bash "${CLAUDE_PLUGIN_ROOT}/scripts/work-logger.sh" --showIf it is already there, tell the user and stop.
Append it with the logger script. Pass the project as the argument and the text on stdin through a quoted heredoc, exactly like this, so quotes,
$, and backticks in the text are never interpreted by the shell:bash "${CLAUDE_PLUGIN_ROOT}/scripts/work-logger.sh" --manual "General" <<'ENTRY' Met with team about API redesign ENTRYThe script adds the timestamp and
📝marker, files the line under today's date and the project heading, and handles locking. Do not edit the log file directly.- Confirm in one line what was logged and under which project.
Examples
Input: /log-entry met with team about API redesign
→ project General, text Met with team about API redesign
→ logged as - **14:32** 📝 Met with team about API redesign
Input: /log-entry researched rate-limiting strategies for the gateway (in api-service)
→ project api-service, text Researched rate-limiting strategies for the gateway
Input: /log-entry blocker — waiting on infra for staging DB access
→ current project, text ⚠️ Blocker — waiting on infra for staging DB access
Input: /log-entry pushed frontend onboarding fix (while in api-service)
→ project frontend, text Pushed onboarding fix
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.

