daily-work-summary

Daily Work Content Summary

Use Git history as the sole source of truth, merge related commits into completed items, and output a concise numbered list in Chinese.

Confirm Inputs

Get the project path. If not provided, use the current working directory.
Get a single day, multiple discrete dates, or a continuous date range. If dates are missing, you must ask; do not guess dates.
By default, only count commits authored by the user themselves; never include commits by other authors in the summary.
Confirm the user's own Git author identity:
- If the user explicitly provides an author email, name, or multiple historical identities, use the identities provided by the user.
- Otherwise, read the currently effective git config --get user.emailin the repository and use that email as the user's identity; also read user.name only for verification, and do not use the name to replace the email already obtained.
- Use the repository's .mailmap to normalize commit author identities, so as to cover historical emails or name aliases declared therein.
- If the email cannot be obtained, or the visible history shows that the current email is insufficient to uniquely identify the user, you must ask the user for the email or identity list used for their commits; do not switch to counting all authors, and do not guess based merely on similar names.
Use the time zone specified by the user; if unspecified, use the local time zone of the runtime environment.
Use git rev-parse --show-toplevel to confirm the repository root directory. If the path does not exist or is not a Git repository, state the problem directly.

Extract Evidence

For each target date, establish a half-open interval in local time: that day's 00:00:00 to the next day's 00:00:00. Filter by commit time; the end boundary must not be included in the current date.

First read the commit metadata:

git log --all --use-mailmap --since="<开始时间>" --until="<结束时间>" --date=iso-local --pretty=format:"%H`t%cI`t%aN`t%aE`t%s%n%b"

After reading the metadata, precisely filter the author field according to the confirmed user identity: email comparison ignores case but must be fully equal; when the user explicitly provides only a name, the name must be fully equal. Do not use fuzzy matching or an unescaped --author regex instead of precise filtering.
When there are multiple confirmed user identities, handle them as "match any identity"; commits that do not match must all be excluded.
The date range should cover all dates specified by the user, and then be assigned to each day by commit time.
Use %cI and commit time to assign the work date; use %aN、%aE to determine the commit author, and do not use the committer identity in place of the author identity.
Do not automatically execute git fetch、git pull or switch branches.

For each filtered commit, check the scope of changes:

git show --stat --summary --name-status <commit>

When the commit title and body cannot explain the actual work, then read the necessary diff:

git show --format= --unified=2 <commit> -- <相关文件>

Prioritize checking implementation code, tests, migrations, deployment configuration, and directly related documentation. Do not summarize based only on commit titles, and do not indiscriminately expand all large diffs.

Merge Work Items

Merge commits by actual goal; do not restate commits one by one.
Merge the implementation, subsequent fixes, tests, and documentation of the same feature into one item.
Split independent features, performance optimizations, defect fixes, deployment changes, and documentation deliveries into separate items.
Describe the completed behavior and results; only write specific technical changes when there is diff evidence.
Avoid duplication: when a later commit only refines a previous commit, do not add a new work item.
Do not include uncommitted files in the workspace, the current code state, memory contents, or commits from other dates in the summary.
When a merge commit and a regular commit express the same work, keep it only once.

Output format

By default, output only the work content, not the evidence-gathering process, commands, tables, commit counts, or summary explanations.

Single-day format:

### 7 月 16 日

1. 完成事项……
2. 完成事项……

For multiple days or a date range, use the same structure separately by date, renumbering each day. Use completed-form wording suitable for a daily report for items, retaining necessary project terminology while controlling technical detail.

By default, do not show commit hashes.
When the user requests traceability, append the relevant short hash at the end of the corresponding item.
When there are no qualifying commits for the day, output:该日期没有已提交工作内容。
When the repository is a shallow clone or the history is clearly incomplete, add:仅基于当前可见 Git 历史。
Do not rewrite "no commits" as "no work".

Exception handling

Invalid path: point out the project path that cannot be accessed.
Non-Git directory: point out that the target is not a Git repository.
Invalid date or unclear boundaries: ask the user to provide a parseable date.
Unable to reliably confirm the user's identity: ask the user to provide the author email or identity list used in commits, and do not continue generating a summary that may include other people's commits.
Author filtering yields no results: state that the user has no visible commits on the specified date, and do not switch to counting other authors.
Large number of commits: still aggregate by completed items; output commit-level details only when the user explicitly requests it.

Examples

Single day

User:使用 $daily-work-summary 总结 E:\Code\Project\Demo 2026-07-16 的工作内容。

Output: list only the numbered work items for July 16.

Multiple dates

User:使用 $daily-work-summary 总结当前项目 7 月 16 日和 7 月 17 日的工作内容。

Output: group by the two dates, with independent numbering for each day.

Date range

User:使用 $daily-work-summary 总结 D:\work\app 2026-07-01 至 2026-07-05 的每日工作。

Output: cover every date in the range, including dates with no commits.

Date with no commits

User:使用 $daily-work-summary 总结当前项目 2026-01-01 的工作内容。

Output:该日期没有已提交工作内容。