---

name: code-review description: Structured code review with OWASP awareness and 5 severity levels type: semantic user-invocable: true semantic: skillVersion: 1 permissions: graph: [read, write] proofs: [request] memory: [recall, remember] assertions: - predicate: "review:passed" requireProof: true - predicate: "review:finding" requireProof: false - predicate: "review:security_issue" requireProof: true queries: - predicate: "review:finding" scope: agent - predicate: "review:history" scope: namespace

code-review

Structured, comprehensive code review with OWASP Top 10 awareness and five severity levels. Inspired by best-practice review workflows used in production agent systems.

Review Methodology

1. Read the Entire Diff First

Before making any comment, read the complete diff from start to finish. Understand the full context of the change --- what is being added, removed, and modified --- before writing a single finding. Premature comments without full context lead to false positives and noise.

2. Severity Levels

Every finding is assigned one of five severity levels:

| Level | Meaning | Action Required | |-------|---------|-----------------| | critical | Exploitable vulnerability, data loss, or system compromise | Must fix before merge | | high | Significant logic error, race condition, or security weakness | Should fix before merge | | medium | Performance issue, missing validation, or suboptimal pattern | Fix recommended | | low | Style violation, naming issue, or minor improvement | Optional fix | | info | Observation, suggestion, or positive feedback | No action needed |

3. OWASP Top 10 Awareness

Security findings are mapped to the OWASP Top 10 (2021) categories with corresponding CWE IDs:

• A01 - Broken Access Control (CWE-284, CWE-285): Missing authorization checks, IDOR, privilege escalation, CORS misconfiguration, path traversal.
• A02 - Cryptographic Failures (CWE-327, CWE-328): Weak algorithms (MD5, SHA1 for security), hardcoded keys, missing encryption at rest/transit, insufficient key length.
• A03 - Injection (CWE-79 XSS, CWE-89 SQLi, CWE-78 OS Command): Unsanitized user input in SQL queries, shell commands, HTML output, LDAP queries, XPath, template engines.
• A04 - Insecure Design (CWE-840): Missing threat modeling, insecure business logic, insufficient rate limiting by design.
• A05 - Security Misconfiguration (CWE-16): Default credentials, unnecessary features enabled, overly permissive CORS, verbose error messages, missing security headers.
• A06 - Vulnerable and Outdated Components (CWE-1035): Known CVEs in dependencies, unmaintained libraries, missing security patches.
• A07 - Identification and Authentication Failures (CWE-287, CWE-384): Weak password policies, missing MFA, session fixation, credential stuffing exposure.
• A08 - Software and Data Integrity Failures (CWE-502): Insecure deserialization, missing integrity checks on CI/CD pipelines, unsigned updates.
• A09 - Security Logging and Monitoring Failures (CWE-778): Missing audit logs, no alerting on suspicious activity, insufficient log detail.
• A10 - Server-Side Request Forgery (SSRF) (CWE-918): Unvalidated URL redirects, internal service access via user-controlled URLs, DNS rebinding.

4. Language-Specific Checks

TypeScript

• Strict types enforced, no any usage
• Proper error handling (no swallowed exceptions, no empty catch blocks)
• Null/undefined safety (strict null checks, optional chaining)
• ESM imports (no require() in ESM modules)
• Async/await correctness (no floating promises, proper error propagation)

Python

• Type hints on all public functions
• Exception handling (no bare except:, specific exception types)
• Input validation (Pydantic models, dataclasses)
• f-string vs format() consistency
• Context managers for resource handling

Rust

• Unsafe blocks justified and minimized
• Error propagation via ? operator (no .unwrap() in library code)
• Lifetime annotations correct
• No unnecessary cloning
• Clippy-clean code

Go

• Error checking on all fallible calls (no _ for errors)
• Goroutine leak prevention (context cancellation, WaitGroups)
• Defer ordering (LIFO)
• Interface satisfaction at compile time
• Proper mutex usage (no lock-copy)

5. Output Format

Each finding is structured as:

File: <path>
Lines: <start>-<end>
Severity: critical | high | medium | low | info
Category: security | logic | performance | style | documentation
Description: <what the issue is>
Suggested Fix: <how to resolve it>
OWASP: <reference if applicable>
CWE: <CWE-ID if applicable>

6. Semantic Integration

• Use skill_assert with review:finding predicate for each finding discovered.
• Use skill_assert with review:passed (proof required) when no critical or high findings remain.
• Use skill_assert with review:security_issue (proof required) for security-category findings.
• Consult skill_memory_context for previous review history to detect recurring patterns.

7. Review Categories

Security: injection flaws, broken authentication, sensitive data exposure, cryptographic weaknesses, access control failures, SSRF, insecure deserialization.

Logic: null/undefined handling, race conditions, edge cases, off-by-one errors, boundary conditions, state management issues, infinite loops, deadlocks.

Performance: N+1 queries, unnecessary memory allocations, missing caching opportunities, unoptimized loops, redundant computations, blocking I/O in async contexts.

Style: naming conventions, code formatting, dead/unused code, import organization, comment quality, consistency with project conventions.

Documentation: missing JSDoc/docstrings, outdated comments, missing README updates, undocumented public APIs, missing changelog entries.