feature-review

name	feature-review
description	This skill should be used when the user invokes "/feature-review", asks to "review this feature for bugs", "analyze this feature", "check for potential bugs", "do a feature analysis", or wants a structured bug risk assessment of a codebase feature. Always use this skill for feature-level bug analysis and risk reporting.

Feature Review — Bug Risk Analysis

Perform a structured bug risk analysis on a given feature. The goal is to surface potential bugs, edge cases, and vulnerabilities a senior engineer would catch in a code review — before they reach production.

Step 1: Identify the Scope

If the user has selected code in the editor, use that as the primary input. Otherwise, ask:

"Which feature or files should I analyze? You can share file paths, paste code, or describe the feature."

Gather enough context to understand:

• The entry point (API route, function, service, etc.)
• Any related files (services, repositories, schemas, models, middleware)
• The intended behavior (what the feature is supposed to do)

Read all relevant files before proceeding. Trace the full call chain from API layer down to the database if applicable.

Step 2: Analyze Using the Bug Matrix

Evaluate the feature across all 10 dimensions. For each dimension, identify concrete issues — not generic observations. If a dimension is clearly not applicable, note it briefly and move on.

Dimension	Questions to Ask
Happy Path	Does it work under normal/expected inputs?
Edge Cases	Empty input, max values, boundary conditions?
Error Handling	What happens on invalid input, DB failure, timeout?
Auth/AuthZ	Who can access it? Are permissions enforced correctly?
Data Integrity	Is data saved correctly? Are constraints respected?
Concurrency	What if two requests hit simultaneously? Race conditions?
Performance	N+1 queries? Unindexed columns? Slow paths?
Security	Injection, over-posting, exposed sensitive fields?
Contract	Does the response schema match the spec/frontend expectation?
Side Effects	Does it trigger anything unexpected (events, emails, jobs, etc.)?

Step 3: Write the Report

Create a markdown report at report/<feature-name>-review.md (create the report/ directory if it doesn't exist). Use the following structure:

# Feature Review: <Feature Name>

**Date:** <today's date>
**Scope:** <files or entry points analyzed>

## Summary

<2–3 sentence overview of the feature and overall risk level: Low / Medium / High / Critical>

## Bug Risk Matrix

### Happy Path
<findings or "No issues found">

### Edge Cases
<findings or "No issues found">

### Error Handling
<findings or "No issues found">

### Auth / AuthZ
<findings or "No issues found">

### Data Integrity
<findings or "No issues found">

### Concurrency
<findings or "No issues found">

### Performance
<findings or "No issues found">

### Security
<findings or "No issues found">

### Contract
<findings or "No issues found">

### Side Effects
<findings or "No issues found">

## Critical Issues

List only issues that could cause data loss, security breach, incorrect behavior in production, or broken user experience. Number them. Include:
- What the bug is
- Why it matters
- A concrete fix or mitigation

## Recommendations

Numbered list of improvements beyond critical issues — things that reduce risk, improve resilience, or follow best practices.

## Verdict

**Risk Level:** Low / Medium / High / Critical
**Recommended Action:** Ship / Ship with fixes / Block

Guidelines

• Be specific. Reference actual line numbers, variable names, and function names where possible.
• Don't pad the report. If a dimension has no issues, say so clearly and move on.
• Prioritize ruthlessly. Not every observation deserves a "Critical Issues" entry — only things that would cause a real problem in production.
• Think like a senior engineer doing a pre-deploy review, not a linter.
• If the feature spans multiple layers (API, service, repository, DB), trace the full flow — bugs often hide at layer boundaries.