Audit Simplification

Find removable mechanisms while preserving required observable behavior. Favor fewer concepts, allocations, synchronization paths, and lifecycle responsibilities.

Scope and Authorization

• Analyze the project or directory the user names. If they name no target, infer the smallest reasonable scope from the request and repository state.
• Treat an audit as read-only. Edit only when the user explicitly asks for implementation.
• Read the root AGENTS.md, nearer agent instructions, and the target project's DEVELOPMENT.md before analyzing. DEVELOPMENT.md lists the test types the project runs, which shows which observable behavior is already covered. Read additional required guidelines for the files or APIs in scope.
• Preserve unrelated working-tree changes.
• Preserve published API unless the user authorizes a breaking change. 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 unpublished, search every project under projects/, including starters, site docs, *.examples.ts files, and projects/internals/patterns.

Use audit-consolidation instead when the main question is where duplicate or shared responsibility should live. Use this skill when the earlier question is whether a mechanism or responsibility needs to exist at all. When both apply, run this audit first; removing a mechanism often removes the duplication question with it.

Establish the Observable Contract

Before proposing removal, identify the behavior that must survive: