monthly-invoice-summary

月度发票摘要

目的

将技术 Git 提交与工时表备注（会议、规划等）整合为简洁、突出价值且客户能够理解的描述。核心工作是将技术工作转化为业务沟通。

所需信息

1. 项目名称 — 例如“Acme Project”或“Client Portal App”
2. 时间段 — 例如“August 2025”“Q3 2025”
3. 上个月的摘要（可选）— 保持措辞一致，并延续持续进行的事项
4. 工时表备注（可选）— Git 提交中未体现的工作：会议、规划、讨论
5. Git 仓库位置 — 或确认当前目录

询问缺少的信息。如果用户一开始就提供了所有信息，直接进入步骤 2。

示例

• /monthly-invoice-summary for Acme Project, August 2025
• /monthly-invoice-summary I need to bill the client for last month
• /monthly-invoice-summary（将询问所需信息）

步骤 1：收集信息

收集上面列出的信息。

步骤 2：收集 Git 提交数据

运行 git log 获取指定时间段的数据：git log --since="2025-08-01" --until="2025-08-31"。 包含提交消息和日期；如果有多位开发者，请注明作者。

分析提交模式，以识别功能开发、错误修复、依赖项更新、文档更改、测试改进和配置更改。

步骤 3：审阅其他背景信息

查看工时表备注，了解提交中未体现的工作 — 客户会议和状态沟通、规划与设计会议、代码审查和结对编程、研究和调查、电子邮件往来。

参考上个月的摘要，识别持续进行的事项、保持格式和语气一致，并注明跨月进行的工作。

步骤 4：综合整理

将相关工作归入合理类别。常见类别包括：

• 状态会议与项目管理 — 每月常规事项
• 版本发布 — 突出每个版本的关键改进
• 基础设施/依赖项更新 — 合并归类，尽量少提技术细节
• 主要功能开发 — 业务价值和面向用户的改进
• 错误修复 — 仅列出重要修复；将次要修复合并归类
• 安全改进
• 性能优化 — 业务影响（如加快页面加载等）
• 文档更新 — 用户指南、API 文档、设置说明
• 规划和设计工作 — 需求探索、研究、架构规划

将相关提交合并为单个项目。二十条依赖项提交可归纳为“更新项目依赖项和安全补丁”；五项错误修复可归纳为“解决报告问题并修复用户通知中的边缘情况”。列表应简短，方便客户快速浏览。

步骤 5：呈现结果

使用围栏代码块输出，以便复制纯文本且不受 Markdown 渲染影响：

Project Notes:
Acme Client Portal - August 2025:
- Status meetings & project management
- Released version 2.3 with improved dashboard performance and new reporting features
- Resolved authentication issues and fixed edge cases in notification delivery
- Updated security patches and project dependencies
- Documented API endpoints for third-party integrations

写作风格

• 直接、以行动为导向 — 避免使用“全面”“增强”“强大”等词语
• 聚焦业务 — 描述成果和价值，而不是技术实现
• 尽量少用行话 — 客户不需要了解依赖项
• 句首字母大写 — 仅将首词和专有名词首字母大写

❌ “实施全面的错误处理系统” → ✅ “为支付处理添加错误恢复功能” ❌ “增强数据库性能” → ✅ “提高报告生成速度” ❌ “重构旧版代码” → ✅ “更新用户身份验证系统” ❌ “更新各种依赖项” → ✅ “更新安全补丁和项目依赖项”