agentsclimarketplace

Code review

Skill justincordova/agents/skills/code-review

A structured AI coding workflow with skills, agents, and commands that make AI think before it builds.

Install
npx -y skills add justincordova/agents --skill code-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when reviewing code for quality, bugs, security, and correctness. Load before any code review, whether reviewing your own work or someone else's.

SKILL.md

3.4 KB, as published. Nobody here has run it

Code Review

Overview

Thorough code review methodology: correctness, security, error handling, concurrency, and design. Think like a senior engineer reading this for the first time.

Core principle: Read everything before writing anything. Understand what it's trying to do, trace what it actually does, find where those diverge.

The Process

1. Establish Context

  • What language, framework, and stack?
  • What kind of code is this? (API, CLI, library, frontend, data pipeline)
  • What is this code supposed to do?
  • What changed? (diff, PR description, commit messages)

2. Read Everything

Read every file completely. Do not skim.

For each function, ask:

  1. What is this supposed to do?
  2. What does it actually do?
  3. Under what conditions do 1 and 2 diverge?

3. Mentally Simulate Execution

Run it in your head under adverse conditions:

  • Empty, null, zero, or malformed input
  • Two requests at the same time
  • Slow or failing dependencies (database, API, filesystem)
  • The 1000th call. Large datasets. Deep recursion.
  • Attacker-controlled input
  • Error paths — does cleanup still run?

4. Trace Data Flow

For any external input (user input, request body, env var, file, network):

  • Where does it go?
  • Is it validated?
  • Does it reach a query, command, file path, log, or response unmodified?

What to Look For

Correctness

  • Does the code do what it claims?
  • Variables mutated inside loops corrupting logic
  • Conditions that can never be true
  • Off-by-one errors
  • Return values silently discarded

Error Handling

  • Every operation that can fail must handle it, propagate it, or document why it's safe to ignore
  • Silent failures and swallowed exceptions are bugs
  • Partial failures leaving inconsistent state are serious bugs

Security

  • Trace user input: does it reach a query, shell command, file path, or response without sanitization?
  • Auth checks: does it verify identity AND ownership?
  • Can auth be bypassed by hitting a different route or HTTP method?
  • Are secrets, tokens, or PII being logged?
  • Passwords hashed properly? (bcrypt/argon2, not MD5/SHA1)
  • Hardcoded credentials anywhere?
  • Input validation: type checked, length bounded, format validated

Concurrency

  • Shared state with unsynchronized access?
  • Races between response and background work?
  • Leaked goroutines/threads?

Resource Management

  • Anything opened must be closed
  • Cleanup runs on error paths
  • No resource leaks inside loops

Data Correctness

  • Floats for money or precision values
  • Timezone-naive datetimes
  • Integer overflow
  • ReDoS on user-controlled regex

Design

  • Is this solving the right problem?
  • Is the abstraction appropriate?
  • Would this be hard to test, extend, or understand in 6 months?

Output Format

Critical — broken behavior, data loss, security vulnerability, crash risk Important — incorrect logic, unhandled errors, performance problems Suggestion — improvements, naming, style

For each finding:

  • File and line number
  • What the code does vs. what it should do
  • Concrete fix

Only report findings grounded in actual code with a specific line. Do not speculate.

Open with a brief summary: stack, what the code does, overall quality. Close with highest-priority items first.

Do not make edits. Report only.

Gives 0 of the 12 instructions most code review skills give

Counted across 610 of the 674 authors here whose files we hold, read 2026-08-06

  • push back with technical reasoning if wrongin 60 of 610, across 24 files
  • ask for clarification on unclear itemsin 51 of 610, across 16 files
  • fix critical issues immediatelyin 45 of 610, across 29 files
  • implement one item at a timein 45 of 610, across 11 files
  • group findings by severityin 44 of 610, across 43 files
  • verify feedback against the codebasein 42 of 610, across 8 files
  • dispatch a code reviewer subagentin 39 of 610, across 23 files
  • fix important issues before proceedingin 37 of 610, across 22 files
  • test each fix individuallyin 35 of 610, across 7 files
  • reply in github comment threadsin 33 of 610, across 5 files
  • check for security vulnerabilitiesin 31 of 610, across 27 files
  • factualize corrections without over-explainingin 30 of 610, across 2 files

Said here and by no other author read

  • ask what each function should do
  • ask where intent and execution diverge
  • mentally simulate execution under adverse conditions
  • trace data flow from all external input
  • open with a summary of code and quality
  • classify findings as critical, important, or suggestion

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.