agentleFS
Bishal-Raj-ParajuliBishal-Raj-Parajuli/work-logger/skills/log-entry/SKILL.md

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.

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
  1. Very specific:

    Read $ARGUMENTS — this is the raw description of what to log.

    line 26
  2. Distinctive:

    If it is empty, ask the user what they want to log and stop.

    line 27
  3. Very specific:

    Not about code (meeting, email, admin) → General.

    line 31
  4. Distinctive:

    Check today's log for an entry that already says the same thing:

    line 33
  5. Distinctive:

    If it is already there, tell the user and stop.

    line 39

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

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

/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

  1. 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.
  2. 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.
  3. Clean it up into a concise, specific one-liner. Keep a leading ⚠️ for blockers.
  4. Check today's log for an entry that already says the same thing:

    bash "${CLAUDE_PLUGIN_ROOT}/scripts/work-logger.sh" --show

    If it is already there, tell the user and stop.

  5. 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
    ENTRY

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

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

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.