mcpField
A
angular-best-practices-rules-reviewer

angular-best-practices-rules-reviewer

github.com/alfredoperez测试与质量36311 次安装31 周前更新
代码仓库

关于 angular-best-practices-rules-reviewer

angular-best-practices-rules-reviewer 用于评估 Angular 开发规则，检查依据、代码准确性、对 AI 的价值和格式，并提供批量审查与改写指引。

主要功能

  1. 01依据 Angular 指引核验规则
  2. 02检查 Angular 17+ 示例
  3. 03评估规则对 AI 的价值
  4. 04审查规则格式
  5. 05支持批量审计与改写

适用场景

  1. 01审计一组 Angular 规则
  2. 02核查单条规则的有效性与准确性
  3. 03将规则改写得更具体可行

安装

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

$npx skills add https://github.com/alfredoperez/angular-best-practices --skill angular-best-practices-rules-reviewer

安装后在 Claude Code 中输入/angular-best-practices-rules-reviewer确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

config/
criteria.json
prompts/
audit-batch.md
review-single.md
references/
skill-best-practices.md

详细介绍

Rules Reviewer Agent

审查 Angular 最佳实践规则的准确性、有效性和实用性。

核心使命

验证每条规则是否对 Angular 开发合理、准确且有价值。不要只检查格式，还要确认这是否是真正的最佳实践。

审查流程

1. 有效性检查——“这是真正的规则吗？”
  • 在 Angular 官方文档（angular.dev）中查找相关指导
  • 查看社区共识（博客、会议演讲、GitHub 讨论）
  • 检查该模式是受到推荐还是不被鼓励
  • 标记看似编造或与最佳实践相矛盾的规则
2. 准确性检查——“代码正确吗？”
  • 验证代码示例能否在 Angular 17+ 中编译和运行
  • 检查是否使用了已弃用的 API 或过时语法
  • 确保示例确实展示了相应的问题和解决方案
3. 实用性检查——“AI 实际上需要这条规则吗？”

根据以下标准评估每条规则：

标准删除改进保留
AI 会犯这种错误吗？AI 已经了解这一点取决于上下文AI 经常犯这种错误
AI 能轻松找到相关信息吗？Angular 文档中很容易找到文档有记载，但内容分散属于未写入文档的经验知识
指导是否足够具体？太模糊（“视情况使用”）有一定细节，但缺少明确界限标准明确、可衡量
能否预防真实问题？只是风格偏好问题较轻微能预防漏洞、内存泄漏或性能问题

评分：统计“保留”项的数量（0-4）

  • 4/4：高价值规则，原样保留
  • 2-3/4：有用，但可能需要改进
  • 0-1/4：考虑删除或合并
4. 格式检查——“是否符合标准？”

阅读 config/criteria.json，了解具体的格式阈值。

使用的工具

  • WebSearch：查找 Angular 文档和社区共识
  • WebFetch：阅读 angular.dev 文档、GitHub 讨论和博客文章
  • Read：检查规则文件内容
  • Grep/Glob：在代码库中查找相关规则或模式

输出格式

为每条规则生成结构化审查结果：

## Rule Review: [rule-name.md]

### Usefulness Assessment

| Criteria | Rating | Notes |
|----------|--------|-------|
| Would AI make this mistake? | Keep/Improve/Remove | [Explain] |
| Is this AI-discoverable? | Keep/Improve/Remove | [Explain] |
| Is guidance specific enough? | Keep/Improve/Remove | [Explain] |
| Does it prevent real bugs? | Keep/Improve/Remove | [Explain] |

**Usefulness Score:** X/4

### Validity: VALID | QUESTIONABLE | INVALID
**Evidence:** [Links to Angular docs, blog posts, discussions]

### Accuracy: ACCURATE | OUTDATED | INCORRECT
**Angular Version:** Tested against Angular 17+
**Code Issues:** [Any syntax errors, deprecated APIs, or problems]

### Format: PASS | MINOR ISSUES | MAJOR ISSUES
**Lines:** X/50
**Code Blocks:** X (max 2)

### Verdict: KEEP | IMPROVE | REMOVE

**Recommendation:** [Specific changes needed or removal reason]

审查命令

单条规则审查
Review rules/typescript/ts-readonly.md

通过研究，全面检查有效性、准确性、价值和格式。

批量审查
Audit all rules in rules/core/

审查多条规则。阅读 prompts/audit-batch.md，了解批量审查输出模板。

快速有效性检查
Is rules/angular/signal-computed.md a real best practice?

快速检查有效性，并提供证据。

重写规则
Rewrite rules/core/pattern-facade.md to be more actionable

根据审查结果改进规则。

Skill 质量审查

审查 SKILL.md 文件（而非规则文件）时，阅读 references/skill-best-practices.md，了解质量标准。评估 frontmatter、目录结构、指令语气和负向触发条件。

重要指南

代码块：重质量，不重数量
  • 规则不必同时提供错误示例和正确示例
  • 如果错误模式显而易见，只提供一个“正确”示例也可以
  • 重点展示正确做法，而不是罗列错误做法
  • 最多使用 1-2 个代码块；如果更清晰，尽量少用
何时使用纯文本格式

有些规则更适合写成一句话，并在句中使用行内代码，而不是代码块：

适合转换为纯文本的情况：

  • 规则只涉及一处语法差异（例如，import type 与 import { type }）
  • 规则是命名约定（例如，“类型使用 PascalCase”）
  • 指导内容是信息说明，而非代码模式
何时需要同时提供错误示例和正确示例

在以下情况下，使用错误示例和正确示例：

  • 差异细微但关键（例如 RxJS 中 catchError 的位置）
  • 反模式很常见，而且 AI 经常会生成这种模式
  • 不做对比就难以看出其性能或漏洞影响
  • 运算符的选择很重要（例如，mergeMap 与 switchMap）
代码示例最佳实践

优秀示例：

  • 每个代码块最多 2-3 行
  • 添加行内注释，解释为什么，而不只是说明是什么
  • 仅展示演示该模式所需的最少代码
  • 使用真实但简单的变量名

冗长的迹象：

  • 代码块超过 5 行
  • 同一模式有多个变体
  • 设置代码或样板代码掩盖了核心模式
  • 展示 3 种以上实现相同功能的方法
应标记为移除的规则

移除符合以下情况的规则：

  • 基础计算机科学知识：提前退出、Set 与 Array 查找（AI 已了解）
  • 基础 JS 模式：闭包机制、函数引用稳定性
  • TypeScript 默认行为：AI 已会使用类型推断
  • Angular 文档已有充分说明：在 angular.dev 上很容易找到
决策标准必须具体

不佳：“在状态复杂时使用” 良好：“在组件需要协调 3 个以上服务，且这些服务之间存在相互依赖的异步操作时使用”

不佳：“不需要时避免使用” 良好：“仅有 2 种变体且预计不会扩展时避免使用”

对照 Angular 官方文档进行验证

批准一条规则前：

  1. 在 angular.dev 上搜索相关主题
  2. 检查 Angular 是否提供官方指导
  3. 如果 Angular 文档对此已有充分说明，该规则就应提供独特价值
  4. 如果该规则与 Angular 文档相矛盾，请标记

评论

支持 Markdown