Commit History Review

Core Question

Is this branch history coherent and reviewable, and what history cleanup would improve it if the user chooses to rewrite?

When To Use

Use this skill when:

• the user asks whether commit history is clean
• the branch has WIP, fixup, squash, revert, or duplicate commits
• the user wants a review-only recommendation before PR
• the user wants to know whether commits should be split, squashed, or reworded

When Not To Use

Do not use this skill when:

• performing rebase, squash, amend, or force-push
• creating commits
• changing staged content
• merge readiness as a whole

Route to:

• actual rewrite or commit regrouping routes to atomic-commits or undo-recover depending risk
• PR narrative routes to pr-review-prep
• range diagnosis routes to repo-state-diagnosis

Required Evidence

Before action, inspect or establish:

• branch range or merge-base
• commit subjects and bodies
• changed files per commit
• fixup/squash/WIP/revert markers
• public/shared branch status when available
• project commit convention evidence

No-evidence rule:

• Do not make strong claims without observed evidence.
• State assumptions when proceeding under incomplete evidence.
• Stop when missing evidence affects safety, correctness, user work, remote state, or irreversible action.

Operating Contract

You MAY:

• inspect relevant repository state and project files.
• generate a plan, report, or local artifact within the declared risk scope.
• route to another skill when the requested action is outside this skill's owner boundary.

You MUST:

• inspect before acting.
• keep the task within the declared owner boundary.
• classify state and risk before any meaningful action.
• preserve unrelated user work.
• verify outcomes proportional to risk.
• report evidence, assumptions, actions, verification, and residual risk.

You MUST NOT:

• invent project policy.
• expose secrets or sensitive values.
• mutate unrelated files or refs.
• perform destructive, remote, shared, history-rewriting, or irreversible actions without explicit action-specific confirmation.
• continue after unexpected destructive output.

State / Risk Table

Workflow

1. Identify the user goal and current owner boundary.
2. Inspect required evidence.
3. Classify repository/task state.
4. Classify risk using the declared scope.
5. Choose the minimal sufficient action or route.
6. Execute only allowed actions, if any.
7. Verify outcome or self-check the artifact.
8. Report result, evidence, verification, assumptions, and residual risk.

Decision Rules

• Review only; do not mutate history.
• Do not recommend force-push without explicit high-risk gate handled elsewhere.
• Tie cleanup suggestions to concrete commits and changed files.
• Preserve semantic commit boundaries over cosmetic compactness.

Tool Rules

• May inspect logs, ranges, diffs, and commit metadata.
• Must not run rebase, amend, reset, or commit commands.
• Must not push or force update remote refs.

Verification

Minimum verification:

• Verify each finding references a commit or range.
• State if range or target branch is assumed.
• Route executable cleanup to owning skill.

Risk-based floor:

• R0-R1: evidence inspected and output self-checked.
• R2: inspect resulting diff or local state.
• R3: verify local state and report recovery limits.
• R4-R5: require explicit confirmation, preflight evidence, and post-action verification where this skill owns the action.

Output Contract

Final response must include:

## Result

- Decision, action, or artifact produced.

## Evidence

- Files, commands, diffs, refs, or assumptions used.

## Verification

- Checks performed and their result.

## Risks / Limitations

- Remaining uncertainty, blocked actions, or routed next steps.

Stop / Confirmation Rules

Stop when the repository state is dirty, conflicted, diverged, missing required evidence, or ambiguous in a way that could overwrite user work, invalidate the requested scope, or require a gated action.

Require explicit action-specific confirmation for:

• destructive local mutation.
• remote/shared mutation.
• history rewriting.
• security/secret/data impact.
• irreversible or hard-to-recover operation.

Broad approval such as "do whatever" is not enough for R4-R5 actions.

Lazy-load References

Load references/history-smells.md when:

• the task needs the detailed guidance described by the file name.
• the state/risk table identifies an ambiguous or high-risk path.

Load references/rewrite-routing.md when:

• the task needs the detailed guidance described by the file name.
• the state/risk table identifies an ambiguous or high-risk path.

Load references/reviewability.md when:

• the task needs the detailed guidance described by the file name.
• the state/risk table identifies an ambiguous or high-risk path.