go-logic-review

Go Logic Review

Purpose

Audit Go code for business logic correctness. Core question: "Does the code do what it's supposed to do?"

Key distinction from other 6 vertical skills: they use pattern matching (see SQL → check injection, see goroutine → check race). This skill uses semantic understanding — understand the code's intent, then compare with its implementation.

This skill relies primarily on AI's general reasoning ability, not heavy reference files. The checklist provides the review framework; AI provides the reasoning.

This skill does NOT cover: security patterns, concurrency patterns, performance patterns, code style, test quality, or error handling patterns — those belong to sibling skills.

When To Use

• Any code change that modifies behavior
• Code contains conditional branches (if/else, switch)
• Code contains data transformation or processing
• Code contains state management or state transitions
• Default dispatch: always run (any code change can introduce logic errors)

When NOT To Use

• Pure refactoring with no behavior change
• Config-only changes
• Security vulnerability patterns → go-security-review
• Concurrency patterns → go-concurrency-review
• Code style → go-quality-review

Mandatory Gates

1) Context Understanding Gate (unique to this skill)

Before evaluating correctness, understand the INTENT:

• Read function name, comments, docstring
• Read caller context — who calls this function, what do they expect?
• Read related tests — they document expected behavior
• Read commit message / PR description if available

If intent is ambiguous after these steps, flag as "unclear intent — needs clarification" rather than guessing. Do not report uncertain intent as a confirmed defect.

2) Anti-Example Suppression Gate

MUST cite evidence of intent mismatch. Category match alone insufficient.

Embedded anti-examples:

• "Function name doesn't match behavior" — when you cannot verify the expected behavior from available context (don't guess business rules you don't know).
• "Off-by-one in pagination" — when the code follows the framework's pagination convention (0-based vs 1-based varies by framework). Verify convention before flagging.
• "Missing state transition validation" — when the state machine is intentionally permissive by design (e.g., admin override paths).
• "Unused function parameter" — this is a quality/style issue (go-quality-review), not a logic issue. Only flag here if the unused parameter indicates a logic bug (function ignores input it should use).
• "Return value could be nil" — when callers already handle nil (check all callers before flagging).