git-workspace-review
Scannednpx machina-cli add skill athola/claude-night-market/git-workspace-review --openclawGit Workspace Review
Table of Contents
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
git-review:repo-confirmedgit-review:status-overviewgit-review:code-quality-checkgit-review:diff-statgit-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.
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.
Source
git clone https://github.com/athola/claude-night-market/blob/master/plugins/sanctum/skills/git-workspace-review/SKILL.mdView on GitHub Overview
Git workspace review provides the foundation for git workflows by verifying the repository state before other operations. It focuses on checking staged changes, preflight quality gates, and ensuring the workspace matches expectations prior to commits or PRs. It should not be used for full commit or PR workflows; for those, use commit-messages or pr-prep.
How This Skill Works
The skill runs a sequence of checks to establish a reliable repo baseline: confirm the repository, analyze git status -sb, validate code quality with make format && make lint, and inspect diffs with git diff --stat and git diff --cached. It logs progress via git-review markers and requires completing a set of progress items before downstream steps proceed.
When to Use It
- Before workflows that depend on repository state, such as generating commit messages, PR preparation, or release notes.
- When starting a new session to establish a baseline for subsequent git operations.
- Whenever staged changes are modified to revalidate the intended diff and scope.
- To perform a preflight check before invoking automated pipelines that rely on clean workspace state.
- When you need a foundation check but not the full commit workflow (use commit-messages or pr-prep for those cases).
Quick Start
- Step 1: Confirm Repository (repo-confirmed) — Run pwd to confirm directory, and git status -sb to view branch and status; capture branch and upstream.
- Step 2: Review Status Overview and Code Quality — Analyze status output, stage/unstage as needed, then run make format && make lint; do not bypass --verify.
- Step 3: Review Diffs — Run git diff --cached --stat (and git diff --stat for unstaged) and then git diff --cached (or git diff) to understand changes and context.
Best Practices
- Run this skill from the repository root and use pwd and git status -sb to capture the exact state.
- Capture the current branch and upstream information to ensure correct context for downstream steps.
- Validate code quality with make format && make lint before committing; do not bypass pre-commit hooks with --no-verify.
- Examine diffs with git diff --cached --stat and git diff --stat to identify hotspots and changes in scope.
- Follow the required progress tracking steps (repo-confirmed, status-overview, code-quality-check, diff-stat, diff-details) and mark each complete to enable downstream workflows.
Example Use Cases
- Generating commit messages after confirming the workspace reflects the intended changes.
- Preparing a PR with an accurate diff and an up-to-date status overview.
- Producing release notes grounded in the actual modified files and changes.
- Starting a session to establish baseline state after adding or removing staged changes.
- Onboarding new contributors by validating workspace state before feature work begins.
