rigor: Skill for Claude Code

Rigor Type-Coverage Uplift

A contributor workflow for systematically discovering, prioritising, and implementing precision improvements across Rigor's method-dispatch pipeline. The flow has three phases:

1. Audit — enumerate each type's own methods, cross-reference against the existing implementation, and produce a machine-readable coverage doc.
2. Decision — classify every gap by implementation tier; this document is the parallelisation artifact that lets separate agents work on independent tiers.
3. Implementation — one tier at a time, apply the per-tier patterns and commit each slice.

Background

Rigor's method-dispatch pipeline resolves receiver.method(args) through ordered tiers. For a given call site, the first tier that returns a non-nil type wins. The order is defined by dispatch_precise_tiers in lib/rigor/inference/method_dispatcher.rb; read it before relying on this summary:

DataFolding / StructFolding — Data / Struct value objects
meta-introspection          — `Singleton[*].new` and other class-object lifts
ConstantFolding             — scalar constant receivers (String, Integer, Float, bool, nil, Regexp, Symbol)
LiteralStringFolding        — mutable literal-string concatenation
ShapeDispatch               — structural types (Tuple, HashShape, Difference, Size-carrying Nominals)
STDLIB_SINGLETON_FOLDERS    — one folder per stdlib singleton receiver (File, Shellwords, Math, …)
Kernel intrinsics           — Kernel / Object methods (puts, pp, raise, …)
MethodFolding, ReduceFolding, ArrayToHFolding, BlockFolding
RbsDispatch                 — RBS envelope (fallback, always non-nil)

A "coverage gap" is any method where the RBS fallback gives a wide type (String, Integer, Array[T], …) when a precise Constant[T] or Tuple or Refined type could be returned because all the relevant arguments are statically known.

The underlying design documents:

• docs/adr/3-type-representation.md
• docs/type-specification/imported-built-in-types.md
• docs/adr/5-robustness-principle.md