
Git Workspace Review
- 96 installs
- 325 repo stars
- Updated August 2, 2026
- athola/claude-night-market
Git Workspace Review is an agent skill that supplies Sanctum-standard git status and diff commands—usable whenever a solo builder needs the agent to confirm branch and workspace changes before committing or o
About
Git Workspace Review (packaged in SKILL.md as git command patterns for Sanctum workflows) is a compact reference skill that standardizes how coding agents inspect a repository before destructive or publish steps. It lists verify-working-directory checks, short branch status, staged and unstaged diff statistics and bodies, and compare-to-main commands so reviews are consistent across stack-push, pr-prep, and commit rituals. Solo builders benefit because agents stop guessing git flags and instead follow the same diff vocabulary every session. The skill is not a standalone product feature; it is procedural knowledge meant to be composed into larger workflow skills. Use it whenever you need the agent to articulate what changed on the current branch versus main, what is staged for the next commit, and whether upstream tracking looks sane—especially on Claude Code or Cursor driving git from natural language.
- pwd and git status -sb for repository and branch confirmation in one line
- Staged versus unstaged stats and full diffs via --cached and working tree diffs
- Branch comparison against main using origin/main...HEAD stat and full diff
- Documents parsing patterns for ahead/behind and branch name from short status output
- Shared parent skill pattern consumed by stack-push and other Sanctum git workflows
Git Workspace Review by the numbers
- 96 all-time installs (skills.sh)
- Ranked #231 of 733 Git & Pull Requests skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/athola/claude-night-market --skill git-workspace-reviewAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 96 |
|---|---|
| repo stars | ★ 325 |
| Last updated | August 2, 2026 |
| Repository | athola/claude-night-market ↗ |
What it does
Give agents copy-paste git status and diff command patterns so they confirm repo, branch, and staged versus unstaged changes before Sanctum commits and stack workflows.
Who is it for?
Best when you use Sanctum stacked-diff or PR workflows and want agents to review the git workspace with the same commands every time.
Skip if: Skip if you need interactive merge conflict resolution UI, non-git VCS, or deep code-quality review beyond diff inspection.
When should I use this skill?
Composed inside Sanctum workflows whenever the agent must confirm correct repo, branch, staged changes, unstaged changes, or divergence from main before commit or PR steps.
What you get
The agent follows a fixed command set to report branch, tracking, staged deltas, working tree deltas, and divergence from main in a review-ready format.
- Structured workspace summary from standard git commands
- Parsed branch and ahead/behind context for downstream workflow skills
Files
Git Workspace Review
Table of Contents
1. Usage 2. Required Progress Tracking
Verification
Run git status after review to verify workspace state matches expectations.
Testing
Run pytest plugins/sanctum/tests/test_git_workspace_review.py to validate review workflow.
Usage
Use this skill before workflows that depend on repository state, such as commit message generation, PR preparation, or release notes. Run it once per session or whenever staged changes are modified.
Required Progress Tracking
1. git-review:repo-confirmed 2. git-review:status-overview 3. git-review:code-quality-check 4. git-review:diff-stat 5. git-review:diff-details
Mark each item as complete as you finish the corresponding step.
Step 1: Confirm Repository (repo-confirmed)
Run pwd to confirm you are in the correct repository directory. Execute git status -sb to view the current branch and short status, then capture the branch name and upstream information.
Step 2: Review Status Overview (status-overview)
Analyze the git status -sb output for staged and unstaged changes. Stage or unstage files so that subsequent workflows operate on the intended diff.
Step 3: Check Code Quality (code-quality-check)
Run make format && make lint to validate code quality before committing. Fix any errors immediately. Do not bypass pre-commit hooks with --no-verify. This check identifies issues early and avoids late-stage pipeline failures.
Step 4: Review Diff Statistics (diff-stat)
Run git diff --cached --stat for staged changes (or git diff --stat for unstaged work). Note the number of files modified and identify hotspots with large insertion or deletion counts.
When sem is available (see leyline:sem-integration), also run sem diff --format plain --staged to display an entity-level summary alongside the stat output. This shows which functions, classes, and methods changed rather than just line counts.
Step 5: Review Detailed Diff (diff-details)
Run git diff --cached to examine the actual changes. For unstaged work, use git diff. Identify key themes, such as Makefile adjustments or new skill additions, to provide context for downstream summaries.
Exit Criteria
Complete all progress tracking items. You should have a clear understanding of modified files and areas, and the correct work should be staged. Subsequent workflows can then rely on this context without re-executing git commands.
Supporting Modules
- Git commands reference - diff, status, branch operations for sanctum workflows
Troubleshooting
If pre-commit hooks block a commit, resolve the reported issues instead of using --no-verify. Run make format to fix styling errors automatically and use make lint to isolate logical failures. If merge conflicts occur, use git merge --abort to return to a clean state before retrying.
Git Commands for Sanctum Workflows
Repository Confirmation
Verify Working Directory
pwdvalidates you are in the correct repository before running git operations.
Check Branch and Status
git status -sbShows current branch, upstream tracking, and short status in one line.
Diff Commands
Staged Changes Statistics
git diff --cached --statShows file-by-file statistics for staged changes (insertions/deletions).
Staged Changes Details
git diff --cachedFull diff of staged changes for review before commit.
Unstaged Changes Statistics
git diff --statFile-by-file statistics for unstaged working directory changes.
Unstaged Changes Details
git diffFull diff of unstaged working directory changes.
Branch Comparison Statistics
git diff --stat origin/main...HEADShows statistics for all commits in current branch since diverging from main.
Branch Comparison Details
git diff origin/main...HEADFull diff of all changes in current branch compared to main.
Status Parsing Patterns
Extract Branch Name
From git status -sb output, the first line shows:
## branch-name...origin/branch-name [ahead N, behind M]Parse the branch name from the ## line.
Identify Staged vs Unstaged
- Lines starting with
M(M-space): staged modification - Lines starting with
M(space-M): unstaged modification - Lines starting with
A(A-space): staged new file - Lines starting with
??: untracked file
Count Changes
Use --stat output to count affected files:
file1.md | 10 +++++++---
file2.py | 5 +++++
2 files changed, 12 insertions(+), 3 deletions(-)Branch Operations
Get Merge Base
git merge-base origin/main HEADFinds the common ancestor commit for comparison.
List Recent Commits
git log --oneline -10Shows last 10 commits in compact format.
Show Commit Details
git show <commit-hash>Displays commit message and diff for a specific commit.
Best Practices
Always Run in Sequence
1. pwd - Confirm location 2. git status -sb - Check branch/status 3. git diff --cached --stat - Review staged stats 4. git diff --cached - Review staged details
Use Limits
- Always limit
git logoutput (e.g.,-10,-20) - Use
--statbefore full diffs to understand scope - For large diffs, consider
git diff --cached -- <specific-file>
Error Handling
- Check if
git statusshows "Not a git repository" - Verify upstream tracking exists before comparing to origin
- Handle empty diffs (no staged changes) gracefully
Related skills
How it compares
Reference pattern sheet for git inspection, not a full code-review or stack-push workflow on its own.
FAQ
Who is git-workspace-review for?
It is for developers and agents following athola Sanctum workflows who need reliable git status and diff recipes before commits, PR prep, or stack push.
When should I use git-workspace-review?
Use in Ship/review before commits; in Build when validating what changed; in Operate when checking branch drift; whenever stack-push or pr-prep requires confirmed staged and unstaged diffs.
Is git-workspace-review safe to install?
It only documents read-only git inspection commands—review the Security Audits panel on this page; actual risk comes from downstream workflows that commit or push after review.