gru: Command for Claude Code

Run a Code Quality Improvement Plan (CQIP) — a structured codebase audit that identifies test gaps, dead code, duplication, testability issues, and code complexity, then files actionable GitHub issues for all findings.

No source code is modified during this process.

Instructions:

Phase 0: Detect Language & Check for Existing CQIP Issues

1. Detect the project language by checking for Cargo.toml (Rust), package.json (JS/TS), pyproject.toml/setup.py (Python), build.gradle (Java/Kotlin), etc. Adapt the audit instructions in Phase 1 to use language-appropriate constructs (e.g., #[test] for Rust, describe/it for JS, def test_ for Python).

2. Check for existing open CQIP issues:

   gh issue list --label cqip --state open --json number,title
   

   If open CQIP issues exist, note them. In Phase 4, skip filing issues that duplicate existing open ones.

Phase 1: Audit (parallel agents)

Spawn two auditor agents in parallel using the Agent tool. Each agent should write its findings to a temp file, then send a summary message back.

Agent 1: Test Auditor

Read every test module and test function across the codebase. For each:

• Classify each test as high/medium/low value
• Identify tests to delete: trivial tests, tests that test mocks not behavior, tests with no assertions
• Identify tests testing the wrong thing: tests that re-implement production logic locally, tests that inline production format strings
• Identify dead code kept alive by tests: production code with zero non-test callers
• Identify critical missing coverage: untested code paths most likely to break in production (error handling, state transitions, async loops, timeout machinery)
• Identify tests to improve: tests with no assertions, tests using real CLI tools instead of mocks

Report findings with specific file paths and line numbers, grouped by module.

Agent 2: Architecture Auditor

Read all source files and audit for:

• Testability: Where interfaces/traits should be added for dependency injection, functions mixing business logic with I/O, global state blocking parallel tests
• Long functions: Functions >80 lines with multiple responsibilities — list file:line, length, suggested splits
• Duplication: Repeated patterns across modules that should be extracted into helpers
• Dead code: Unused items, unused public API surface, commented-out code
• API surface: Overly broad visibility (e.g., pub items that should be pub(crate) in a binary crate)