quality-gate
Quality Gate
Dispatch the code-reviewer agent (agents/code-reviewer.md) to surface defects before they propagate.
Core principle: Inspect early, inspect often.
Prime Directive
NO LANDING WITHOUT REVIEW
No exceptions. No workarounds. No shortcuts.
The Entry Protocol
Before initiating a review, confirm:
- The test suite passes on the current branch
- All changes are committed (no dirty working tree)
- You have determined BASE_SHA and HEAD_SHA
- You can articulate what was built and why
- You know the plan or specification to review against
- You have scoped the review correctly (single task vs. batch)
If any condition is unmet, resolve it before requesting review.
When to Initiate
Required:
- After each task in delegated-execution workflows
- After completing a significant feature
- Before landing on the trunk branch
Discretionary but recommended:
- When stuck (an outside perspective often unblocks)
- Before starting a large refactor (establish a baseline)
- After resolving a tricky defect
How to Initiate
1. Capture the commit range:
BASE_SHA=$(git rev-parse HEAD~1) # or origin/main
HEAD_SHA=$(git rev-parse HEAD)
2. Launch a code-reviewer subagent:
Dispatch the code-reviewer agent (agents/code-reviewer.md) using the Agent tool. Fill in the template at code-reviewer.md.
Template placeholders:
{WHAT_WAS_IMPLEMENTED}— What was just built{PLAN_OR_REQUIREMENTS}— What it should satisfy{BASE_SHA}— Starting commit{HEAD_SHA}— Ending commit{DESCRIPTION}— Brief narrative
3. Respond to findings:
- Resolve Critical findings immediately
- Resolve Important findings before advancing
- Log Minor findings for a future pass
- Object with evidence if the reviewer is mistaken
Walkthrough
[Just completed Task 3: Add data validation layer]
You: Initiating quality gate before proceeding.
BASE_SHA=$(git log --oneline | grep "Task 2" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)
[Launch code-reviewer agent (agents/code-reviewer.md)]
WHAT_WAS_IMPLEMENTED: Input validation and sanitization for all API endpoints
PLAN_OR_REQUIREMENTS: Task 3 from docs/plans/api-hardening-plan.md
BASE_SHA: c4e19a7
HEAD_SHA: 8b2f305
DESCRIPTION: Added validateRequest() and sanitizeInput() with 5 rule types
[Subagent returns]:
Strengths: Comprehensive rule coverage, solid test assertions
Issues:
Important: Missing rate-limit header on validation error responses
Minor: Hardcoded threshold (50) for payload size check
Assessment: Ready to proceed after addressing Important item
You: [Fix rate-limit header]
[Continue to Task 4]
Cognitive Traps
| Rationalization | Truth |
|---|---|
| "It's a tiny change — no review needed" | Small diffs cause large outages. Review everything. |
| "I tested it exhaustively" | Testing and review catch fundamentally different classes of issues. |
| "Review will slow momentum" | Fixing production incidents slows momentum far more. |
| "The reviewer won't follow this code" | If a reviewer cannot follow it, neither will the next engineer. |
| "I'll batch review on the next PR" | Quality debt compounds. Review now or pay compounded interest later. |
Integration
godmode:delegated-execution:
- Review after EACH delegated task
- Surface defects before they cascade
- Resolve before starting the next task
godmode:task-runner:
- Review after each batch of tasks
- Collect feedback, apply corrections, continue
Ad-Hoc Development:
- Review before landing
- Review when blocked
Guardrails
Prohibited:
- Skipping review because "it's straightforward"
- Ignoring Critical findings
- Advancing with unresolved Important findings
- Dismissing valid technical feedback without evidence
- Landing changes with open Critical or Important items
Mandatory:
- Review after every task in delegated-execution
- Include BASE_SHA and HEAD_SHA in every review request
- Respond to Critical findings immediately
- Object with code or test evidence when disputing feedback
- Request clarification when feedback is vague
Process Diagram
START: Work finished
|
+-- Suite green? --NO--> Fix tests first
| |
| YES
| |
+-- Changes committed? --NO--> Commit changes
| |
| YES
| |
+-- Determine BASE_SHA and HEAD_SHA
| |
+-- Launch code-reviewer agent (agents/code-reviewer.md)
| |
+-- Wait for results
| |
+-- Critical items? --YES--> Fix now, re-review
| |
| NO
| |
+-- Important items? --YES--> Fix before advancing
| |
| NO
| |
+-- Log Minor items for later
| |
+-- ADVANCE to next task
See reviewer template at: quality-gate/code-reviewer.md
More from noobygains/godmode
intent-discovery
Use when starting any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements, and design before implementation.
15agent-messaging
Use when dispatching subagents, composing prompts for teammates, structuring handoff reports, or managing context boundaries between agents. Covers both subagent prompts and team-level messaging.
15fault-diagnosis
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
15merge-protocol
Use when implementation is finished, tests are green, and you need to decide how to land the work - presents structured integration paths for local merge, pull request, deferral, or abandonment
14quality-enforcement
Use when preparing code for commit, PR, or merge - covers linting, type safety, bundle budgets, coverage thresholds, complexity limits, dependency audit, and dead code detection
14pattern-matching
Use when contributing code to an existing project - guarantees that every new line mirrors the established conventions, naming schemes, architectural layering, directory layout, and stylistic choices already present in the codebase rather than drifting toward generic AI defaults
14