resolve evidence -> group related commits -> draft or record
Default to today. Accept plain-language dates or ranges (2026-07-31, yesterday, last\nweek, this month) and normalize to [from, to]; query through <to + 1 day> because\nGit's --until boundary is exclusive. State the resolved date or range.
Read optional workProjects from ~/.agent-tools/config.jsonc. An entry is a path\nor { \"path\", \"prompt\" }, where the prompt is free text this skill follows for that\nproject, such as how to label items or which commits to skip.
另外包含: add them to the default scope.Resolve paths to Git roots and deduplicate them. Report invalid paths; a non-Git current\ndirectory does not block other valid projects. Do not clone remote URLs without consent.
\nFor each repository, resolve the author with git -C <root> config user.name; never\ninfer aliases or use the remote login as the author.
Inspect all local branches, current HEAD, user-named branches, and configured\nupstreams. Unless the user requests local-only data, refresh only the configured\nupstream branches, grouped into one best-effort git fetch --no-tags <remote> <branch...> per involved remote. Fetch failure is non-fatal. Do not change the\nworking 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\nupstream refs from git -C <root> for-each-ref --format=%(upstream) refs/heads/.\nPassing no ref walks only the current branch, so work on an unmerged branch reads as\nno activity; --all reaches past the scope above into remote branches nobody tracks.\nKeep the rows whose %an equals the resolved name exactly. Never pass --author: it\nmatches the whole Name <email> header, so anchored patterns silently match nothing.\nWhen the window holds commits but none carry that name, report the names actually\nfound instead. Deduplicate commits by hash.
Collect non-merge commits for the resolved author and day. Use subjects and changed\npaths to turn related commits into concrete completed work items. Fold formatting,\nversion bumps, and follow-up fixes into the outcome they supported; do not inflate one\nchange into several deliverables. Never restate a\ncommit subject as the work item; describe the outcome it produced. A day left with\nnothing has no reportable activity.
\nUse file counts and added/deleted lines only when they meaningfully support the work\nitem. Generated files, lockfile churn, renames, and bulk formatting often make those\nnumbers misleading. Metrics are evidence, never hours, difficulty, impact, or a\nproductivity score.
\nUncommitted changes are not work items. At most, note them factually in a chat draft\nfor today (project and files, no invented progress); never write them to the file:\ntheir dates are unverifiable, and a project left dirty for weeks would reappear as in\nprogress every day. User-provided non-code work must remain clearly identified as user\ncontext.
\n~/.agent-tools/config.jsonc may also carry log.output, an automatically recorded\nAI session log, separate from dailyLog.output. It is a markdown file with dated\nentries, or a directory holding one <date>.md report per day; entries under\nlog.projects may route their sessions to their own output, so check those paths\ntoo. When log.format is daily, read its single-line results only as activity\nleads: they may be truncated and omit important context. Do not state a log-only\nitem as a confirmed outcome from a daily entry alone. When log.format is detailed, its\nper-day reports are stronger supplementary evidence, but still do not replace Git\nor user confirmation. If the log block or its output is absent, skip this entirely.\nMerge, do not duplicate, work already backed by commits.
Match the user's language:
\n+ 2026-07-31\n 1. agent-tools: 完成多项目日报规则和 skill 落地.\n 2. vscode-plugin: 修复 Webview 刷新后状态丢失问题, 补充回归验证.\nStart each item with the label that best locates the work for a reader: the project\nname when the day spans projects, a module or feature within a single one.
\nKeep entries compact: the file accumulates for months, so every recurring line must\nearn its place. Do not add per-day summary, total, or section-header lines; the\nnumbered items already show project and count.
\nPrefer outcomes over raw Git metrics. If no verified activity exists, say so rather\nthan fabricate an entry. For a range, output one entry per day with activity, oldest\nfirst, and skip empty days.
\n\"Generate\" / 生成日报 returns a draft. \"Record\" / 记录日报, or an explicit\nwrite request, writes after previewing the entry. A draft may close with one short\nline offering to record it; treat any affirmative reply to that offer as the go-ahead,\nand keep the suggested word short (记录 / record). Resolve the destination in order:
dailyLog.output in ~/.agent-tools/config.jsonc;Read the destination before editing. Wrap each date's generated content in that date's\nown markers, <!-- daily-log:2026-07-31:start 5,a1b2c3d --> / <!-- daily-log:2026-07-31:end -->,\nwhere the start marker stores the day's commit count and newest commit hash across the\nscanned projects; the date line and every line outside the markers belong to the user.\nRefresh an existing block when either value changed or the user explicitly asks;\notherwise leave it alone, because regenerated wording varies between runs. For an existing date, show\nthe current block and the regenerated one before writing, then replace only that\ndate's block. If the date exists without markers, append a marked block below the\nuser's lines instead of editing them. Do not duplicate the date. Insert a new date\namong the existing dated entries at its date-order position, inferring ascending or\ndescending from the dates already present (ascending when that is ambiguous). A date\nthat sorts last goes right after the final dated entry, not at the end of the file:\nnotes, comment blocks and todo lists kept below the log stay below it. On duplicate or\nunpaired markers, stop and propose the edit instead of writing. When neither Git nor\nthe session log shows activity for the day, leave the file unchanged and say so; the\nuser can add a manual entry themselves. Recording a range applies these rules to each day's block independently.
Scheduling is separate; set it up only when the user asks. Prefer the OS scheduler\n(Task Scheduler, cron, launchd) over agent-internal timers, which stop with the agent:\nschedule a headless run of the CLI this skill is executing in — claude -p <prompt>,\ncodex exec <prompt>, opencode run <prompt> — invoking the skill with the recording\nrequest the user asked for, as in claude -p \"/at-daily-log record the log\". How a\nskill is addressed varies per CLI, so the test run below is what confirms it.\nKeep projects and output in config so the command stays stable. Before registering,\nconfirm the schedule, make sure the output file is resolvable, and run the exact\ncommand once; register only after that test run records correctly, and show how to\nremove the task. Headless auth\ndiffers from the interactive session, so a failed test run means stop instead of\nregistering, and show the exact command, its error output, and the likely fix (log in\nfor headless use, adjust the output path). An unattended run has nobody to confirm\nwith, so it must follow the marker rules exactly and skip any file it cannot edit that\nway: it fills missing days and refreshes days whose stored count or hash moved,\nnothing else.