Nerd

Use when explicitly invoked or when a concrete latency constraint requires minimizing wall-clock agent time without reducing accuracy.

Use when the user explicitly asks for Nerd Loop or wants a cost-proportional, behavior-aware task-completion controller that selects the cheapest adequate loop profile and iterates toward an explicit Definition of Done through focused work, automatic verification, and bounded stopping rules.

Use when turning a confirmed outcome into actionable, ordered implementation steps with file-level changes and proof, then stopping before execution.

Use when defining requirements, observable behavior, boundaries, or system design and stopping before implementation planning or execution.

Use when a request needs fast alignment on outcome, endpoint, or scope before handing work to exactly one endpoint route, including ambiguous or materially multi-goal requests.

Use only when explicitly invoked for a concrete output or authorized file or code change where latency is worth reduced exploration, accuracy, completeness, and proof breadth.

Use when the installed Nerd hook activates behavioral memory, the user invokes $nerd-memory or /nerd-memory, or Nerd Smart selects longitudinal behavioral advice.

Use when examining a confirmed code, pull request, module, application, endpoint, dependency, or configuration scope for vulnerabilities, unsafe behavior, or exploitability.

Use when reviewing existing code, implementations, pull requests, or named scopes with stack-aware checks and severity-ranked findings, without edits.

Use when explicitly invoked, when reducing agent-workflow cost, or when a concrete deliverable requires no narration, final only, code only, findings only, or minimal output.

Use when implementing an approved written plan or confirmed coding outcome in an existing repository, including requests to build, add, change, or write code.

Use when discovering codebase facts, context, patterns, constraints, or unknowns through focused, incremental, read-only investigation without diagnosing a failure or modifying state.

Use when observing and rechecking an ongoing process or state until a requested condition, deadline, or meaningful change occurs without mutation.

Use when code, integrations, automation, infrastructure, or runtime behavior is broken, unexpected, inconsistent, or probably misimplemented and the user wants diagnosis, root-cause analysis, or repair.

Use when establishing why behavior is broken, unexpected, or inconsistent and reporting a confirmed, probable, or unknown cause without performing repair.

Use when creating or updating a requested static documentation artifact from established information without changing product behavior.

Use when answering, explaining, comparing, or guiding conversationally, or when generating and choosing among possible directions, before creating artifacts or mutating state.