home / skills / mastra-ai / mastra / code-review

This skill provides structured TypeScript code review guidelines to assess correctness, quality, and performance in pull requests and reviews.

npx playbooks add skill mastra-ai/mastra --skill code-review

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.1 KB
---
name: code-review
description: Provides structured code review guidelines for TypeScript projects. Use when reviewing pull requests, analyzing code quality, or suggesting improvements.
license: MIT
---

# Code Review Guidelines

## Overview

This skill provides structured guidelines for reviewing TypeScript code. Apply these standards when reviewing pull requests, analyzing code quality, or suggesting improvements.

**Keywords**: code review, pull request, PR review, TypeScript, code quality, best practices, refactoring

## Review Checklist

### 1. Code Correctness

**Before approving, verify:**

- [ ] Logic is correct and handles edge cases
- [ ] Error handling is appropriate
- [ ] No obvious bugs or race conditions
- [ ] Tests cover the changes adequately

### 2. Code Quality

**Check for:**

- [ ] Clear, descriptive variable and function names
- [ ] Functions do one thing well (single responsibility)
- [ ] No excessive nesting (max 3 levels)
- [ ] DRY - no unnecessary duplication
- [ ] YAGNI - no speculative features

### 3. TypeScript Specific

**Ensure:**

- [ ] Proper type annotations (avoid `any`)
- [ ] Interfaces/types defined for complex objects
- [ ] Generics used appropriately
- [ ] Null/undefined handled safely
- [ ] `strict` mode compatible

### 4. Performance

**Look for:**

- [ ] Unnecessary re-renders (React)
- [ ] Missing memoization for expensive operations
- [ ] Inefficient loops or data structures
- [ ] Memory leaks (event listeners, subscriptions)

## Review Comments

### Comment Format

Use this format for review comments:

```
[severity]: brief description

Why: explanation of the issue
Suggestion: how to fix it (with code if helpful)
```

**Severity levels:**

- `[critical]` - Must fix before merge
- `[suggestion]` - Recommended improvement
- `[nit]` - Minor style preference
- `[question]` - Need clarification

### Example Comments

**Good comment:**

```
[suggestion]: Consider extracting this validation logic

Why: This 15-line validation block is hard to test in isolation
Suggestion: Move to a `validateUserInput(data)` function
```

**Bad comment:**

```
This is wrong, fix it.
```

## Common Issues

### Anti-patterns to Flag

1. **God functions** - Functions over 50 lines doing multiple things
2. **Prop drilling** - Passing props through 3+ component levels
3. **Magic numbers** - Unexplained literal values
4. **Catch-all error handling** - `catch(e) { console.log(e) }`
5. **Implicit any** - Missing type annotations on function parameters

### Security Concerns

Always flag:

- SQL/NoSQL injection vulnerabilities
- XSS opportunities (unsanitized user input in DOM)
- Hardcoded secrets or API keys
- Insecure randomness for security contexts
- Missing input validation on API endpoints

## Approval Guidelines

### Approve When

- All critical issues resolved
- Tests pass
- Code meets team standards
- No security concerns

### Request Changes When

- Critical bugs found
- Security vulnerabilities present
- Missing required tests
- Significant performance issues

### Leave Comments When

- Minor improvements possible
- Design alternatives worth discussing
- Documentation could be clearer

Overview

This skill provides structured code review guidelines tailored for TypeScript projects. It helps reviewers evaluate correctness, quality, TypeScript specifics, performance, and security in pull requests. Use it to produce consistent, actionable review comments and clear approval or change recommendations.

How this skill works

The skill inspects pull request changes against a checklist that covers logic, tests, naming, single-responsibility, and TypeScript typing practices. It highlights performance and security risks, suggests concrete fixes, and recommends when to approve, request changes, or leave comments. Review comments follow a severity-based template with Why and Suggestion sections for actionable feedback.

When to use it

  • Reviewing TypeScript pull requests before merging
  • Auditing code quality and test coverage for features or bug fixes
  • Identifying TypeScript typing and null-safety issues
  • Checking React components for rendering and memoization problems
  • Evaluating security, injection, and secret-management risks

Best practices

  • Verify logic and edge cases; ensure tests cover new behavior
  • Prefer clear names and single-responsibility functions; avoid god functions
  • Enforce TypeScript strictness: no implicit any and defined interfaces for complex shapes
  • Flag performance hotspots: unnecessary re-renders, heavy loops, missing memoization
  • Use the severity-based comment format: [critical], [suggestion], [nit], [question]

Example use cases

  • Review a feature PR adding new API routes to ensure input validation and test coverage
  • Audit a React component refactor for prop drilling, memoization, and unnecessary re-renders
  • Find and fix implicit any types, unsafe null handling, or missing generics
  • Detect and report security issues like hardcoded secrets, SQL/NoSQL injection risks, or XSS vectors
  • Recommend extracting long validation or business-logic blocks into testable helper functions

FAQ

What counts as a critical issue?

Critical issues are correctness, security, or missing required tests that block merging until fixed.

How should I format review comments?

Use the template with a severity tag, a brief description, Why explaining the impact, and a Suggestion with a concrete fix or code sample.

When is it OK to use any?

Avoid any in production code; only use it temporarily with a clear TODO and follow-up plan if a safe typed alternative is not yet available.