/at-daily-log

name: at-daily-log
description: "Summarize each day's Git activity into a concise daily work log, for a single date or a range. Uses the current repository, optional configured work projects, or paths named in conversation; configuration is never required."
argument-hint: "[<date>|<range>]"

Daily Work Log

`resolve evidence -> group related commits -> draft or record`

Date and evidence scope

Default to today. Accept plain-language dates or ranges (`2026-07-31`, yesterday, last week, this month) and normalize to `[from, to]`; query through `<to + 1 day>` because Git's `--until` boundary is exclusive. State the resolved date or range.

Read optional `workProjects` from `~/.agent-tools/config.jsonc`. An entry is a path or `{ "path", "prompt" }`, where the prompt is free text this skill follows for that project, such as how to label items or which commits to skip.

• No project named: current Git repository plus configured projects.
• Projects named directly: only those projects.
• "Also include" / `另外包含`: add them to the default scope.

Resolve paths to Git roots and deduplicate them. Report invalid paths; a non-Git current directory does not block other valid projects. Do not clone remote URLs without consent.

For each repository, resolve the author with `git -C <root> config user.name`; never infer aliases or use the remote login as the author.

Inspect all local branches, current HEAD, user-named branches, and configured upstreams. Unless the user requests local-only data, refresh only the configured upstream branches, grouped into one best-effort `git fetch --no-tags <remote> <branch...>` per involved remote. Fetch failure is non-fatal. Do not change the working tree or local branch history.

Then list candidates with `git -C <root> log --no-merges --since=<from> --until=<to+1day> --format=%H%x09%an --branches HEAD <upstream refs>`, taking the upstream refs from `git -C <root> for-each-ref --format=%(upstream) refs/heads/`. Passing no ref walks only the current branch, so work on an unmerged branch reads as no activity; `--all` reaches past the scope above into remote branches nobody tracks. Keep the rows whose `%an` equals the resolved name exactly. Never pass `--author`: it matches the whole `Name <email>` header, so anchored patterns silently match nothing. When the window holds commits but none carry that name, report the names actually found instead. Deduplicate commits by hash.

Build work items

Collect non-merge commits for the resolved author and day. Use subjects and changed paths to turn related commits into concrete completed work items. Fold formatting, version bumps, and follow-up fixes into the outcome they supported; do not inflate one change into several deliverables. Never restate a commit subject as the work item; describe the outcome it produced. A day left with nothing has no reportable activity.

Use file counts and added/deleted lines only when they meaningfully support the work item. Generated files, lockfile churn, renames, and bulk formatting often make those numbers misleading. Metrics are evidence, never hours, difficulty, impact, or a productivity score.

Uncommitted changes are not work items. At most, note them factually in a chat draft for today (project and files, no invented progress); never write them to the file: their dates are unverifiable, and a project left dirty for weeks would reappear as in progress every day. User-provided non-code work must remain clearly identified as user context.

`~/.agent-tools/config.jsonc` may also carry `log.output`, an automatically recorded AI session log, separate from `dailyLog.output`. It is a markdown file with dated entries, or a directory holding one `<date>.md` report per day; entries under `log.projects` may route their sessions to their own `output`, so check those paths too. When `log.format` is `daily`, read its single-line results only as activity leads: they may be truncated and omit important context. Do not state a log-only item as a confirmed outcome from a daily entry alone. When `log.format` is `detailed`, its per-day reports are stronger supplementary evidence, but still do not replace Git or user confirmation. If the `log` block or its output is absent, skip this entirely. Merge, do not duplicate, work already backed by commits.

Output

Match the user's language:

+ 2026-07-31
  1. agent-tools: 完成多项目日报规则和 skill 落地.
  2. vscode-plugin: 修复 Webview 刷新后状态丢失问题, 补充回归验证.

Start each item with the label that best locates the work for a reader: the project name when the day spans projects, a module or feature within a single one.

Keep entries compact: the file accumulates for months, so every recurring line must earn its place. Do not add per-day summary, total, or section-header lines; the numbered items already show project and count.

Prefer outcomes over raw Git metrics. If no verified activity exists, say so rather than fabricate an entry. For a range, output one entry per day with activity, oldest first, and skip empty days.

Draft or record

"Generate" / `生成日报` returns a draft. "Record" / `记录日报`, or an explicit write request, writes after previewing the entry. A draft may close with one short line offering to record it; treat any affirmative reply to that offer as the go-ahead, and keep the suggested word short (`记录` / `record`). Resolve the destination in order:

1. a path supplied in conversation; 2. optional `dailyLog.output` in `~/.agent-tools/config.jsonc`; 3. no destination: return the draft without writing.

Read the destination before editing. Wrap each date's generated content in that date's own markers, `<!-- daily-log:2026-07-31:start 5,a1b2c3d -->` / `<!-- daily-log:2026-07-31:end -->`, where the start marker stores the day's commit count and newest commit hash across the scanned projects; the date line and every line outside the markers belong to the user. Refresh an existing block when either value changed or the user explicitly asks; otherw