Git Review — Work Retrospective Tool

Analyze all commits within a specified time range in the current git repository and generate a structured work retrospective report. Suitable for any content managed by git, such as code, documents, designs, research, etc.

When to Use

Trigger when the user requests the following operations:

"Do a retrospective" / "What did I do today" / "Work summary"
"review commits" / "git review" / "daily review"
"What did I do this week" / "Work in the last 3 days" / "retrospective"
Any request involving reviewing git commit history and conducting analysis

Phase 0: Parse Input — Determine Time Range

Determine the analysis time range based on user input:

Default Value: 22:00 yesterday to current time (covers work segments spanning midnight)

Natural Language Mapping:

User Input	--after	--before
Today / today	00:00 today	now
Yesterday / yesterday	00:00 yesterday	23:59 yesterday
This week / this week	00:00 Monday of this week	now
Last N days / last N days	00:00 N days ago	now
Specific date (e.g., Feb 20)	00:00 on that date	23:59 on that date
Date range (e.g., 2/20-2/23)	00:00 on the start date	23:59 on the end date
Default (no specification)	22:00 yesterday	now

Use the

date

command to calculate the specific timestamp and convert it to a format usable by git log (e.g.,

2026-02-22T22:00:00

Phase 1: Data Collection

Pre-check: First run

git rev-parse --is-inside-work-tree

to confirm the current directory is a git repository. If not, inform the user and stop.

Execute the following 5 commands in sequence (local operation, no parallel execution required):

1. Complete Commit History

bash

git log --after="{after}" --before="{before}" --format="%H|%an|%ai|%s|%b|||" --name-status

If the result is empty, must immediately terminate all subsequent steps. Do not attempt to expand the time range, do not look for recent commits, do not adjust parameters on your own to continue analysis. Only need to:

Inform the user that there are no commits within this time range
Display the timestamps of the last 5 commits to help the user select an appropriate range
Suggest the user specify a time range (e.g., "retrospect yesterday", "retrospect 2/22", "last 3 days")
Wait for the user's next instruction

2. Commit Statistics

bash

git log --after="{after}" --before="{before}" --stat --format="%H %s"

3. Overall Change Statistics for Time Period

bash

git diff --stat $(git log --after="{after}" --before="{before}" --format="%H" | tail -1)^..$(git log --after="{after}" --before="{before}" --format="%H" | head -1)

If there is only one commit, use

git show --stat {hash}

instead.

4. Branch Information

bash

git branch -a --sort=-committerdate | head -20

5. Current Unfinished Work

bash

git status --short && echo "---STASH---" && git stash list

Phase 2: Seven-Dimension Analysis

Based on the collected data, complete the following analyses one by one.

Dimension 1: Work Summary

Group commits by logical themes (instead of simply chronological order)
Summarize the content of each group in narrative language, explaining what was done and why
Attach a commit timeline table:
```
| Time | Short Hash | Commit Message |
```

Dimension 2: Change Type Distribution

Classify changes into the following types based on file suffixes and paths, and count the number of files and line changes for each type:

Type	Matching Rules
Code	`.go` , `.py` , `.js` , `.ts` , `.java` , `.rs` , `.c` , `.cpp` , `.swift` , `.kt` , etc.
Testing	Path contains `test` / `spec` / `_test` , or filename contains `test` / `spec`
Documentation	`.md` , `.txt` , `.rst` , `.adoc` , `.doc`
Configuration	`.yaml` , `.yml` , `.json` , `.toml` , `.ini` , `.env` , `Dockerfile` , `Makefile`
Design/Research	Path contains `design` / `research` / `rfc` / `proposal` / `audit` / `review`
Dependencies	`go.mod` , `go.sum` , `package.json` , `package-lock.json` , `requirements.txt` , `Cargo.toml` , `Gemfile`
Others	Files that do not match any of the above

Output a classification table and pie-chart style proportion.

Dimension 3: Work Rhythm

Draw a commit timeline (represented in text, e.g., one grid per hour)
Identify Flow Sessions: consecutive commits with intervals < 30 minutes are considered the same session
Statistics: first commit time, last commit time, total span, number of sessions, longest session, longest interval
If there is only 1 commit, skip rhythm analysis and only record the commit time

Dimension 4: Commit Practice Evaluation

Score commit habits on a scale of 1-5:

Evaluation Item	5-point Standard	1-point Standard
Message Quality	Clearly describes what + why	Vague or meaningless (e.g., "update", "fix")
Granularity	Each commit is an independent logical unit	Giant commit mixing multiple unrelated changes
Conventional Commits	Follows `type(scope): description`	No adherence to any specification

Provide the score for each item, good examples (from actual commits), and examples for improvement.

Dimension 5: Technical Decision Identification

Scan the change content to identify the following types of technical decisions:

New Dependency Introduction: New entries in dependency files
Architecture Change: New directory structure, new modules, interface changes
Refactoring: A large number of file renames/moves, function signature changes
Security-Related: Changes involving auth, token, secret, permission
API Change: Modifications to routes, endpoints, schema

List specific commits and impact assessments for each item. If no technical decisions are identified, briefly explain.

Dimension 6: Completeness Check

Check in checklist format:

Are there uncommitted changes (
```
git status
```
)
Are there stashed works in stash
Does the new code include
```
TODO
```
/
```
FIXME
```
/
```
HACK
```
/
```
XXX
```
comments
Does the new code file have a corresponding test file (check if a
```
_test
```
file with the same name exists)

Mark each item with Pass/Warning/Info and specific content.

Dimension 7: Improvement Suggestions

Based on the analysis results of the above 6 dimensions, provide 3-5 actionable improvement suggestions. Each suggestion needs:

Cite specific analysis data as evidence
Propose clear action items
Explain expected outcomes

Phase 3: Output Report

Output the complete report in the following format:

markdown

# Git Work Retrospective

> {Time Range} | {Repository Name} | {Number of Commits} commits | {Number of Changed Files} files | +{Added Lines} -{Deleted Lines}

## Key Findings

1. ...
2. ...
3. ... (3-5 key points)

## 1. Work Summary

{Narrative summary}

### Commit Timeline

| Time | Hash | Commit Message |
|------|------|---------|
| ... | ... | ... |

## 2. Change Type Distribution

| Type | Number of Files | Proportion | Line Changes (Add/Delete) |
|------|-------|------|---------|
| ... | ... | ... | ... |

{Analysis Description}

## 3. Work Rhythm

- First Commit: ...
- Last Commit: ...
- Total Span: ...
- Flow Sessions: ... sessions
- Longest Session: ...
- Longest Interval: ...

{Timeline Visualization}

## 4. Commit Practice Evaluation

| Evaluation Item | Score | Description |
|--------|------|------|
| Message Quality | ⭐×N | ... |
| Commit Granularity | ⭐×N | ... |
| Conventional Commits | ⭐×N | ... |

**Good Examples**: ...
**Areas for Improvement**: ...

## 5. Technical Decisions

{List of decisions, each with commit reference and impact assessment}

## 6. Completeness Check

- [x/!/ ] Uncommitted Changes: ...
- [x/!/ ] Stashed Work: ...
- [x/!/ ] TODO/FIXME: ...
- [x/!/ ] Test Coverage: ...

## 7. Improvement Suggestions

1. **{Suggestion Title}** — {Specific Content} (Evidence: {Cited Analysis Data})
2. ...
3. ...

Save the report as

git-review-{date}.md

in the current working directory, where

{date}

is the current date (e.g.,

2026-02-23

Edge Cases

No Commits: After detecting an empty result in Step 1 of Phase 1, immediately terminate the process — display the timestamps of the last 5 commits for reference, and prompt the user to re-specify the range. Prohibited to expand the time range on your own or proceed to subsequent Phases
Single Commit: Generate the report normally, but skip the session analysis in Dimension 3 (Work Rhythm), simplify to only record the commit time
Non-git Repository: Pre-check in Phase 1 fails, prompt the user that the current directory is not a git repository
Binary Files: Only mark as binary in the file list, skip line count statistics, do not attempt diff analysis
Oversized Time Range (>100 commits): Analyze normally, but perform higher-level induction when grouping by theme in Dimension 1 to avoid overly long reports

git-review

NPX Install

Tags

SKILL.md Content (Chinese)

Git Review — Work Retrospective Tool

When to Use

Phase 0: Parse Input — Determine Time Range

Phase 1: Data Collection

1. Complete Commit History

2. Commit Statistics

3. Overall Change Statistics for Time Period

4. Branch Information

5. Current Unfinished Work

Phase 2: Seven-Dimension Analysis

Dimension 1: Work Summary

Dimension 2: Change Type Distribution

Dimension 3: Work Rhythm

Dimension 4: Commit Practice Evaluation

Dimension 5: Technical Decision Identification

Dimension 6: Completeness Check

Dimension 7: Improvement Suggestions

Phase 3: Output Report

Edge Cases