// Review Remix pull requests from a local development checkout. Use when asked to review a PR, inspect a pull request diff, or produce a thorough reviewer-style assessment.
| name | review-pr |
| description | Review Remix pull requests from a local development checkout. Use when asked to review a PR, inspect a pull request diff, or produce a thorough reviewer-style assessment. |
Use this skill to review a GitHub pull request for remix-run/remix from a local checkout. Build the review context yourself from git, GitHub metadata, and the repository. Keep the review focused on the PR diff and on issues that would materially affect correctness, security, performance, maintainability, or release readiness.
gh pr view to gather the title, body, base branch, head branch, author, and current state.origin/main unless the user names a different base.git diff --stat <base>...<head>git diff --name-status <base>...<head>git diff --unified=80 <base>...<head> for the files that matter mostgit log --oneline <base>...<head> when commit shape helps explain intentApply the Remix repo conventions while reviewing:
packages/.src/*.ts files.src/lib is implementation-only; avoid requesting thin pass-through wrappers there.import type and export type with .ts extensions.remix/ui code in this repository intentionally uses components that return functions. Before flagging framework-level JSX or component-runtime behavior, compare against nearby package patterns and template examples under template/app.Prioritize high-signal findings:
Do not spend space on style-only nits unless they materially affect maintainability. If a concern depends on an assumption, state the assumption and what code led you there.
Do not run validation commands by default for a review. If the user asks for validation, choose the narrowest useful command first, such as a single test file, package test, changed-package typecheck, or changed-package lint.
In the final review, clearly distinguish:
Never claim a command passed unless you ran it or directly inspected a reliable status for the exact PR head.
Return markdown using this structure unless the user asks for a different format:
## PR Review
Verdict: one short sentence
Findings:
- one bullet per finding, ordered by severity, with file/line references where possible
Completeness:
- concise bullets about missing pieces or explicit confirmation that the PR looks complete
Validation:
- commands run, CI inspected, or a clear statement that no validation was run
If there are no meaningful findings, say that explicitly under Findings and call out any residual risk or test gaps.
Build and review Remix 3 applications using the `remix` npm package and subpath imports. Use when working on Remix app structure, routes, controllers, middleware, validation, data access, auth, sessions, file uploads, server setup, UI components, hydration, navigation, or tests.
Create or align a package in the Remix monorepo to match existing package conventions. Use when adding a brand new package under packages/, or when fixing an existing package's structure, test setup, TypeScript/build config, code style, and README layout to match the rest of Remix 3.
Create GitHub pull requests with clear, reviewer-friendly descriptions. Use when asked to open or prepare a PR, especially when the PR needs strong context, related links, and feature usage examples. This skill enforces concise PR structure, avoids redundant sections like validation/testing, and creates the PR with gh CLI.
Publish a placeholder npm package at version 0.0.0 so package names are reserved and npm OIDC permissions can be configured before CI publishing. Use when creating a brand-new package that is not ready for full release.
Safely replace one GitHub pull request with another. Use when a user says a PR supersedes/replaces an older PR, asks to auto-close a superseded PR, or needs guaranteed closure behavior after merge. This skill explicitly closes the superseded PR with gh CLI and verifies final PR states instead of relying on closing keywords.
Write, refactor, or review TypeScript code with strict, precise, maintainable types and without unnecessary `any`, type assertions, or type suppressions. Use when working on `.ts` or `.tsx` files, public APIs, generics, discriminated unions, type guards, tsconfig/module settings, declaration-facing code, or any change where TypeScript type quality affects correctness in the Remix repo.