Scout

Scout Rule

"Leave the code better than you found it."

Identify the top 3 highest-impact, lowest-risk improvement opportunities in files touched by a diff. Reads entire file content, not just changed lines. Focuses on pre-existing code quality — things the next developer will thank you for fixing.

Prerequisite check

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

If git is not installed or the working directory is not a git repository, stop and report the issue. Do not proceed.

Detect changed files

Determine which files to analyze based on input.

Default — working tree vs base branch

# 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

If all sources return empty, report that there are no changed files to analyze.

Specific branch

If the user specifies a target branch to analyze, detect the base branch the same way as the default mode, then 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}

Specific files

If given an explicit list of file paths rather than a branch name, use those directly without running git diff.

Scope

Read the full content of each changed file, not just diff hunks. Look for improvements in the entire file.

Do not:

• Find bugs in PR changes (that's a code reviewer's job)
• Suggest architectural redesigns
• Flag style preferences not established in the codebase
• Propose changes requiring new dependencies

Categories

dead-code

Unused functions, variables, imports, or types. Commented-out code blocks. Unreachable branches. Stale TODO/FIXME comments referencing completed work.

naming

Misleading names that don't match current behavior (code evolved, name didn't). Inconsistent patterns within the same file (e.g., getUserID vs fetchUserId). Single-letter variables in non-trivial scope (beyond simple loop counters). Abbreviations that hurt readability when the full word is short.

magic-values

Hardcoded numbers or strings that should be named constants. Repeated literal values that represent the same concept. Timeout/limit values embedded in logic without explanation.

deprecated-patterns

Old APIs when newer alternatives exist in the same codebase. Patterns that the project has moved away from (check other recent files for the modern approach). Legacy error handling when the project now uses a different convention.

simplification

Overly complex logic that can be expressed more directly. Unnecessary indirection (wrapper functions that add no value). Redundant nil/error checks where the invariant is already guaranteed. Nested conditionals that can be flattened with early returns.

Scoring

Score each opportunity on two dimensions (1-5 each):

• Impact: How much does fixing this help the next developer?
  • 5 = Prevents real confusion or bugs
  • 3 = Noticeable improvement to readability
  • 1 = Minor polish
• Low-Risk: How safe is this change?
  • 5 = Pure cleanup, zero behavior change possible
  • 3 = Safe but touches logic paths
  • 1 = Could change behavior if not careful

Composite score = Impact × Low-Risk. Return only the top 3.

Output format

Present a summary table followed by per-suggestion details:

For each suggestion, include:

• Category and Effort (trivial / small / medium)
• Why this matters — one sentence explaining value to the next developer
• Suggested change — concrete code snippet or diff showing the improvement

If no improvement opportunities are found, report:

No significant improvement opportunities found. The touched files are in good shape.

Anti-patterns — do not suggest

• Refactoring entire files or modules
• Changing public API signatures
• Style preferences not established in the codebase
• Anything requiring new dependencies or architectural decisions
• Changes that would touch more than ~20 lines
• Issues a linter would catch