Remix v2 代码审查

参数

• --parallel：当代理支持子代理时（参见第 5 步），提示按技术领域并行执行。若不支持，则仍以串行方式运行，输出结果完全一致。
• 路径：目标目录（默认为当前工作目录）

第 1 步：识别已变更文件

git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '.(tsx?|jsx?|mjs|cjs|css)$|^(remix|vite).config.'

若无任何输出，请在继续前向用户索要明确的文件路径列表。

第 2 步：检测 Remix v2 及相关技术栈

# 在 package.json 中检测 Remix v2（任一官方适配器）
grep -E '"@remix-run/(react|node|cloudflare|deno|serve)"' package.json | head -3

# 确认应用路由布局
ls app/routes/ 2>/dev/null | head -5

# meta 导出（路由元数据）
grep -rE 'export const meta|export function meta|export let meta' app/ --include="*.tsx" --include="*.ts" -l | head -3

# Sessions / Cookies / 认证
grep -rE 'createCookieSessionStorage|getSession(|commitSession(|destroySession(' app/ --include="*.ts" --include="*.tsx" -l | head -3

# 表单基础能力（forms-review）
grep -rE 'useFetcher(| / 手动 fetch（即使未导入 Remix 相关模块，forms-review 也会触发）
grep -rE '(^|[^.])

若 package.json 检查无任何匹配结果，请立即中止并告知用户：本技能仅适用于 Remix v2 项目。
第 3 步：加载审查验证协议
在对代码做出任何实质性判断前，必须先加载 review-verification-protocol 技能。该协议是跨插件的标准规范；禁止替换为任一框架专属副本。
通过第 5 步前的必要条件：该技能必须已成功加载（或其检查清单已在上下文中打开）。在该关卡通过前，不得进行严重性分级，也不得撰写任何发现项。
第 4 步：加载技能
请逐个阅读下方适用的技能文档（即打开其 SKILL.md 文件），确保在审查对应领域前，已将相应指导纳入上下文。
始终加载以下技能（一个非平凡的 Remix v2 应用必然涉及全部六个领域）：

remix-v2-routing-review
remix-v2-data-flow-review
remix-v2-forms-review
remix-v2-error-boundaries-review
remix-v2-perf-ssr-review
remix-v2-meta-sessions-review

检测遥测（记录各领域审查实际覆盖范围；不影响技能加载——所有六项技能均强制加载，但需在最终报告的“覆盖率”章节中明确标注各领域是否命中）：



条件
技能



app/routes/ 目录存在
remix-v2-routing-review


发现 loader 或 action 导出
remix-v2-data-flow-review


