Code Reviewer

Goal: Produce a code review report (best practices, security, style, complexity) with file:line findings and a clear Approval Status for pipeline or human use.

Description

Automated code review checking for best practices, security vulnerabilities, code smells, and style violations.

Usage

• •"Review PR #123"
• •"Check [file] for issues"
• •"Review the code in [directory]"
• •"What's wrong with this code: [code snippet]"

When run by pipeline with --files or --json, also end with a one-line Approval Status: APPROVED, APPROVED WITH COMMENTS, or NOT APPROVED.

Pipeline Contract (sdlc-full.lobster and sdlc-tdd-full.lobster)

Inputs (when used in pipeline; bin wrapper passes --files or PR context):

• •files (array of paths) or pr_number (number). If PR: fetch diff via gh pr diff <pr_number>.
• •security_report (JSON, optional): Security scan results from security-scanner
• •quality_report (JSON, optional): Quality gate results from quality-gate-checker
• •stories (JSON array, optional): User stories for acceptance criteria verification
• •strict_mode (boolean, optional): If true, fail recommendation on warnings.

Output: JSON with structure:

{
  "approval_status": "APPROVED",
  "code_review": {
    "critical_issues": 0,
    "warnings": 2,
    "suggestions": 5
  },
  "security_summary": {
    "status": "PASS",
    "vulnerabilities": 0
  },
  "quality_summary": {
    "coverage_percent": 82,
    "complexity_max": 8,
    "linting_errors": 0
  },
  "acceptance_criteria_met": true
}

Implementation

Execute in order. Do not run the Lobster tool or any pipeline. Prefer workspace-relative paths. Use bash for gh/linters.

Step 0: Review Quality and Security Reports (NEW)

• •If security_report provided: Check for vulnerabilities, failed OWASP checks
• •If quality_report provided: Check coverage, complexity, linting status
• •If security_report.status = "FAIL" OR quality_report.status = "FAIL":
  • •Set approval_status = "NOT APPROVED"
  • •List blocking issues in review findings
  • •Include specific security vulnerabilities or quality failures

Step 1: Obtain Code to Review

• •If input is a PR number: run gh pr diff <number> and capture output; optionally gh pr view <number> for title/body.
• •If input is a list of files: read_file each path (workspace-relative).
• •If input is a directory: list_dir then read_file key files (prioritize source over tests). Prefer diff when available (e.g. git diff main -- <files>).

Step 2: Run Static Analysis (by language)

• •Python: Run bandit -r <path> -f txt (security); flake8 <path> or ruff check <path> (style); radon cc <path> -a (complexity). If a linter is not installed, say so and continue with manual review.
• •JavaScript/TypeScript: Run eslint <path> or npx eslint <path>. If missing, say so and continue with manual review.
• •Go: Run golangci-lint run <path>. If missing, say so and continue with manual review.
• •Generic: Grep for dangerous patterns (e.g. eval(, innerHTML =, raw SQL with string concat) and cite line numbers.

Step 3: Check Project Conventions

• •Read .editorconfig, .eslintrc*, pyproject.toml, or package.json for lint/format config if present; note any violations.
• •Look for existing test files for the same module; note coverage or missing tests.

Step 4: Verify Acceptance Criteria (if stories provided)

• •If stories provided, check that implementation matches acceptance criteria
• •For each story's Given-When-Then scenarios, verify corresponding tests exist and pass
• •Flag any acceptance criteria not covered by implementation
• •Set acceptance_criteria_met: true if all scenarios implemented

Step 5: Generate Review Report

• •Use the Output Format below. Include file:line for every finding. Group by Critical / Warning / Info.
• •Include Quality Gate Summary if quality_report provided (coverage, complexity, linting)
• •Include Security Report if security_report provided (vulnerabilities, OWASP checks)
• •End with exactly one line: Approval Status: NOT APPROVED if any critical issues; Approval Status: APPROVED WITH COMMENTS if only warnings; Approval Status: APPROVED if clean. This line allows the pipeline to parse the result.
• •If pipeline passed strict_mode: true, set NOT APPROVED if there are any warnings.
• •Output JSON block at end with approval_status, code_review, security_summary, quality_summary, acceptance_criteria_met

Output Format

# Code Review for [Feature/PR]

## Quality Gate Summary
✅ Coverage: 82% (target: 70%)
✅ Complexity: Max 8 (limit: 10)
✅ Linting: 0 errors, 2 warnings

## Security Report
✅ No SQL injection vulnerabilities
✅ No XSS vulnerabilities
✅ No hardcoded secrets
✅ Dependencies: 0 high, 3 medium, 5 low

## Review Findings
✅ **Passed (8 checks)**
⚠️ **Suggestions (2)**
❌ **Issues (0)**

### Passed Checks
- No security vulnerabilities detected
- Style conventions followed
- No code duplication
- Test coverage adequate (82%)
- Documentation present
- All acceptance criteria implemented
- SOLID principles followed
- Git commits well-structured

### Suggestions (Non-Blocking)
- Function `calculateMetrics()` has complexity 8 (close to limit)
  → api/metrics.py:42 - Consider simplifying for future maintainability
- Missing error handling in API call
  → api/client.py:105 - Add try-catch block for network errors

## Acceptance Criteria Verification
✅ STORY-001: All scenarios covered by tests
✅ STORY-002: Implementation matches Given-When-Then
✅ STORY-003: Edge cases handled

## Recommendations
1. Consider adding error handling to API client (non-blocking)
2. Keep monitoring complexity of calculateMetrics() function

## Approval Status
**APPROVED** ✅

```json
{
  "approval_status": "APPROVED",
  "code_review": {
    "critical_issues": 0,
    "warnings": 0,
    "suggestions": 2
  },
  "security_summary": {
    "status": "PASS",
    "vulnerabilities": 0
  },
  "quality_summary": {
    "coverage_percent": 82,
    "complexity_max": 8,
    "linting_errors": 0
  },
  "acceptance_criteria_met": true,
  "quality_score": 9.0,
  "security_score": 10.0
}