client-report-from-commits

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

client-report-from-commits

从Git提交记录生成客户报告

Turn git history since an explicit date into a copy-pastable, non-technical client update grouped by feature.

将指定日期以来的Git历史记录转换为按功能分组、可直接复制粘贴的非技术向客户更新报告。

Decision Tree

决策树

What do you know already?

Exact start date in
```
YYYY-MM-DD
```
and the current working directory is the target git repo: continue.
Exact start date in
```
YYYY-MM-DD
```
, but the target repo is elsewhere: use the explicit repo path and continue.
Relative or vague date such as "this week", "recently", "a few days ago", or "since the last push": stop and ask
```
What exact start date should I use? Please reply in YYYY-MM-DD.
```
Do not proceed until the user answers with an exact date.
No readable git repo in the current working directory and no repo path was provided: stop and ask for a readable git repository path.
The user wants engineering release notes, a developer changelog, or a code review: do not use this skill.

你已经了解哪些信息？

已知精确起始日期（格式为
```
YYYY-MM-DD
```
）且当前工作目录为目标Git仓库：继续执行。
已知精确起始日期（格式为
```
YYYY-MM-DD
```
）但目标仓库在其他位置：使用明确的仓库路径并继续执行。
相对或模糊日期（如“本周”“最近”“几天前”或“自上次推送以来”）：停止执行并询问
```
请提供精确的起始日期？请以YYYY-MM-DD格式回复。
```
在用户提供精确日期前请勿继续。
当前工作目录中无可读Git仓库且未提供仓库路径：停止执行并请求提供可读的Git仓库路径。
用户需要工程版发布说明、开发者变更日志或代码评审：请勿使用此工具。

Quick Reference

快速参考

Task	Action
Confirm the repo	Run `git rev-parse --show-toplevel` in the current directory, or `git -C /path/to/repo rev-parse --show-toplevel` when a repo path is provided.
Gather commit context	Run `python3 scripts/collect_git_changes.py --repo /path/to/repo --since YYYY-MM-DD` .
Inspect more detail	Read `references/workflow.md` and then inspect targeted commits with `git show <commit>` .
Shape the client update	Use `templates/client-report-template.md` and the language rules in `references/output-format.md` .
Handle edge cases	Read `references/gotchas.md` .

任务	操作
确认仓库	在当前目录运行 `git rev-parse --show-toplevel` ，若提供了仓库路径则运行 `git -C /path/to/repo rev-parse --show-toplevel` 。
收集提交上下文	运行 `python3 scripts/collect_git_changes.py --repo /path/to/repo --since YYYY-MM-DD` 。
查看详细信息	阅读 `references/workflow.md` ，然后使用 `git show <commit>` 查看指定提交的详细内容。
生成客户更新报告	使用 `templates/client-report-template.md` 和 `references/output-format.md` 中的语言规则。
处理边缘情况	阅读 `references/gotchas.md` 。

Operating Rules

操作规则

Confirm the date before doing anything else. Exact means a real calendar date, not a relative phrase.
Confirm the repository context. If the current working directory is not a readable git repo, require an explicit repo path.
Collect the commit list and touched files first. Use
```
scripts/collect_git_changes.py
```
for a fast high-level pass, then inspect specific commits only when the summary is unclear.
Group the work by feature, workflow, or product area. Do not group by commit, file, branch, or engineer.
Write for a non-technical client. Remove hashes, filenames, code terms, refactor jargon, and internal tooling names unless they are truly client-facing.
Keep each main accomplishment to a heading plus
```
2-3
```
bullets max. Each bullet should be one short sentence.
Do not invent business impact. If the value is unclear, use conservative phrasing such as "improved the foundation for" or "advanced the work on".

先确认日期再执行任何操作。精确日期指真实日历日期，而非相对表述。
确认仓库上下文。若当前工作目录不是可读的Git仓库，需用户提供明确的仓库路径。
先收集提交列表和变更文件。使用
```
scripts/collect_git_changes.py
```
快速获取高层汇总，仅当总结内容不清晰时再查看具体提交。
按功能、工作流或产品领域分组工作内容。请勿按提交记录、文件、分支或工程师分组。
面向非技术客户写作。移除哈希值、文件名、代码术语、重构行话和内部工具名称，除非它们确实面向客户。
每项主要成果仅保留标题加最多
```
2-3
```
个项目符号。每个项目符号应为简短的单句。
请勿虚构业务影响。若价值不明确，使用保守表述，如“为……完善了基础”或“推进了……的工作”。

Recommended Workflow

Report Contract

报告规范

Use this exact standard:

Start with a one-line intro such as

Here is a high-level update for work completed since 2026-04-01.

Break the report into feature sections with short audience-friendly headings.
Keep each section to
```
2-3
```
bullets max.
Make every bullet outcome-first and non-technical.
Keep the output copy-pastable. Do not wrap it in analysis notes or a developer preamble.
If there were no meaningful client-facing changes in the requested window, say so plainly instead of padding the report.

严格遵循以下标准：

以一行引言开头，例如

以下是自2026-04-01以来完成工作的高层更新。

将报告按功能板块划分，使用简短的受众友好型标题。
每个板块最多保留
```
2-3
```
个项目符号。
每个项目符号都以成果为导向且非技术向。
输出内容需可直接复制粘贴。请勿添加分析说明或开发者前言。
若指定时间段内无有意义的客户可见变更，请直接说明，不要填充内容。

Reading Guide

阅读指南

Need	Read
Repo checks, command flow, and git collection steps	`references/workflow.md`
Tone, grouping, and bullet-writing rules	`references/output-format.md`
Failure modes and what to avoid	`references/gotchas.md`
Blank client-ready structure	`templates/client-report-template.md`

需求	阅读文档
仓库检查、命令流程和Git收集步骤	`references/workflow.md`
语气、分组和项目符号写作规则	`references/output-format.md`
失败场景及注意事项	`references/gotchas.md`
空白的客户就绪结构	`templates/client-report-template.md`

Gotchas

注意事项

Ambiguous dates are a hard stop. Do not translate "this week" or "a few days ago" yourself.
A long git log is not a client report. Condense by feature and omit low-signal internal churn when it is not useful to the client.
Technical commit subjects are often misleading for a non-technical audience. Inspect the diff or surrounding files before rewriting them as client-facing bullets.
Multiple commits may represent one accomplishment. Merge them into one feature section instead of repeating the same theme.
Infrastructure-only changes should not be exaggerated. If they matter, frame them as stability or foundation work and keep the wording modest.

模糊日期为强制停止条件。请勿自行转换“本周”“几天前”等表述。
冗长的Git日志不是客户报告。按功能浓缩内容，忽略对客户无用的低信号内部变动。
技术向的提交主题对非技术受众常具误导性。在改写为客户可见的项目符号前，请查看差异内容或相关文件。
多个提交可能对应一项成果。将它们合并到一个功能板块，而非重复相同主题。
仅涉及基础设施的变更不应夸大。若确实重要，将其表述为稳定性或基础工作，并保持措辞谦逊。

client-report-from-commits

Original

Translation

client-report-from-commits

从Git提交记录生成客户报告

Decision Tree

决策树

Quick Reference

快速参考

Operating Rules

操作规则

Recommended Workflow

推荐工作流

Report Contract

报告规范

Reading Guide

阅读指南

Gotchas

注意事项