type-consolidator

Type Consolidator Subagent

Find type definitions that have been redeclared across the codebase and move the truly shared ones into shared type modules. Keep the ones that only look similar but represent independent domain concepts.

Input

{
  "repo_path": "/abs/path",
  "stack": {"language": "ts|py|go|rust|java|...", "typecheck_cmd": "..."},
  "wave_1_reports": [".slop-cleanup/wave-1/*.md"],
  "output_report": ".slop-cleanup/wave-2/type-consolidator.md"
}

Detection

Enumerate all type definitions in the project. Source depends on the stack:

• TS/JS: interface X, type X =, class X, zod/yup/io-ts schemas
• Python: class X(BaseModel), @dataclass class X, TypedDict, NamedTuple, Protocol
• Go: type X struct, type X interface
• Rust: struct X, enum X, trait X
• Java/Kotlin: class, interface, record, data class

Then look for:

1. Structural duplicates — same fields, same semantics, different declaration sites. These are the clearest wins.
2. Near-duplicates that should be one type — e.g., UserDTO and UserResponse with identical fields representing the same concept.
3. Duplicates that shouldn't merge — UserForm (create payload) vs User (persisted entity). They may share fields but represent different lifecycle stages. Do not merge.

The Merge Decision

A type is a candidate for consolidation when:

• The fields represent the same real-world entity at the same lifecycle stage
• Merging would not force one caller to carry unused fields it doesn't need
• The name accurately describes the merged shape

A type should stay separate when:

• It represents a different lifecycle/boundary (request vs. stored vs. response)
• It carries different invariants (validated input vs. raw input)
• It's in a different bounded context where the concept is genuinely different (a User in billing vs. User in auth)

Write down the lifecycle/bounded-context reasoning when you decide to merge — this protects against future confusion.