rmc-test-vs-prod

Classify Rust symbol references into test-only or production categories.

29|5|Updated Nov 24, 2025
One-click install
npx skills add https://github.com/molaco/rust-code-mcp --skill rmc-test-vs-prod
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rmc-test-vs-prod
Source: https://github.com/molaco/rust-code-mcp/tree/main/skills/rmc-test-vs-prod
Command: npx skills add https://github.com/molaco/rust-code-mcp --skill rmc-test-vs-prod

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It helps you determine whether a Rust symbol (or family of related symbols) is only used in tests or is truly part of the production code path, so you can prioritize refactors and reduce high-touch change risk.

Core Features & Use Cases

  • Test vs production fan-in classification: Categorizes each reference as Read / Write / Test / Other and judges whether usage is test-only, production-only, mixed, or over-tested in isolation.
  • Constructor and API audit recipes: Focuses on Type::new-style constructors and trait/public API entry points to find candidates for demotion, #[cfg(test)], or fixture extraction.
  • Encapsulation signal via Read vs Write: When available, uses Read/Write sub-counts to flag diffuse invariants caused by heavy write fan-in.
  • Per-symbol actionable output: Produces a verdict, counts, top consumers, recommended action, and notes about limitations of the heuristic.

Quick Start

Ask your AI to analyze a specific symbol by running who_uses_summary for the target after building the hypergraph for the repository.

Frequently Asked Questions about rmc-test-vs-prod

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check if a Rust symbol is only used in tests versus production code?

To check if a Rust symbol is test-only versus production, you classify reference categories into Test and Other. This categorizes each reference as Read, Write, Test, or Other to judge whether usage is test-only, production-only, mixed, or over-tested.

What is the best way to audit Rust constructors for production refactoring?

Auditing Rust constructors for refactoring involves classifying usage for Type::new-style constructors and public API items. This identifies candidates for demotion, cfg(test) isolation, or fixture extraction based on test-only or production-only verdicts.

Does rust-analyzer work with test coverage analysis for Rust codebase auditing?

rust-analyzer works with test coverage analysis by building the HIR hypergraph and running who_uses_summary. Interpreting the category_breakdown outputs a test-only, production-only, mixed, or over-tested verdict for targeted symbols.

How do I identify diffuse invariants from heavy write fan-in in a Rust codebase?

To identify diffuse invariants from heavy write fan-in, you analyze Read and Write sub-counts for Rust symbols. This encapsulation signal flags symbols with heavy write fan-in, indicating potential invariant management issues.

What are the limitations of using heuristics for Rust refactoring triage?

The limitations of using heuristics for Rust refactoring triage include potential inaccuracies in reference classification. The analysis provides notes about heuristic limitations alongside actionable output like verdicts, counts, top consumers, and recommended actions.