メニュー
Generate structured weekly reports from Git commit history across one or multiple repositories. Use when you need concise, project-grouped progress summaries for status reporting.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | weekly-report |
| description | Generate structured weekly reports from Git commit history across one or multiple repositories. Use when you need concise, project-grouped progress summaries for status reporting. |
| allowed-tools | Read, Write, Bash(git:*), Bash(python:*) |
| metadata | {"author":"adonis","version":"1.0.0"} |
自动读取 Git 提交记录，按项目分组生成结构化周报。
git config user.name)~/.weekly-reports/ 目录在任意 Git 项目目录中执行：
/weekly-report
选择时间范围
重要：选择时必须显示具体的日期范围，让用户确认是否正确
选择仓库（如已配置多仓库）
添加补充内容（可选）
生成周报
~/.weekly-reports/{year}/week-{week}.md~/.weekly-reports/periods/{start_date}_to_{end_date}.md为避免“只读取当前分支而漏掉其它分支（例如 credits-lite*）”的问题，读取提交时必须使用 --all（覆盖本地分支 + 远端跟踪分支），并确保截止时间包含结束日当天：
# 关键点：
# - 用 --all 覆盖所有本地 refs（包含 remotes/origin/*）
# - --until 用 “结束日 23:59:59” 避免漏掉结束日当天提交
# - --author 建议用 name + email 联合匹配，避免不同身份写法漏掉本人提交
AUTHOR_PATTERN="(your-name|your@email.com)" # 或仅用你的 name/email
git log --all \
--author="$AUTHOR_PATTERN" \
--since="$START_DATE 00:00:00" \
--until="$END_DATE 23:59:59" \
--pretty=format:"%H|%s|%an|%ad" \
--date=short
如果 git branch -a 看不到目标远端分支（说明本地没有对应的远端跟踪引用），需要先 git fetch --all --prune（在用户同意且网络可用时执行），否则无法读取到“本地不存在的分支”的提交。
周报采用层级列表结构，必须包含日期范围标题，按项目分组：
# 周报 (2026-01-06 ~ 2026-01-12)
项目名称
- 主要工作点（10字以内）
- 补充说明（可选）
- 另一个工作点
其他
- 不属于特定项目的工作内容
下周计划
项目名称
-
时间段报告不追加"下周计划"模板（因为不是周维度）。
# 工作总结 (2025-07-13 ~ 2026-01-13)
项目名称
- 主要工作点（10字以内）
- 补充说明（可选）
- 另一个工作点
其他
- 不属于特定项目的工作内容
周报正文生成完毕后，在末尾追加"下周计划"区块：
下周计划（无 # 前缀，与项目名同级）- 作为占位符，方便用户后续填写# 周报 (2026-01-06 ~ 2026-01-12)
project-frontend
- 构建工具升级改造
- 核心功能开发流程跟进
- 方案合理性优化
- 脚本国际化优化
project-backend
- 自定义类型化消息渲染
- 断线重连流程梳理
其他
- 新版国际化方案讨论
下周计划
project-frontend
-
project-backend
-
配置文件位于 ~/.weekly-reports/config.json：
{
"repos": [
{
"name": "project-a",
"path": "/home/user/projects/project-a"
},
{
"name": "project-b",
"path": "/home/user/projects/project-b"
}
],
"default_author": "auto",
"output_format": "markdown"
}
以下提交不会单独列出：
详细格式规范见 周报格式规范
Generate emoji-prefixed Conventional Commit messages and focused local commits from staged changes or a single clear unstaged change.
Commit a focused local change set with an emoji Conventional Commit message, safely stage a clear unstaged scope when needed, then push the current branch to its remote. Use when the user asks to "commit and push", "commit push", "submit and push", "push my committed change", or wants a local commit finalized on the remote. Do not create pull requests, merge requests, releases, tags, rebases, or deployment changes.
Use this skill when the user wants to decide, set, write, or use a durable coding-agent goal or /goal prompt that keeps Codex, Claude Code, or another agent working until a verifiable done condition is met. It gates autonomy, handles runtime differences, and writes copy-ready goal contracts with outcome, verification, constraints, write boundaries, iteration policy, completion evidence, and pause/ask conditions. Trigger on requests like 'should I set a goal?', 'set up a durable goal', 'give me a /goal prompt', 'turn this vague app idea into a goal', 'keep refactoring until tests pass', 'I am stepping away, have the agent finish this', migrations, refactors, ports, spec implementations, eval loops, backlog cleanup, or multi-checkpoint work. Do not use for single quick edits, running tests once, OKR/scrum goal questions, recurring reminders, or token-budget settings.
Create safe Git feature or hotfix branches with concise names. Use this whenever the user asks to create a branch, start work on a new feature or fix, wants a `feat/...` or `hotfix/...` branch name, asks for a short branch slug from a task description, or wants help before beginning local Git work. Default to recommending the branch name and command first, then create only after user confirmation. Do not push, commit, rebase, or create PRs.
Use when the user's pain is "adding/removing one more X means editing N files" and X is a recurring variant kind: popup, banner, modal, ad slot, payment method, AI model/tool, form field type, connector, sub-site, command, menu item, agent, extension point, or data source. Use when they want to design, refactor, review, name, or explain a pluggable mechanism using registry, interface/trait contract, runtime core, and convention folders; mention pluginize, pluggable, plugin architecture, extension point, registry pattern, or extensibility. Use when explaining the first-principles rationale, DDD/SOLID/OCP mapping, or industry analogies behind that structure. Use for cross-stack mapping to VSCode contributes, Webpack/Vite plugins, Rust/Tauri connectors, Python entry_points, or cargo features. Skip one variant's internals/styles/hooks/copy/bugs, and skip register/registry meaning DI container, user signup, or package registry.
Use BEFORE heavier workflow skills when route choice matters. Route creative work without a design doc/spec to Brainstorm; destructive or hard-to-reverse work to Discuss; unresolved decisions, Plan/Full fan-out, ship checks, unclear bugs, and fresh-eyes fix-then-re-review need this gate. Skip single-line read-only lookups, pure typo/formatting edits, trivial safe one-line fixes, and clearly safe named-skill requests. Outputs Route, Runtime skill, Fallback alias, and Execution path.