Writing work logs
npx -y skills add narumiruna/skills --skill writing-work-logsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use only when the user explicitly names writing-work-logs to produce a concise, evidence-based Git work log for a resolved date range; never auto-activate for generic status or summary requests.
SKILL.md
1.5 KB, as published. Nobody here has run it
Writing Work Logs (Deprecated Reference)
Use only after explicit invocation. Operate on one repository and do not save a file unless requested.
Workflow
- Resolve the date range. Check the local date for relative terms; interpret “last week” as the previous calendar week unless context makes “last seven days” materially plausible. Ask for a range when none is provided.
- Gather commits with hashes, dates, authors, and subjects. Identify the current Git user's name/email when filtering a multi-author history; ask only when ownership remains ambiguous.
- Inspect
git show --stator--name-onlywhen subjects do not support a reliable summary. For a range including today, inspect uncommitted status/diff only when useful and label it as in progress. - Use user notes as evidence but never invent completed work. Mark irreducible uncertainty or request the minimum missing context.
- Return exactly:
# Work Log - <concrete date range>
- <high-impact work item>
- <progress, blocker, or follow-up>
Keep one flat bullet list, ordered by likely team/customer impact, risk reduction, unblockers, and follow-ups before low-level implementation detail. Use concrete dates, not relative labels.