mcpField
S
scout

scout

github.com/rshade测试与质量388 次安装2 周前更新
代码仓库

关于 scout

Scout 是面向代码维护者的改进审查技能，根据变更文件识别影响较大且风险较低的既有代码质量问题。它阅读全文并按影响与风险评分，只给出排名前三的建议。

主要功能

  1. 01检测变更文件或接受指定路径
  2. 02阅读全文而非只看差异
  3. 03聚焦既有代码质量改进
  4. 04按影响和风险评分
  5. 05仅输出前三项并附具体修改

适用场景

  1. 01在提交前清理变更文件中的遗留问题
  2. 02为后续维护挑选低风险改进
  3. 03按指定分支或文件检查代码

安装

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

$npx skills add https://github.com/rshade/agent-skills --skill scout

安装后在 Claude Code 中输入/scout确认已加载。

附带文件evals/evals.jsonevals/fixture.py

详细介绍

Scout Rule

“让代码变得比你发现它时更好。”

找出 diff 涉及的文件中影响最大、风险最低的 3 个改进机会。读取整个文件内容，而不仅是改动的行。重点关注已有代码质量问题——修复后会让下一位开发者感激不尽的问题。

前置条件检查

git --version 2>/dev/null && git rev-parse --is-inside-work-tree 2>/dev/null

如果未安装 git，或当前工作目录不是 git 仓库，请停止并报告问题。不要继续操作。

检测变更文件

根据输入确定要分析的文件。

默认 — 工作树与基础分支对比
# Detect base branch
BASE_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null \
  | sed 's@^refs/remotes/origin/@@' || echo "main")

# Combine committed + uncommitted + staged changes vs base
{ git diff --name-only ${BASE_BRANCH}...HEAD 2>/dev/null; \
  git diff --name-only; \
  git diff --name-only --cached; } | sort -u

如果所有来源都没有返回结果，请报告没有可供分析的变更文件。

指定分支

如果用户指定了要分析的目标分支，请使用与默认模式相同的方法检测基础分支，然后进行 diff：

BASE_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null \
  | sed 's@^refs/remotes/origin/@@' || echo "main")
git diff --name-only ${BASE_BRANCH}...${BRANCH}
指定文件

如果用户提供的是明确的文件路径列表，而非分支名称，请直接使用这些路径，不要运行 git diff。

范围

读取每个变更文件的完整内容，而不仅是 diff 片段。检查整个文件中的改进机会。

不要：

  • 查找 PR 改动中的 bug（这是代码审查者的工作）
  • 建议架构重设计
  • 指出代码库中没有确立依据的风格偏好
  • 提议需要新增依赖的改动

类别

dead-code

未使用的函数、变量、导入项或类型。已注释掉的代码块。不可达分支。引用已完成工作的过时 TODO/FIXME 注释。

naming

与当前行为不符的误导性名称（代码已演进，名称却未更新）。同一文件中的命名模式不一致（例如，getUserID 与 fetchUserId）。非简单循环计数器的非平凡作用域中使用单字母变量。使用会降低可读性的缩写，而完整单词很短。

magic-values

应该命名为常量的硬编码数字或字符串。表示同一概念的重复字面值。未加说明、嵌入逻辑中的超时或限制值。

deprecated-patterns

当代码库中已有较新替代方案时仍使用旧 API。项目已弃用的模式（查看其他近期文件，确认现代做法）。当项目现已采用其他约定时仍使用旧式错误处理。

simplification

可以用更直接方式表达的过度复杂逻辑。没有带来价值的不必要间接层（包装函数）。不变量已能保证、却仍重复进行的 nil/错误检查。可以通过提前返回扁平化的嵌套条件语句。

评分

从两个维度为每个改进机会评分（各 1–5 分）：

  • 影响：修复后能为下一位开发者带来多大帮助？
    • 5 = 可避免实际困惑或 bug
    • 3 = 可明显提升可读性
    • 1 = 轻微润色
  • 低风险：这项改动有多安全？
    • 5 = 纯清理，不可能改变行为
    • 3 = 安全，但会触及逻辑路径
    • 1 = 不慎操作可能改变行为

综合得分 = 影响 × 低风险。只返回排名前 3 的机会。

输出格式

先给出摘要表，再逐项详细说明：

#文件:行号类别描述工作量得分
1位置类别描述工作量I×R=S
2位置类别描述工作量I×R=S
3位置类别描述工作量I×R=S

每项建议都应包含：

  • 类别和工作量（琐碎 / 小 / 中）
  • 为何重要——用一句话说明其对下一位开发者的价值
  • 建议改动——提供具体代码片段或 diff，展示如何改进

如果未发现改进机会，请报告：

未发现显著的改进机会。涉及的文件状况良好。

反模式 — 不要建议

  • 重构整个文件或模块
  • 更改公共 API 签名
  • 代码库中尚未确立的风格偏好
  • 任何需要新增依赖项或做出架构决策的内容
  • 会改动超过约 20 行的更改
  • Linter 能发现的问题

评论

支持 Markdown