发现 、useFetcher、useSubmit、useNavigation、原生  或手动 fetch(
remix-v2-forms-review


发现 ErrorBoundary 或 useRouteError
remix-v2-error-boundaries-review


发现 headers 导出、defer( 调用、.server.ts/.client.ts 文件，或 prefetch=/
remix-v2-perf-ssr-review


发现 meta 导出或 session/cookie 辅助函数
remix-v2-meta-sessions-review


若某检测项未返回任何匹配结果，请在报告的“覆盖率”章节中明确注明——该技能仍会加载，但审查员应注明该领域无可供审查的代码表面。
第 5 步：执行审查
若代理支持子代理（且已指定 --parallel 参数或当前场景适合并行），则为每个领域并行分派一个子代理；否则，在同一上下文中按顺序依次执行全部六个领域的审查。两种路径产出的最终报告内容完全一致。
并行路径：

预先完成全部领域检测
为每个领域分派一个子代理，各子代理仅加载自身对应技能，并仅审查其所属领域
等待所有子代理返回结果
将全部发现项合并为单一输出

串行路径：

加载所有适用技能
首先审查路由及嵌套路由结构
审查 loader/action 数据流
审查表单及渐进增强实践
审查错误边界
审查 meta、sessions 及 headers/SSR
合并全部发现项

第 6 步：验证发现项
在报告任一问题前，请务必完成以下验证：

重读实际代码（而非仅依赖 diff 上下文）
对于“未使用”类声明——是否搜索了全部引用，包括路由文件约定？
对于“缺失”类声明——是否检查了父级路由、root.tsx 或框架默认行为？
对于语法类问题——是否对照 Remix v2 官方文档（而非 v1 或 React Router v7）进行了核实？
剔除仅属风格偏好、而非真实问题的发现项

提升为 Critical/Major 级别前的必要条件：针对该问题，须满足上述第 (2)–(4) 条，并提供具体证据——例如打开的文件位置 FILE:LINE、引用的 grep 输出结果，或所引用的父级/框架代码片段；不可仅依赖 diff 上下文。
第 7 步：审查收敛性

单次遍历：在一次审查中完整覆盖路由、数据流、表单、错误处理、SSR/性能、meta/sessions、类型安全及安全性等全部领域。提交前，请确认所建议的修复方案本身是否会触发新的问题——如会，请一并纳入本次报告。
范围限定：仅审查 diff 中的代码及其直接关联的既有代码。测试覆盖缺失仅计为一项 Minor 问题，不提供具体实现建议；禁止引入新依赖。
修复复杂度：对既有代码的修改，其真实难度决定严重性等级。对全新代码（如新增模块、依赖、测试套件、抽取抽象）的请求，一律归类为 Informational，不构成阻塞项。
复审：仅验证先前修复是否生效——不进行新问题发现，不重新标记未修复的 Minor/Nice-to-Have 项。

输出格式
## 审查摘要
[1–2 句概述]

## 问题列表

### Critical（阻塞性）
1. [FILE:LINE] ISSUE_TITLE
   - 问题描述 / 原因 / 修复建议

### Major（应修复）
2. [FILE:LINE] ISSUE_TITLE
   - 问题描述 / 原因 / 修复建议

### Minor（建议优化）
N. [FILE:LINE] ISSUE_TITLE
   - 问题描述 / 原因 / 修复建议

### Informational（供知悉）
N. [FILE:LINE] SUGGESTION_TITLE
   - 建议内容 / 理据

## 优秀实践
- [FILE:LINE] 实践说明（请保留此项）

## 最终结论
就绪状态：是 | 否 | 需修复 1–N 项（仅限 Critical/Major；Minor 项可接受）
依据说明：[1–2 句理由]

修复后验证
修复完成后，请运行：
npm run lint
npm run typecheck
npm run test

所有检查必须全部通过，方可批准。
关卡要求
请严格按顺序推进；不得以非正式方式重述某项 通过条件 并跳过它。

范围已明确记录 —— 通过条件：你已获得第 1 步命令的输出结果（或用户提供的明确替代路径列表），准确列出了本次审查的范围。
协议与必选技能均已加载 —— 通过条件：在首次作出严重性判定前，review-verification-protocol 及全部六项 remix-v2-*-review 技能均已加载完成。
条件型技能已完成审计 —— 通过条件：对第 2 步中的每一项检测规则，你均已确认是否存在匹配，或明确记录该命令未返回任何结果。
Critical/Major 级别问题具备充分证据 —— 通过条件：每一项此类问题均引用了一个真实存在于代码树中的 FILE:LINE，且该引用符合第 6 步对该问题类型的通过规则。
输出为单一连续结果 —— 通过条件：“问题列表”章节采用连续编号序列，且交付物满足第 7 步关于单次遍历完整性的全部要求。

规则

必须先加载技能，再开展审查——不可倒置。
每项问题须依序编号，并附带 FILE:LINE 及清晰的“问题 / 原因 / 修复”三段式说明。
本审查专为 Remix v2 设计——禁止套用 React Router v7、Remix v1 或 Next.js（如 "use client"、服务端组件）的约定。
修复后请执行“修复后验证”环节；最终结论（Verdict）忽略 Minor 和 Informational 类问题。