← Back to Game developers

Skill · Version 1.0.0

Contextual code review

Traces a change through callers, guards and data transformations to distinguish real regressions from unrelated existing issues.

contextual-code-review

Team members using this skill

See how it helps

When is it useful?

Use when a small diff affects shared contracts, state transitions or high-risk data.

What does it help you do?

  • Checks existing upstream validation before reporting a supposedly missing guard.
  • Follows input through domain rules, persistence and serialization.
  • Focuses findings on introduced or worsened defects with concrete consequences.

Try asking this

Review this response-shape change through all callers and serializers, identifying only actionable compatibility failures caused by the change. Trace a nullable field into an older client's renderer. Report a failure only when the changed response can reach that consumer without an existing guard.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Contextual Code Review

Reading only the green and red lines of a diff misses the most dangerous bugs. A change is safe only in the context of its callers, dependencies, data contracts, and runtime environment (Michael Feathers & Michael Fagan).

Thinking Sequence for Every Review

  1. What must this change achieve?
  2. What is the accepted scope and expected behavior?
  3. Where does the code implement it?
  4. What happens on the main path, error paths, and boundary cases?
  5. What does it alter in existing system behavior?
  6. Which claims are backed by real checks?
  7. Is there a concrete, actionable defect that requires a fix?

Workflow

  1. Expand context beyond the modified lines:
    • Inspect all callers of any modified function, hook, component, or endpoint to verify their assumptions about arguments, return values, nullability, and thrown errors still hold.
    • Inspect all callees and existing guards (upstream middleware, schema validators, database constraints, transactions) before claiming a check is missing.
  2. Trace control flow and data transformations end to end:
    • Follow data from entry point (HTTP request, CLI arg, UI event, queue payload) through validation, domain logic, persistence, and response serialization.
    • Check for off-by-one errors, inverted boolean conditions, unhandled null/undefined, mutated shared references, unawaited promises, and resource leaks.
  3. Separate new regressions from pre-existing technical debt:
    • Introduced or worsened by this change: In scope for blocking or targeted review findings.
    • Pre-existing issue in untouched code: Only flag if the current change directly triggers or amplifies it, and explicitly label it as pre-existing rather than blaming the diff.
  4. Calibrate review depth to risk:
    • Spend deep analytical effort on state transitions, permissions, financial/usage math, migrations, and public contracts; never pad a review with subjective naming or formatting nitpicks.

Included files 1

  • SKILL.md