Project Weekly Report
Overview
Create a project-level weekly report from recent Git updates. Focus on business outcomes, product progress, delivery status, collaboration, risks, and next actions; do not expose code, function names, class names, file names, branch internals, or implementation details in the final report.
Workflow
- Collect recent Git activity for the last 7 days unless the user specifies another range.
- Convert technical evidence into business-facing work items.
- Write the weekly report with exactly these sections:
1. 本周工作事项完成情况2. 下周的工作计划与安排3. 复盘总结
- In
复盘总结, include both excellent experiences/practices that support self-improvement and problems/reflections with adjustment plans.
- Keep the report concise, concrete, and project-level.
Gather Evidence
Run the helper script from the repository root:
python3 .codex/skills/weekly-report/scripts/collect_git_week.py
Optional arguments:
--since YYYY-MM-DD and --until YYYY-MM-DD for a custom period.--days N for a relative range. Default is 7.--max-commits N to cap detailed commit records. Default is 80.
Use the script output as evidence only. Rewrite it into business language before presenting the weekly report.
Business Translation Rules
- Translate commit messages and changed areas into user-facing progress such as capability improvements, workflow optimization, stability improvement, content generation experience, integration readiness, operational efficiency, or delivery support.
- Group related commits into a small number of business themes instead of listing every commit.
- If evidence is thin, say the weekly report is based on limited Git activity and keep claims conservative.
- Infer next-week plans from unfinished themes, repeated changes, risk areas, and project direction visible in the activity.
- Avoid inventing completed work that is not supported by Git evidence.
Forbidden Final-Report Content
Do not include:
- Code snippets or command output.
- Function names, class names, method names, variable names, API route names, or file paths.
- Raw commit hashes, branch names, merge metadata, or implementation wording.
- Phrases that sound like code review, such as "refactor this function" or "modify this module".
Output Format
Write in Chinese unless the user requests another language.
Use this structure:
1. 本周工作事项完成情况
- ...
2. 下周的工作计划与安排
- ...
3. 复盘总结
- 优秀经验与事项：...
- 问题反思与调整计划：...
Prefer 3-6 bullets for the first section, 3-5 bullets for the second section, and 2-4 bullets for the retrospective.
1---2name: weekly-report3description: Generate a business-oriented project weekly report from the repository's recent Git activity. Use when the user asks for a weekly report, work summary, weekly review, next-week plan, or project-level status based on the last week of commits, while avoiding code details, function names, class names, and implementation-level wording.4---56# Project Weekly Report78## Overview910Create a project-level weekly report from recent Git updates. Focus on business outcomes, product progress, delivery status, collaboration, risks, and next actions; do not expose code, function names, class names, file names, branch internals, or implementation details in the final report.1112## Workflow13141. Collect recent Git activity for the last 7 days unless the user specifies another range.152. Convert technical evidence into business-facing work items.163. Write the weekly report with exactly these sections:17 - `1. 本周工作事项完成情况`18 - `2. 下周的工作计划与安排`19 - `3. 复盘总结`204. In `复盘总结`, include both excellent experiences/practices that support self-improvement and problems/reflections with adjustment plans.215. Keep the report concise, concrete, and project-level.2223## Gather Evidence2425Run the helper script from the repository root:2627```bash28python3 .codex/skills/weekly-report/scripts/collect_git_week.py29```3031Optional arguments:3233- `--since YYYY-MM-DD` and `--until YYYY-MM-DD` for a custom period.34- `--days N` for a relative range. Default is `7`.35- `--max-commits N` to cap detailed commit records. Default is `80`.3637Use the script output as evidence only. Rewrite it into business language before presenting the weekly report.3839## Business Translation Rules4041- Translate commit messages and changed areas into user-facing progress such as capability improvements, workflow optimization, stability improvement, content generation experience, integration readiness, operational efficiency, or delivery support.42- Group related commits into a small number of business themes instead of listing every commit.43- If evidence is thin, say the weekly report is based on limited Git activity and keep claims conservative.44- Infer next-week plans from unfinished themes, repeated changes, risk areas, and project direction visible in the activity.45- Avoid inventing completed work that is not supported by Git evidence.4647## Forbidden Final-Report Content4849Do not include:5051- Code snippets or command output.52- Function names, class names, method names, variable names, API route names, or file paths.53- Raw commit hashes, branch names, merge metadata, or implementation wording.54- Phrases that sound like code review, such as "refactor this function" or "modify this module".5556## Output Format5758Write in Chinese unless the user requests another language.5960Use this structure:6162```markdown631. 本周工作事项完成情况6465- ...66672. 下周的工作计划与安排6869- ...70713. 复盘总结7273- 优秀经验与事项：...74- 问题反思与调整计划：...75```7677Prefer 3-6 bullets for the first section, 3-5 bullets for the second section, and 2-4 bullets for the retrospective.
Yu-xuan99