invoice-generator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Invoice Generator — Daily Summary, Reshaped for Leadership

Invoice Generator — 面向管理层优化的每日工作总结

This skill reads git commits across all repositories in the workspace, produces a concise daily work summary, then always hands that summary to the

management-talk

skill so the final output is shaped for the channel it is going to.

此技能会读取工作区中所有代码仓库的Git提交记录，生成简洁的每日工作总结，然后始终将该总结传递给

management-talk

技能，以便最终输出内容适配目标渠道。

Why this exists

开发背景

Writing daily time reports and status updates is tedious. Git commits already capture what was done — this skill turns them into a clean per-day summary and then reshapes that summary for leadership/the target channel, ready to paste without editing.

撰写每日时间报告和状态更新十分繁琐。Git提交记录已经记录了完成的工作内容——此技能可将这些记录转换为清晰的每日总结，再将其调整为适合管理层或目标渠道的版本，无需编辑即可直接使用。

How it works

工作流程

Step 1: Discover all git repositories

步骤1：发现所有Git仓库

Find all git repos under the current working directory. Repos are identified by having a

.git

directory. Typically this means checking immediate subdirectories:

bash

for dir in */; do
  if [ -d "$dir/.git" ]; then
    echo "$dir"
  fi
done

查找当前工作目录下的所有Git仓库。仓库通过是否存在

.git

bash

for dir in */; do
  if [ -d "$dir/.git" ]; then
    echo "$dir"
  fi
done

Step 2: Collect commits for yesterday and today

步骤2：收集昨日和今日的提交记录

For each discovered repo, fetch commits authored by the current git user for yesterday and today:

bash

git log --author="$(git config user.name)" \
  --since="YYYY-MM-DD" --until="YYYY-MM-DD" \
  --pretty=format:"%ad | %s" --date=short

Use the actual calendar dates (not relative dates like
```
--since=yesterday
```
) to avoid timezone ambiguity.
Collect from ALL repos and tag each commit with which repo it came from so you can group related work. Include all branches (
```
--all
```
) so work on feature branches is not missed.

针对每个发现的仓库，获取当前Git用户在昨日和今日的提交记录：

bash

git log --author="$(git config user.name)" \
  --since="YYYY-MM-DD" --until="YYYY-MM-DD" \
  --pretty=format:"%ad | %s" --date=short

使用实际日历日期（而非
```
--since=yesterday
```
这类相对日期），避免时区歧义。
从所有仓库收集记录，并为每个提交标记所属仓库，以便对相关工作进行分组。包含所有分支（
```
--all
```
），避免遗漏功能分支上的工作。

Step 3: Summarize into 4 lines per day

步骤3：总结为每日4条内容

This is the core value of the skill. Raw commits are too granular — produce a high-level summary first.

Rules for summarizing:

Group by feature/area, not by repo. If frontend and backend commits both relate to "Voyage Schedule search", combine them into one line.
Exactly 4 lines per day. No more, no less. If there's less work, make lines more detailed. If there's more work, combine related items.
Each line should be a complete thought — describe what was built/fixed/improved, not individual commits.
Use action verbs — "Built", "Developed", "Added", "Fixed", "Created", "Implemented", "Enhanced".
Include both frontend and backend context when a feature spans both — e.g., "Built Profile page — frontend hook, RTK endpoints, route wiring (GET/PUT /api/profile)".
Mention key technical details that help recall the work — endpoint names, component names, patterns used (TDD, RBAC, etc.).
Exclude knowledge-base / documentation work. Do NOT include wiki ingestion, knowledge-base maintenance, note-taking, or documentation-summarizing activity — only report actual product work (code commits, CRM/Dataverse changes, deployments, bug fixes). This covers billable engineering work, not internal note-keeping.

What NOT to include (always skip):

Wiki / knowledge-base ingestion or scaffolding (e.g. "ingested N docs", "touched N wiki pages", "scaffolded wiki structure", building an Obsidian/RAG vault).
Summarizing, cataloging, or indexing source documents into a knowledge base.
```
log.md
```
entries whose
```
{type}
```
is
```
ingest
```
,
```
scaffold
```
(wiki),
```
synthesis
```
, or
```
lint
```
— these describe knowledge-base upkeep, not product work.

If a day contains ONLY knowledge-base work and no real commits/CRM changes, say so plainly rather than dressing the documentation work up as billable engineering.

This per-day summary is the input to Step 4 — it is not the final deliverable on its own.

这是此技能的核心价值。原始提交记录过于细碎——首先生成一份高层级的总结。

总结规则：

