linear-review

name	linear-review
description	Review the pull request linked to a Linear ticket for correctness, style, and edge cases. Posts review findings. No code changes.
scopes	["linear","slack"]

Linear Review

Review the pull request associated with a Linear ticket. Your job is code review only — do NOT push commits or modify the PR branch.

Use the linear plugin tools (linear_issue_view, linear_issue_update, linear_issue_create, linear_comment_add, etc.) for all API operations.

Phase 1: Find the PR

1. Fetch the ticket with linear_issue (action: view).
2. Look for a PR link in the description or comments.
3. If no link, search by branch name: gh pr list --search "{issue-identifier}" or check for branches matching the issue identifier.
4. If no PR is found, report this on the ticket and stop.

Phase 2: Understand the Context

1. Re-read the ticket description to understand what the PR should accomplish.
2. Check if there's a triage report or implementation plan — the PR should address those findings.
3. Note the ticket's definition of done and test cases if present.
4. Check for an existing code review — if the description already contains a ## Code Review from a prior run, do not redo the full review. Focus only on changes made since that review, or skip if nothing has changed.

Phase 3: Review the Code

Read the full diff carefully with gh pr diff {number}.

Review Checklist

Correctness

• Does the code do what the ticket asks?
• Are there logic errors, off-by-one bugs, or missed branches?
• Are error cases handled? What happens when things fail?
• Are there race conditions or concurrency issues?

Edge Cases

• Null/undefined inputs
• Empty collections
• Boundary values (0, -1, MAX_INT)
• Malformed or unexpected data

Style & Consistency

• Does it follow existing codebase patterns?
• Naming conventions — variables, functions, files
• Code organization — is new code in the right place?
• No unnecessary changes (reformatting, unrelated refactors)

Performance

• N+1 queries or unnecessary loops
• Large allocations or memory leaks
• Missing pagination for unbounded lists
• Unnecessary network calls

Security

• Input validation at system boundaries
• Auth/authz checks
• Injection risks (SQL, command, XSS)
• Sensitive data exposure in logs or responses

Tests

• Are there tests? Do they cover the important cases?
• Do tests match the ticket's test cases (if specified)?
• Are tests testing behavior, not implementation details?
• Any flaky test patterns (timing, randomness, network)?

Phase 4: Post the Review

Update the ticket description with your review (use linear_issue action: update with appendDescription: true).

Review Format

---

## Code Review

### Verdict: [Approve / Request Changes / Needs Discussion]

### Summary
[1-2 sentence overall assessment]

### Findings

#### [Critical / Important / Suggestion] — [Short title]
**File:** `path/to/file.ts:42`
**Issue:** [What's wrong]
**Suggestion:** [How to fix it — be specific, show code if helpful]

[Repeat for each finding]

### What Looks Good
[Highlight things done well — good patterns, thorough error handling, clean abstractions]

### Test Coverage Assessment
[Are the tests sufficient? What's missing?]

Also post the review directly on the GitHub PR if you have access: gh pr review {number} --comment --body "..." or gh pr review {number} --request-changes --body "...".

Output Summary

After posting the review, respond with:

1. Verdict (Approve / Request Changes / Needs Discussion)
2. Number of findings by severity
3. One-sentence summary

Notes

• Be constructive — explain why something is an issue, not just that it is.
• Be specific — file paths, line numbers, concrete suggestions. "This could be better" is not helpful.
• Distinguish severity — not every finding is a blocker. Use Critical (must fix), Important (should fix), Suggestion (nice to have).
• Praise good work — call out things done well. Reviews shouldn't be exclusively negative.
• If the PR is trivially correct (typo fix, version bump), say so briefly and approve — don't over-review.