Advisor Code Champion

An agent that champions code quality practices across development teams, establishing coding standards, review processes, testing strategies, and quality metrics that maintain codebase health as teams and projects grow.

When to Use This Agent

Choose Code Champion when:

• Establishing coding standards and style guides for teams
• Designing code review processes and checklists
• Building testing strategies (unit, integration, E2E testing pyramids)
• Implementing code quality metrics and monitoring dashboards
• Mentoring teams on clean code practices and refactoring techniques

Consider alternatives when:

• Writing code for specific features (use a development agent)
• Reviewing architecture decisions (use an architecture agent)
• Setting up CI/CD pipelines (use a DevOps agent)

Quick Start

Copy
# .claude/agents/advisor-code-champion.yml
name: Code Champion
model: claude-sonnet-4-20250514
tools:
  - Read
  - Write
  - Bash
  - Glob
  - Grep
prompt: |
  You are a code quality champion. Establish and maintain coding
  standards, review processes, and testing strategies. Focus on
  practical quality improvements that teams actually adopt, not
  theoretical perfection that creates friction.

Example invocation:

Copy
claude --agent advisor-code-champion "Set up a code quality
  framework for our TypeScript project: linting rules, formatting
  standards, code review checklist, testing strategy, and quality
  metrics we should track."

Core Concepts

Quality Framework Layers

Standards     → What good code looks like
Automation    → Tools that enforce standards
Review        → Human evaluation of changes
Testing       → Verification of behavior
Metrics       → Measurement of quality trends

Testing Pyramid

         /‾‾‾‾‾‾\
        / E2E     \       Few, slow, high-value
       /‾‾‾‾‾‾‾‾‾‾\
      / Integration  \    Moderate count
     /‾‾‾‾‾‾‾‾‾‾‾‾‾‾\
    /    Unit Tests     \  Many, fast, focused
   /‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾\
  /   Static Analysis     \ Linting, type checking
 /________________________\

Code Review Checklist

Category	Check	Priority
Correctness	Does the code do what it claims?	Critical
Security	Input validation, auth checks, SQL injection?	Critical
Tests	Are changes tested? Edge cases covered?	High
Naming	Are names clear and consistent?	Medium
Complexity	Can this be simplified?	Medium
Performance	Any obvious performance issues?	Medium
Documentation	Are complex parts explained?	Low

Configuration

Parameter	Description	Default
language	Primary project language	TypeScript
linter	Linting tool	ESLint
formatter	Code formatting tool	Prettier
test_framework	Testing framework	Jest/Vitest
coverage_target	Minimum test coverage	80%
review_required	PR review requirements	1 approval
quality_gate	CI quality checks	Lint + test + coverage

Best Practices

1. Automate everything you can, review what you can't. Linting catches style issues, formatters fix whitespace, type checkers catch type errors. Don't waste human review time on things machines detect. Human reviewers should focus on logic correctness, architectural alignment, naming quality, and edge cases—things that require understanding, not pattern matching.

2. Start with fewer, well-enforced rules rather than many loosely followed ones. A linting configuration with 200 rules that half the team ignores is worse than 20 rules everyone follows. Begin with rules that prevent real bugs (no unused variables, no implicit any, no unreachable code) and add style rules gradually as the team builds compliance habits.

3. Make code review about learning, not gatekeeping. Reviews should explain why a change could be improved, not just demand it. "Consider extracting this into a function because it appears in three places and changes together" teaches the author a principle. "Extract this into a function" without explanation creates compliance without understanding. Code review is the highest-leverage teaching tool on a team.

4. Track quality metrics as trends, not absolute numbers. A codebase with 65% test coverage isn't inherently bad—it depends on whether it was 50% last quarter (improving) or 80% last quarter (declining). Track coverage trends, linting violation trends, and review cycle time over months. Trends reveal whether quality practices are working or deteriorating.

5. Adapt standards to the codebase's context. A startup prototype doesn't need the same quality rigor as a financial transaction system. A data pipeline script doesn't need the same testing strategy as a public API. Define quality tiers based on the code's criticality and adjust standards accordingly: critical paths get strict quality gates, internal tools get pragmatic standards.

Common Issues

Team resists new quality standards as overhead. Introduce standards gradually, start with rules that prevent real bugs (not style preferences), and automate enforcement through CI so compliance is effortless. Get buy-in by showing examples of bugs that standards would have caught. Standards that developers see as helpful get adopted; standards perceived as bureaucratic get circumvented.

Code coverage number is high but tests don't catch bugs. Coverage measures which code lines execute during tests, not whether tests actually verify behavior. A test that calls a function but doesn't assert anything adds coverage without value. Review tests for meaningful assertions, edge case coverage, and behavior verification. A test suite with 60% coverage and strong assertions is better than one with 95% coverage and weak assertions.

Code reviews take too long and become bottlenecks. Set expectations: reviews should happen within 4 hours during business hours. Keep PRs small (under 400 lines) so reviews are quick. Use draft PRs for early feedback before the final review. If reviews consistently take days, the team is either understaffed for reviews, PRs are too large, or review standards are too demanding for the team's current practices.