按功能/领域分组，而非按仓库。 如果前端和后端的提交均与“航行日程搜索”相关，则将它们合并为一条内容。
每日恰好4条内容。 不多不少。如果工作内容较少，则每条内容更详细；如果工作内容较多，则合并相关项。
每条内容应表达完整的含义——描述构建/修复/优化的内容，而非单个提交记录。
使用动作动词——“构建”、“开发”、“添加”、“修复”、“创建”、“实现”、“增强”。
当功能涉及前后端时，同时包含两者的上下文——例如：“构建个人资料页面——前端钩子、RTK端点、路由配置（GET/PUT /api/profile）”。
提及有助于回忆工作的关键技术细节——端点名称、组件名称、使用的模式（TDD、RBAC等）。
排除知识库/文档工作。 请勿包含维基内容导入、知识库维护、笔记记录或文档总结活动——仅报告实际产品工作（代码提交、CRM/Dataverse变更、部署、bug修复）。这涵盖可计费的工程工作，而非内部笔记记录。

需要排除的内容（始终跳过）：

维基/知识库导入或搭建（例如“导入N份文档”、“修改N个维基页面”、“搭建维基结构”、构建Obsidian/RAG知识库）。
将源文档总结、分类或索引到知识库中。
```
log.md
```
中
```
{type}
```
为
```
ingest
```
、
```
scaffold
```
（维基）、
```
synthesis
```
或
```
lint
```
的条目——这些描述的是知识库维护工作，而非产品工作。

如果某一天仅包含知识库工作，没有实际的提交记录/CRM变更，则直接说明情况，不要将文档工作伪装成可计费的工程工作。

这份每日总结是步骤4的输入——它本身并非最终交付成果。

Step 4: Always reshape via management-talk

步骤4：始终通过management-talk调整内容

After building the per-day summary, always hand it to the

management-talk

skill to shape it for leadership and the target channel. Do not skip this step and do not present the raw 4-line summary as the final answer.

Pick the channel. If the user named a channel (Tribletext entry, Slack, async standup, email, JIRA comment, or meeting talking-points), use it. If they did not, ask which channel — defaulting to a Tribletext daily entry when the trigger was invoice/timesheet/Tribletext-related.
Invoke management-talk. Load the
```
management-talk
```
skill (fully qualified:
```
dev-workflows:management-talk
```
) via your harness's skill-loading mechanism (Claude Code: the Skill tool; Antigravity: read its
```
SKILL.md
```
when it applies), passing the per-day summary from Step 3 as the content to rewrite, along with the chosen channel. management-talk owns the audience translation and channel formatting.
Output the reshaped result that management-talk returns as the final deliverable. If useful, you may keep the raw per-day summary available as an appendix, but the leadership/channel version is the headline output.

生成每日总结后，必须将其传递给

management-talk

技能，调整为适合管理层和目标渠道的版本。请勿跳过此步骤，也不要将原始的4条总结作为最终答案呈现。

选择渠道。 如果用户指定了渠道（Tribletext条目、Slack、异步站会、邮件、JIRA评论或会议讨论要点），则使用该渠道。如果未指定，则询问用户——当触发词与发票/工时表/Tribletext相关时，默认使用Tribletext每日条目。
调用management-talk。 通过技能加载机制（Claude Code：Skill工具；Antigravity：适用时读取其
```
SKILL.md
```
）加载
```
management-talk
```
技能（完整标识：
```
dev-workflows:management-talk
```
），将步骤3生成的每日总结作为待重写内容，连同选定的渠道一起传递。management-talk负责受众适配和渠道格式调整。
输出调整后的结果，即management-talk返回的内容作为最终交付成果。如有需要，可将原始每日总结作为附录保留，但面向管理层/渠道的版本是主要输出内容。

Customization

自定义设置

If the user asks for a different number of lines, different date range, or different format — adapt accordingly. The 4-line format is the default, not a hard rule.

If the user specifies a date range (e.g., "this week", "last 3 days"), adjust the git log date filters accordingly. Always convert relative dates to absolute dates for the git commands.

If the user explicitly asks for the raw commit summary only (no leadership reshaping), honor that and skip Step 4 — but the default is always to reshape via management-talk.

如果用户要求不同的条目数量、日期范围或格式——请相应调整。4条格式是默认设置，而非硬性规则。

如果用户指定了日期范围（例如“本周”、“过去3天”），则相应调整Git日志的日期过滤器。始终将相对日期转换为绝对日期用于Git命令。

如果用户明确要求仅提供原始提交总结（不进行面向管理层的调整），则遵循此要求并跳过步骤4——但默认情况下始终通过management-talk调整内容。