mcpField
F
frontend-review-weekly

frontend-review-weekly

github.com/mizchi测试与质量41646 次安装1 周前更新
代码仓库

关于 frontend-review-weekly

面向定期开展 AI 代码审查的团队的前端周度审查编排技能。它按流程协调审查技能、跟踪 KPI 变化与重复问题，并汇总报告，不修改源代码。

主要功能

  1. 01按序运行审查技能
  2. 02并行开展多视角审查
  3. 03比较并递进更新 KPI
  4. 04检测重复出现的问题
  5. 05提交 GitHub 问题并提议规则
  6. 06监测生态趋势

适用场景

  1. 01执行每周前端质量审查
  2. 02对照 KPI 基线跟踪回归
  3. 03将重复问题转为规则提案

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/mizchi/skills --skill frontend-review-weekly

安装后在 Claude Code 中输入/frontend-review-weekly确认已加载。

附带文件README.md

详细介绍

前端审查 — 每周协调器

你正在执行每周 AI 审查。你的任务不是做出新的判断，而是：

  1. 按正确顺序重新运行每个 frontend-review-* 技能。
  2. 并行调度 5 个视角子技能。
  3. 将 KPI 与上周的基线进行比较。
  4. 为重复出现的问题创建 GitHub issue。
  5. 为连续 3 周或更久出现的模式提出静态规则晋升建议。

流程

阶段 1：原始数据收集

按以下顺序运行：

  1. frontend-review-triage
  2. frontend-review-ci
  3. frontend-review-hygiene
  4. frontend-review-deps
  5. frontend-review-testing
  6. frontend-review-security

每项技能都会写入 <client-repo>/.frontend-review/report/latest/。

阶段 1.5：架构审查（发现疑似问题时运行）

按需运行以下技能；或者在新项目合作的第一个每周周期中始终运行：

  1. frontend-review-state
  2. frontend-review-performance

这些技能会写入 <client-repo>/.frontend-review/report/latest/md/。

阶段 2：视角审查（并行）

使用 dispatching-parallel-agents 技能并发调度 5 个视角技能。每项技能都会读取原始 JSON，并生成特定视角的 Markdown 报告：

  • frontend-expert
  • react-expert
  • performance-expert
  • security-expert
  • frontend-ops-expert
阶段 3：KPI 差异比较与棘轮

将 <client-repo>/.frontend-review/report/latest/raw/*.json 与 <client-repo>/.frontend-review/kpi/baseline.json 进行比较。标记：

  • 任何退步（不良）——必须在下次每周审查前修复
  • 任何改进（良好）——这些会更新基线（棘轮收紧）
阶段 4：检测重复问题

将本周的问题与之前 2 个 report/weekly-*.md 文件进行比较。连续三周都出现的任何问题，都是晋升为静态规则的候选项：提出 eslint/biome 自定义规则、codemod，或能自动执行检查的 CI 门禁。将这些提案写入 <client-repo>/eslint-rules/proposals/<rule-name>.md（如有需要则创建目录），但不要实施——这是单独的工程任务。

阶段 5：报告

将报告写入 <client-repo>/.frontend-review/report/weekly-$(date +%Y-w%V).md，包含：

  • KPI 差异表（按类别）
  • 退步项（必须修复）
  • 改进项（棘轮更新）
  • 各视角摘要（每个视角 1 段）
  • 静态规则晋升（指向提案）
  • 已创建的 issue（gh issue create 输出）

趋势监控

除 KPI 差异比较外，每个每周周期还要检查以下外部信号，及早发现生态变化。

监控来源
来源频率关注内容
jser.info每周（周日发布）影响项目依赖项的重大版本发布、RFC、破坏性变更、安全公告
State of JS（每年，约 12 月）每年使用率/满意度趋势；连续两年满意度下降是切换触发信号
State of CSS（每年）每年CSS 采用趋势、对 Tailwind / CSS-in-JS 的看法
JavaScript Rising Stars（每年，约 1 月）每年GitHub 星标增长；新兴工具的早期信号
官方发布博客发布时跟踪项目的直接依赖项（框架、打包器、测试运行器、代码检查工具、TypeScript）的重大版本发布

每周运行时，使用 WebFetch 访问 https://jser.info/，并检查是否提及 package.json 中列出的软件包。在 Ecosystem Signals 标题下标记所有相关内容。

切换触发条件

当以下条件中任意两项满足时，建议调查替换工具：

  1. State of JS / State of CSS 的满意度评分连续 2 年下降。
  2. 过去 6 个月没有重要版本发布，且 GitHub issue 的累积趋势呈上升态势。
  3. 有报告指出维护者离职或发布弃用通知。
  4. 存在明显更优的替代方案：功能对等 + 性能或 DX 显著提升 + 迁移路径切实可行。

AI / 人类职责划分

AI 可执行（无需人工预先批准）：

  • 可自动修复的 lint / 类型检查错误
  • 扩展现有模式的测试覆盖率
  • 依赖版本升级（lint + 测试通过后）

必须由人工决定：

  • 测试失败分类：是规范有误、实现有误，还是测试有误？
  • 新增或移除库
  • 架构边界变更（新的状态层、新的路由模式、新的异步边界）
  • 任何会改变应用行为、而不仅仅是实现方式的变更

在周报中标记任何似乎越过人工决策范围的 AI 生成 PR。

边界

  • 即使时间紧迫，也不要跳过任何 Phase 1 领域技能。
  • 不要修改客户端仓库中的源代码。
  • 出现回归时，不要悄悄更新 kpi/baseline.json。仅在有改进时更新。

参考

  • 检查清单：11-ai-review.md、13-kpi-tracking.md
  • 阶段：week-4-ai-review.md、ongoing.md
  • 相关技能：所有 frontend-review-*，以及 frontend-expert、react-expert、performance-expert、security-expert、frontend-ops-expert
  • 外部技能：superpowers:dispatching-parallel-agents

评论

支持 Markdown