looply-code-review

name	looply-code-review
description	Use to execute structured code review like GitHub and CodeRabbit. Reviews code changes, classifies findings by severity and generates actionable suggestions. Formal delivery gate with approval checklist.

Use this skill when the user explicitly invokes $looply-code-review, asks to run /looply:code-review, or when review is needed for a delivery story. Workflow phase: delivery. Primary orchestrator: reviewer.

Quick usage:

• $looply-code-review <feature-name> <story-reference> "[focus-areas...]"

Primary references:

• Workflow playbook: ../../../../.looply/state/workflow-playbook.opencode.md
• Host status contract: ../../../../.looply/state/host-status-contract.json
• Managed pack: ../../../../.looply/managed/packs/software-delivery-suite
• Custom overrides: ../../../../.looply/custom
• Execution hints: ../../../../.looply/state/execution-hints.opencode.json
• Context index: ../../../../.looply/state/context-index.md
• Project context: ../../../../.looply/custom/project-context.md
• Session context: ../../../../.looply/custom/session-context.md
• Knowledge graph: ../../../../.looply/state/knowledge-graph.json

Usage:

• Explicit mention: $looply-code-review
• Workflow alias to honor: /looply:code-review
• Syntax in Codex: $looply-code-review <feature-name> <story-reference> "[focus-areas...]"

Example:

• $looply-code-review pix-webhook-retry story-01-retry-automatico "verify error handling and race conditions"

When to use:

• After story implementation, before advancing to release
• Standalone code review without full pipeline
• When story-to-production reaches the technical-review stage

Curated example guidance:

• ICL mode: on
• Use examples only for style, structure and quality calibration.
• Do not copy feature-specific names, identifiers or business details from examples.
• No example was selected for this workflow.

Review Flow

Stage 1: Load Context

1. Read the feature's workflow-status.md.
2. Load the associated story, tech-spec, ADR and implementation-summary.
3. Run looply refresh-code-context --check to ensure code-context is current.
4. Identify changed files via git diff.

Stage 2: Code Walkthrough

Generate a structured walkthrough of changes:

# Code Review Walkthrough

## Summary
- Changed files: 12
- Lines added: 340
- Lines removed: 85
- Affected modules: payments-api, webhook-dispatcher, retry-queue

## Walkthrough
1. `src/services/retry-queue.ts` (+120/-10)
   - New retry queue service with exponential backoff
   - Extracts retry logic from webhook-dispatcher
   
2. `src/api/webhooks.ts` (+45/-30)
   - Integrates with retry-queue service
   - Removes inline retry, delegates to queue

Stage 3: Findings by Severity

Classify each finding using GitHub/CodeRabbit severity:

Critical - Potential system failure, security or data loss Major - Significant impact on functionality or performance Minor - Recommended improvements, low impact Nitpick - Style, naming, preferences

For each finding, provide:

• File and line
• Problem description
• Fix suggestion (actionable)
• Severity

Stage 4: Review Report

Generate report in .looply/custom/features/<feature-name>/review-report.md:

# Review Report

## Status
Pending review

## Summary
- Total findings: 8
- Critical: 1
- Major: 2
- Minor: 4
- Nitpick: 1

## Walkthrough
[Stage 2 output]

## Findings

### Critical
1. **Race condition in consumer** (`src/services/retry-queue.ts:45`)
   Consumer accesses `pendingRetries` without lock, may process same message twice
   
   Suggestion: Add mutex or use atomic database transaction

### Major
2. **Missing error handling** (`src/api/webhooks.ts:78`)
   Retry-queue call without catch - silent failure in production
   
   Suggestion: Add try/catch with error log and metric

### Minor
3. **Magic number** (`src/services/retry-queue.ts:30`)
   Constant 5 for max retries without name
   
   Suggestion: Extract to constant MAX_RETRY_ATTEMPTS

## Compliance
- [x] Adheres to tech-spec
- [x] Follows codebase patterns
- [ ] Adequate test coverage (see coverage report)
- [x] Error handling documented

## Verdict
[ ] Approved - proceed
[x] Approved with comments - resolve Major/Minor before release
[ ] Rejected - requires significant refactoring

Stage 5: Decision

Present the verdict to the user with options:

# Review Decision

## Verdict: Approved with comments

1 Critical, 2 Major pending.

[o] OK - proceed to release
[r] Review - I want to resolve findings first
[v] View details - show each finding in detail

Execution rules:

1. Start by reading the workflow playbook and the feature state file.
2. Run looply refresh-code-context --check before the review.
3. If the user asked for help, explain syntax, arguments, example, expected output and next step without mutating state.
4. Classify all findings with severity (Critical/Major/Minor/Nitpick).
5. For each finding, provide file, line, description and actionable suggestion.
6. Critical findings block advancement to release.
7. Verify compliance with story criteria, tech-spec and ADR.
8. Use managed pack files as canonical process definition and write local state only under .looply/custom.
9. Respond in the same language as the user's input.
10. For existing projects, use the real local codebase as the primary source of truth and use context files only as accelerators.
11. Follow balanced interaction mode to avoid unnecessary repeated clarifications.
12. Keep the response visually structured with clear Markdown section titles.
13. Do not use emojis.

---

Composed Agent Context

The sections below were pre-composed by looply from agent context_slots.

Constraints

• Critical findings block advancement to release
• Provide actionable suggestions for each finding
• Verify compliance with story criteria and tech-spec

Escalation

• Escalate design issues to architect
• Escalate security findings to sre
• Escalate product conflicts to pm-analyst Arguments:
• feature-name: short identifier for the feature (required)
• story-reference: story being reviewed (required)
• focus-areas: optional areas to focus review on (optional)