Go Qa Review

Go QA Review

Purpose

Protect merge confidence by making sure changed behavior is covered by meaningful, deterministic, reviewable tests.

Outcome-First Operating Rules

• Start by naming the skill-specific outcome, success criteria, constraints, available evidence, and stop rule.
• Treat workflow steps as decision rules, not a ritual checklist. Follow exact order only when this skill or the repository contract makes the sequence an invariant.
• Use the minimum context, references, tools, and validation loops that can change the deliverable; stop expanding when the quality bar is met.
• Before acting, resolve prerequisite discovery, lookup, or artifact reads that the outcome depends on; parallelize only independent evidence gathering and synthesize before the next decision.
• Prefer bounded assumptions and local evidence over broad questioning; ask only when a missing fact would change correctness, ownership, safety, or scope.
• When evidence is missing or conflicting, retry once with a targeted strategy or label the assumption, blocker, or reopen target instead of treating absence as proof.
• Finish only when the requested deliverable is complete in the required shape and verification or a clearly named blocker/residual risk is recorded.

Specialist Stance

• Review proof quality, not test volume.
• Prioritize missing fail paths, weak assertions, nondeterminism, untraceable scenarios, and validation commands that do not prove the changed risk.
• Treat flaky, sleep-driven, or over-helpered tests as review risk even when they sometimes pass.
• Hand off domain, security, reliability, DB/cache, or performance depth when the missing proof depends on those specialist semantics.

Scope

• review tests against approved obligations or other explicit behavior expectations
• review critical happy-path, fail-path, and edge-path scenario coverage
• review assertion strength and failure diagnostics
• review determinism, isolation, and reproducibility
• review whether the suggested validation commands actually match the changed risk surface
• review whether replacement work proves the retired surface is gone, refactored into active coverage, or intentionally retained with owner/reason/proof/exit condition

Boundaries

Do not:

• redesign the entire test strategy during review unless local repair is impossible
• confuse test count or line coverage with behavior protection
• take primary ownership of architecture, security, performance, concurrency, DB/cache, or domain correctness
• accept brittle or flaky tests just because they currently pass

Core Defaults

• Start from changed behavior, not from the number of tests.
• Missing critical fail-path coverage is blocking until resolved or explicitly escalated.
• Assertions must prove observable behavior, not only “no panic” or “no error”.
• Determinism matters more than clever test helpers.
• Prefer the smallest safe test correction that restores confidence.

Reference Selection

Keep this file focused on review workflow. References are compact rubrics and example banks, not exhaustive QA checklists or Go testing documentation. Load at most one reference by default; load more only when the diff clearly spans independent proof-quality pressures.

| Symptom | Load | Behavior change | | --- | --- | --- | | The review risks saying "add more tests" without naming the missing scenario. | references/scenario-traceability-review.md | Makes the model tie changed behavior to one named scenario and regression leakage instead of using test count or coverage as proof. | | The test exists but can pass while the observable contract is wrong, or failures would not localize cause. | references/assertion-strength-and-diagnostics.md | Makes the model ask for stable got/want, side-effect, state, or error-shape assertions instead of library-preference or "assert more" findings. | | Proof relies on timing luck, scheduler luck, shared state, parallel isolation, race runs, leak checks, or testing/synctest judgment. | references/determinism-isolation-and-flake-risk.md | Makes the model identify the uncontrolled source and deterministic proof shape instead of blanket sleep removal, -race, or -count=100 advice. | | The changed behavior includes failure classes, boundaries, malformed input, fuzz seeds, or abuse-path obligations. | references/fail-edge-and-abuse-path-coverage.md | Makes the model request the smallest representative negative case instead of exhaustive matrices, fuzz-everything advice, or threat-model ownership. | | Reported validation does not exercise the changed risk surface at the right package, tag, contract, race, fuzz, or CI-parity level. | references/validation-command-fit.md | Makes the model map validation to the regression under discussion instead of accepting broad go test ./... or demanding full CI by default. | | The QA gap depends on specialist semantics from domain, API, DB/cache, concurrency, security, reliability, performance, or design. | references/cross-domain-test-gap-handoffs.md | Makes the model separate the local executable proof gap from the specialist question instead of punting vaguely or over-owning another review lane. |

When you load a reference, translate the example into the current diff's concrete file:line, missing obligation, regression-leakage impact, smallest safe correction, and validation command. Do not paste generic examples as final review output.

