Audit Consolidation

Find high-confidence changes that reduce the number of places a maintainer must understand or update for one concept. Favor cohesive ownership and simpler invariants over mechanically maximizing reuse.

Use audit-simplification instead when the primary question is whether state, indirection, lifecycle plumbing, synchronization, or another mechanism needs to exist at all. When both questions apply, run the simplification audit first; removing a mechanism often removes the duplication question with it.

Scope and Authorization

• Analyze the project or directory the user names. If they name no target, infer the smallest reasonable scope from the current request and repository state; ask only when materially different scopes are equally plausible.
• Treat the audit as read-only. Do not edit code merely because the audit finds an opportunity. Make a refactor only when the user explicitly asks for changes.
• Read the root AGENTS.md and any nearer agent instructions. Before analyzing a project, inspect its DEVELOPMENT.md, package.json, architecture notes, public entrypoints, and directory structure when present.
• Treat each project's package.json exports as its published boundary. Packages also export their /internal entrypoints, and sibling packages depend on them; for example, most other projects import @nvidia-elements/core/internal. Before calling anything unused or safe to move, search every project under projects/, including starters, site docs, *.examples.ts files, and projects/internals/patterns.
• Preserve unrelated working-tree changes. Generated output, third-party code, dependency trees, build artifacts, snapshots, and coverage output are out of scope unless the user explicitly includes them.

Build an Evidence-Based Model

Start with a structural inventory, then follow behavior rather than relying on filenames or textual similarity alone.