CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

review-and-commit

(Claude Code only) Have the `staged-reviewer` subagent review the staged changes, resolve its findings with the user, then draft a commit message and commit after approval. Intended for the session that wrote the changes, so the review comes from an agent without the author's context; a fresh session should use `generate-commit-message` instead. Accepts optional arguments - a model name for the commit footer and `--auto-fix` to enable the automatic fix loop (e.g., `/review-and-commit --auto-fix Opus 5.5`).

Quality

91%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Review and Commit

Arguments

  • --auto-fix (optional): Enable the automatic fix loop (see "Automatic fix loop" below). Also enable it when the user explicitly asks for automatic fixing in other words. Otherwise it is off.
  • [model name] (optional): The remaining argument text is the <model name> for the commit message footer (Commit message generated by <harness name> (<model name>)).

Guard

This skill requires the Agent tool, the staged-reviewer subagent type, and the SendMessage tool. Before doing anything else, check that staged-reviewer is listed among the available agent types, and that SendMessage is available (load it via ToolSearch if it is deferred). If either is missing:

  • Stop and tell the user what is missing. The subagent is not configured until it is installed by symlinking claude-subagents/staged-reviewer.md from the skills repository into ~/.claude/agents/.
  • Mention that /generate-commit-message in a fresh session is an alternative.
  • Do not fall back to reviewing the changes yourself. You wrote them; a self-review defeats the purpose of this skill.

Workflow

  1. Load the git-workflows skill and read its references/op_commit_message.md. Follow that operation, with step 2 ("Review") requested and performed by delegation as described below.

  2. Op step 1 - Collect staged changes as the operation describes.

  3. Op step 2, delegated - Start the staged-reviewer subagent with the Agent tool. Give it the repository root. Keep its name or ID: every later round must continue the same reviewer with SendMessage, not start a new one.

  4. Present the findings and a fix plan - Show the user the reviewer's Blocking items, Suggestions, and verdict, keeping its IDs. For each item, propose a plan: how you would fix it, or why you would decline it. Check scripts/git-unstaged-diff.sh <repo-root> for the files the plan touches; for each file that already has unstaged changes, ask whether to stage those changes along with the fix or to stage only the fix. Wait for the user. The user may:

    • Approve the plan, or change it item by item
    • Fix things themselves
    • Ask for clarification
    • Approve moving on to the commit message without further changes
  5. Apply the approved plan - Make the approved fixes and stage them:

    • Files without other unstaged changes, or where the user chose to include them: git add <file>.
    • Files where the user chose to stage only the fix: snapshot the file before editing it, then stage only the fix with Method A in git-workflows' references/partial_staging.md. If git apply refuses, stop and ask the user as that method describes.
    • Never stage files the plan did not touch.

    Then continue the reviewer with SendMessage, reporting each ID as fixed or declined + reason. Return to step 4 with the new findings.

  6. Exit the review loop only when the user explicitly approves moving on. The verdict informs the user but does not decide for them. If the verdict is "Needs human decision", highlight those items.

  7. Op steps 1, 3-5 - If anything was staged or unstaged since step 2, collect the staged changes again (op step 1). Then load history, draft the commit message (using the [model name] argument for the footer, if given), display it, and commit only after the user approves it.

Automatic fix loop

Only when --auto-fix is enabled, replace steps 4-6 with:

  • Fix each OPEN Blocking item without asking, or decline it with a reason when you are confident the finding is wrong. Before editing a file, check scripts/git-unstaged-diff.sh <repo-root> for it; if it has unstaged changes, snapshot it before the edit and stage only the fix (Method A), and stop the loop if git apply refuses. Otherwise stage the fix with git add <file>. Continue the same reviewer, reporting each ID as fixed or declined + reason. Do not act on Suggestions.
  • Stop the loop when any of these happens:
    • The verdict is "OK to commit"
    • The verdict is "Needs human decision"
    • 3 fix rounds have run
  • Then show the user a summary: what was fixed, what was declined and why, Blocking items still open or needing a decision, and all Suggestions. Wait for explicit approval before step 7.

The automatic loop never skips the user's approval of the commit message.

Repository

ceshine/ceshine-agent-skills

Path

review-and-commit/SKILL.md

Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.