skills/deprecated/work-log-writer/SKILL.md
Use only when the user explicitly names the work-log-writer skill; never auto-activate from generic work log, daily log, EOD summary, status update, or date-range summary requests.
npx skillsauth add narumiruna/agent-skills work-log-writerInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Write concise work logs for a specified date range in the current git repository. Do not use this skill unless the user explicitly invokes $work-log-writer or names work-log-writer.
Operate on one git repository at a time. Do not write files unless the user explicitly asks for a saved note or file update.
Resolve the requested range before collecting evidence.
Use concrete dates in the final title, not relative labels.
Example commands:
date +%F
git config user.name
git config user.email
git log --since="2026-05-01 00:00" --until="2026-05-05 23:59:59" --date=iso --pretty=format:"%h%x09%ad%x09%an <%ae>%x09%s"
Start from commits in the resolved range.
git config user.name or git config user.email identifies them. If the current author cannot be determined, ask whether to summarize only the user's own commits.git show --stat <sha> or git show --name-only <sha> before summarizing.git status --short and git diff --stat.Required format:
# Work Log - <resolved date range>
- ...
- ...
- ...
Use a title that includes the resolved date range. Keep the body as a single flat bullet list with no sections or subheadings. Each bullet should describe one high-level work item, progress point, blocker, or follow-up. Prefer concise summaries over implementation details, and order bullets from highest to lowest team impact. If team impact is unclear, use the evidence to prioritize likely cross-team/customer impact, risk reduction, unblockers, and follow-ups before lower-impact implementation details.
Do not guess what the user completed. If evidence is insufficient, either mark the uncertainty in a bullet or ask for the minimum missing context needed to proceed.
development
Maintains concise repository MEMORY.md notes for gotchas, stale memory corrections, and durable user preferences. Use at the start of repository conversations, when the user mentions MEMORY.md, when an error should be remembered to avoid repeating it, or when MEMORY.md content may be wrong.
development
Use when implementing non-trivial code changes that should follow TDD (write a failing test first, make the smallest passing change, then refactor safely).
tools
Use when designing, implementing, reviewing, or debugging Codex CLI hooks, including `hooks.json`, `.codex/hooks.json`, feature-flag setup, matcher behavior, event-specific stdin/stdout payloads, and hook scripts for `SessionStart`, `PreToolUse`, `PostToolUse`, `UserPromptSubmit`, or `Stop`.
testing
Use when auditing Atuin shell history for noisy duplicates or high-confidence typo/retry pairs and when preparing safe preview-first cleanup steps without editing the SQLite database directly.