Ln Review

Explore the codebase. Surface structural improvement opportunities. Be opinionated.

Use the repo's pre-release posture: reward conceptual clarity over compatibility scaffolding, and treat unnecessary preservation as review debt. Look for stale code, obsolete fixtures, legacy terms, and compatibility paths that should be deleted rather than protected.

Input

What to review: $ARGUMENTS

If "recent" or unspecified, focus on recently modified files.

What to look for

Read memory/SPEC.md first when it exists. Use its lexicon for domain terms, and treat the live architecture register as the current decision record. Read memory/PLAN.md for active frontier context when the reviewed area touches active or near-horizon work. If ADRs or design docs exist in the touched area, respect them as supporting context, but do not introduce ADRs or sidecar decision logs by default; durable updates reconcile through memory/SPEC.md / memory/PLAN.md.

Apply Ousterhout's depth test: modules should have small interfaces hiding significant complexity. Modules that move together should live together — clusters of small files always used in concert are a single deep module waiting to be extracted.

Use the deletion test for suspected shallow modules: if deleting the module makes complexity vanish, it was pass-through structure; if the same complexity reappears across multiple callers, the module was earning its keep. Prefer depth as leverage/locality, not line-count ratio.