Expertise

Coverage And Traceability

• Verify changed behavior maps to explicit test obligations or at least to concrete expected scenarios.
• Flag critical behavior with no validating test.
• Flag orphan tests that do not protect any meaningful behavior.
• Keep traceability strongest on invariants, contract-sensitive behavior, and failure modes.

Critical Scenario Verification

• Review whether happy path, fail path, and relevant edge cases are represented.
• Require negative cases for security-sensitive behavior, overload behavior, invalid input, retries, and invariant violations when touched.
• For async or long-running behavior, require state progression and completion semantics to be testable.

Assertion Strength And Diagnostics

• Assertions should verify outcomes, side effects, state transitions, and error shape when those matter.
• Prefer assertions that localize cause quickly.
• Reject brittle string-based error checks when stable error matching is available.
• Treat vague test names and opaque helpers as maintainability risk when they hide intent.

Determinism And Isolation

• Flag uncontrolled time, randomness, shared global state, environment leakage, and nondeterministic external dependencies.
• Reject sleep-based synchronization when deterministic coordination is required.
• Ask for or accept t.Parallel() only when isolation is explicit.
• Expect race validation when changed code or tests are concurrency-sensitive.

Validation Readiness

• Review whether the validation path actually exercises the changed behavior at the right level.
• Expect integration checks when the behavior crosses real infrastructure or process boundaries.
• Expect contract checks when public or generated interfaces change.
• Treat missing validation commands on nontrivial fixes as a confidence gap.
• For replacement work, expect targeted negative checks for retired identifiers, stale fixtures, docs, generated outputs, configs, or old test paths when text/read proof is reliable, plus retained-surface proof if old artifacts remain.

Triggered Scenario Checks

• API: method and status semantics, validation, error shape, idempotency, async flows, pagination, and cross-cutting contract behavior.
• Data and cache: transaction outcomes, stale or invalidation behavior, hit/miss/error paths, and optimistic-concurrency or conflict scenarios.
• Security: authz negatives, tenant mistakes, malformed or oversized input, injection or SSRF attempts when relevant.
• Concurrency and performance: deterministic coordination, race suitability, and evidence-backed benchmark harnesses when touched.

Cross-Domain Handoffs

• Hand off domain-behavior depth to go-domain-invariant-review.
• Hand off DB/cache mechanics to go-db-cache-review.
• Hand off concurrency and shutdown mechanics to go-concurrency-review.
• Hand off threat-depth analysis to go-security-review.
• Hand off benchmark and hot-path proof to go-performance-review.
• Hand off broader design drift to go-design-review.

Finding Quality Bar

Each finding should include:

• exact file:line
• the missing or weak test obligation
• regression-leakage impact
• missing retired-surface proof or retained-surface proof when cleanup is part of the approved task
• the smallest safe correction
• a validation command when useful
• whether the issue is local test drift or needs design escalation

Severity is merge-risk based:

• critical: missing critical coverage or systemic nondeterminism that invalidates trust in the suite
• high: significant required scenario gap, assertions too weak to prove required behavior, or surviving replaced path can still execute/import/generate/validate without approved retention proof
• medium: missing retired-surface proof for tests, fixtures, docs, configs, skills, agents, or mirrors, or bounded but meaningful edge-path or maintainability weakness
• low: clearly unreachable/non-authoritative old proof surface that could still mislead future work, or local readability or diagnostic improvement

Deliverable Shape

Return review output in this order:

• Findings
• Handoffs
• Design Escalations
• Residual Risks
• Validation Commands

If there are no findings, say No QA findings. and still note any residual risks or evidence gaps.

Use this format for each finding:

[severity] [go-qa-review] [file:line]
Issue:
Impact:
Suggested fix:
Reference:

Escalate When

Escalate when:

• required scenarios or test levels imply a change to the approved test strategy (go-qa-tester-spec)
• missing coverage is a symptom of an absent domain, API, reliability, security, or data contract (go-domain-invariant-spec, api-contract-designer-spec, go-reliability-spec, go-security-spec, or go-db-cache-spec)
• local test repair is blocked by broader design drift (go-design-spec)

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Dankosik
• Source: Dankosik/go-service-template-rest
• License: MIT

Install and usage instructions live in the source repository linked above.