develop-review-gate

name	develop-review-gate
description	适用于这类请求：直接在当前 checkout 完成开发、固定做两轮自我 review/refactor、先把最终 review 结果给人类确认、确认后再继续改动、提交或进入下一步。用户可能会说："先开发再自审两轮"、"先 review 两次再给我确认"、"不要开 worktree，直接改"、"先输出 review 结论不要继续"、"做完先停在 gate"。

Develop Review Gate

Workflow

1. Confirm scope and current workspace state.

• Work in the current checkout instead of creating a worktree.
• Inspect the repository and any existing local changes before editing.
• If the worktree is already dirty, preserve unrelated user changes and limit edits to the task scope.

2. Implement the requested change in the current checkout.

• Explore the relevant code before editing.
• Finish the feasible scope instead of stopping at a partial patch.
• Keep architecture consistent with the project; do not use temporary patch-style fixes unless the change is truly a local no-risk micro-fix.

3. Run self-review pass 1.

• Inspect the diff as a reviewer instead of as the original author.
• Look for correctness bugs, regressions, missing tests, naming issues, leaky abstractions, and unnecessary complexity.
• Apply the fixes that are clearly actionable.
• Run the most relevant tests, lint, or build checks for the changed area.

4. Run self-review pass 2.

• Re-inspect the updated diff with the same reviewer mindset.
• Focus on issues left after the first pass: edge cases, maintainability, API consistency, error handling, and test quality.
• Apply the second-pass fixes that materially improve the result.
• Re-run the most relevant verification after the refactor.

5. Produce the approval gate output and pause.

• Report the final review findings first. If no blocking findings remain, say that explicitly.
• Summarize what changed, what was refactored during both self-review passes, what verification ran, and what did not run.
• Include the current branch, touched files, and working tree status when relevant.
• Call out residual risks or open questions.
• End in a waiting state such as: Awaiting human confirmation: continue coding, request more changes, commit, or proceed with the next step.
• Do not continue into extra scope, commit, or destructive cleanup unless the human explicitly confirms.

Review Output

Use concise sections in this order:

• Self-review findings
• Change summary
• Refactors applied
• Verification
• Residual risks
• Awaiting confirmation

Include file references when calling out findings or material changes.

After Confirmation

Continue Coding

• Keep using the same checkout.
• Repeat the implement -> review pass 1 -> review pass 2 -> approval gate cycle.
• Preserve any unrelated user changes already present in the worktree.

Commit Or Next Step

• Re-check git status before committing or taking the requested next step.
• Commit only when the human explicitly asks for it.
• If verification is stale after follow-up edits, run the most relevant checks again before committing or proceeding.

Guardrails

• Always run two self-review passes for this workflow unless the human explicitly asks to shorten it.
• Never hide failed verification. Report the failure and stop for direction.
• Never overwrite or revert unrelated user changes in the current checkout.
• Never claim the branch is ready without describing what was verified and what was not.
• Never continue past the approval gate without explicit human confirmation.