content/skills/development-workflows/commit-daily-summary/SKILL.md
Use when the user wants a same-day summary of git commits, a commit-based daily report, asks what they did today, wants to generate a work log from commits, or says 总结我今天做了什么, 总结我的提交, 提交总结, 今天提交总结, 日报. This is the default choice for any "日报" or "daily report" request unless the user explicitly asks for multi-project session aggregation. Use proactively whenever the user mentions commits, daily summary, work log, or end-of-day report.
npx skillsauth add bahayonghang/my-claude-code-settings commit-daily-summaryInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Turn one day of git commits into a readable, grouped work summary. The goal is not to dump raw commit lines but to translate them into human-friendly task statements organized by workstream.
Detect the user's language from their request:
Defaults:
Clarify only when necessary:
Pre-check: Verify the target directory is a git repository (git rev-parse --is-inside-work-tree). If git is not available or the directory is not a repo, report the error and stop — do not guess or fabricate commits.
Single repository:
git log --since="YYYY-MM-DD 00:00" --until="YYYY-MM-DD+1 00:00" --pretty=format:"%h%x09%s"
Multiple repositories (when the user provides a list of paths):
for repo in /path/to/repo-a /path/to/repo-b; do
echo "## $(basename $repo)"
git -C "$repo" log --since="YYYY-MM-DD 00:00" --until="YYYY-MM-DD+1 00:00" --pretty=format:"%h%x09%s"
echo ""
done
Shared repository: If the repo has multiple contributors and the user likely wants only their own commits, add --author="<user>" to the git log command. Detect the current user via git config user.name or git config user.email.
Edge cases:
Cluster related commits together:
Do not create one summary line per commit when several commits are obviously part of the same workstream.
Good summary lines:
Chinese examples:
English examples:
Preferred structure:
## 提交总结
- 日期:YYYY-MM-DD
- 范围:today / current repo
### 今日工作摘要
- ...
- ...
### 分项明细
#### 仓库 A
- workstream 1: ...
- workstream 2: ...
### 原始提交(可选)
- abc123 feat(...)
session-wrapproject-daily-summaryBefore responding, verify:
development
Implement safe, behavior-preserving code refactors after inspecting the existing project. Use when the user asks to refactor code, split large files or modules, extract functions or methods, reduce duplicated logic, rename confusing classes/functions/variables, improve code comments, remove unused or dead code, or says 重构代码, 拆分模块, 提取方法, 减少重复代码, 优化命名, 优化注释, 删除未调用代码. For broad refactor requests, plan safe slices and wait for approval; for narrow scoped requests, directly implement the smallest verifiable slice.
development
Use only when the user explicitly asks for swarm, subagents, parallel agents, dynamic workflow, multi-agent orchestration, 多智能体编排, or when the task truly needs coordinated research plus implementation plus review plus verification packets. Do not use for ordinary code review, planning-only work, single-line bugfixes, routine audits, or migrations unless orchestration is requested or at least two independent workflow dimensions are present.
development
Run a code quality review focused on maintainability, structure, abstraction quality, file growth, branching complexity, boundary cleanliness, and refactoring opportunities. Use when the user asks for code quality review, code review, maintainability review, architecture quality review, PR code quality feedback, 代码质量审查, 代码质量 review, 可维护性审查, 架构质量审查, or review comments about code structure. Do not use for pure security review, formatting-only review, performance profiling, or implementation tasks unless the user also asks for a code quality review.
development
Plan-first brainstorming workflow that turns an idea into an approved Markdown implementation plan by default. Use when the user wants to brainstorm, design, scope, or plan a feature/spec before implementation. Spark explores project context, asks only blocking questions, writes the plan under the project root's .plannings/YYYY-MM-DD-feature-slug.md path, self-reviews it, and waits for user approval. Create an HTML or visual plan/spec only when the user explicitly asks for HTML, browser-viewable, or visual output; save the paired .html beside the Markdown plan.