mcpField
L
liveview-code-review

liveview-code-review

github.com/existential-birdsTesting & quality8588 installsUpdated 11w ago
Repository

About liveview-code-review

A code-review skill for Phoenix LiveView projects. It provides lifecycle, data-management, component, and security checks, with gates intended to ground findings in verified evidence.

Key features

  1. 01LiveView lifecycle checks
  2. 02Assigns, streams, and async-state guidance
  3. 03Function and LiveComponent review
  4. 04Authorization and client-data validation checks
  5. 05Evidence and context-sensitive review gates

Use cases

  1. 01Reviewing LiveView event authorization
  2. 02Checking async loading and error handling
  3. 03Assessing data handling for large collections
  4. 04Reviewing component and slot usage

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/existential-birds/beagle --skill liveview-code-review

After installing, type/liveview-code-reviewin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
assigns-streams.md
components.md
lifecycle.md
security.md

Details

From the project README

LiveView Code Review

Quick Reference

Issue TypeReference
mount, handle_params, handle_event, handle_asyncreferences/lifecycle.md
When to use assigns vs streams, AsyncResultreferences/assigns-streams.md
Function vs LiveComponent, slots, attrsreferences/components.md
Authorization per event, phx-value trustreferences/security.md

Review Checklist

Critical Issues
  • No socket copying into async functions (extract values first)
  • Every handle_event validates authorization
  • No sensitive data in assigns (visible in DOM)
  • phx-value data is validated (user-modifiable)
Lifecycle
  • Subscriptions wrapped in connected?(socket)
  • handle_params used for URL-based state
  • handle_async handles :loading and :error states
Data Management
  • Streams used for large collections (100+ items)
  • temporary_assigns for data not needed after render
  • AsyncResult patterns for loading states
Components
  • Function components preferred over LiveComponents
  • LiveComponents preserve :inner_block in update/2
  • Slots use proper attr declarations
  • phx-debounce on text inputs

Valid Patterns (Do NOT Flag)

  • Empty mount returning {:ok, socket} - Valid for simple LiveViews
  • Using assigns for small lists - Streams only needed for 100+ items
  • LiveComponent without update/2 - Default update/2 assigns all
  • phx-click without phx-value - Event may not need data
  • Inline function in heex - Valid for simple transforms

Context-Sensitive Rules

IssueFlag ONLY IF
Missing debounceInput is text/textarea AND triggers server event
Use streamsCollection has 100+ items OR is paginated
Missing auth checkEvent modifies data AND no auth in mount

Critical Anti-Patterns

Socket Copying (MOST IMPORTANT)
# BAD - socket copied into async function
def handle_event("load", _, socket) do
  Task.async(fn ->
    user = socket.assigns.user  # Socket copied!
    fetch_data(user.id)
  end)
  {:noreply, socket}
end

# GOOD - extract values first
def handle_event("load", _, socket) do
  user_id = socket.assigns.user.id
  Task.async(fn ->
    fetch_data(user_id)  # Only primitive copied
  end)
  {:noreply, socket}
end
Missing Authorization
# BAD - trusts phx-value without auth
def handle_event("delete", %{"id" => id}, socket) do
  Posts.delete_post!(id)  # Anyone can delete any post!
  {:noreply, socket}
end

# GOOD - verify authorization
def handle_event("delete", %{"id" => id}, socket) do
  post = Posts.get_post!(id)

  if post.user_id == socket.assigns.current_user.id do
    Posts.delete_post!(post)
    {:noreply, stream_delete(socket, :posts, post)}
  else
    {:noreply, put_flash(socket, :error, "Unauthorized")}
  end
end

Hard gates (sequence)

Advance only when each pass condition is objectively true (prevents reporting without evidence):

GatePass condition
G1 — Files in evidenceYou have an explicit list of paths under review (e.g. *.ex, *.heex, or the paths the user named). Every finding names a file from that list.
G2 — Verification protocolYou loaded review-verification-protocol and applied its Pre-Report Verification (and issue-type sections where relevant) before treating something as a finding.
G3 — Line anchorsEach finding uses [FILE:LINE] where that line exists in the current file (confirmed by read/grep output, not inferred).
G4 — Valid-pattern screenYou checked the finding against Valid Patterns (Do NOT Flag) and Context-Sensitive Rules; if it matches a “do not flag” case or fails a “Flag ONLY IF,” you do not report it.

Issue format

Use [FILE:LINE] ISSUE_TITLE for each finding.

Comments

Markdown supported