agentleFS
NVIDIAKnown publisherNVIDIA/NeMo-Relay/skills/nemo-relay-instrument-calls/SKILL.md

nemo-relay-instrument-calls

Skill238 starsChanged 2 months agoApache-2.0View on GitHub

Use this skill when an application owns tool or LLM/provider call sites and needs to wrap them with NeMo Relay scopes and managed execution APIs for lifecycle events, middleware, or guardrails.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. About 0 are common, 9 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when an app already has tool functions or model/provider calls and needs to run them through NeMo Relay correctly.

    line 11
  2. Distinctive:

    Keep the original callable behavior stable while adding Relay lifecycle capture.

    line 13
  3. Distinctive:

    Put a scope around the natural agent, request, workflow, or graph boundary.

    line 17
  4. Distinctive:

    Use managed execution APIs first:

    line 18
  5. Distinctive:

    Use manual lifecycle APIs only when the host framework cannot be wrapped by the managed execute helpers.

    line 24
  6. Distinctive:

    If execution fails after the start event has been emitted, the runtime still emits an end event without a semantic output payload.

    line 41
  7. Distinctive:

    Keep the original tool callable responsible for business logic.

    line 44
  8. Distinctive:

    If you use them, every start call needs a matching end or error path with the relevant semantic payloads supplied explicitly.

    line 49
  9. Very specific:

    Use nemo-relay-plugin-observability for traces, ATIF, or export setup.

    line 70
  10. Very specific:

    Use nemo-relay-debug-runtime-integration to debug missing events or load failures.

    line 71
  11. Very specific:

    Use nemo-relay-instrument-context-isolation for per-request isolation or worker-pool guidance.

    line 73
  12. Very specific:

    Use nemo-relay-plugin-build for reusable, configuration-activated runtime behavior.

    line 75
  13. Distinctive:

    Use these skills for adjacent workflows:

    line 80
  14. Very specific:

    Start onboarding with nemo-relay-get-started.

    line 82
  15. Very specific:

    Add typed wrappers with nemo-relay-instrument-typed-wrappers.

    line 83

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Instrument Tool And LLM Calls

Use this skill when an app already has tool functions or model/provider calls and needs to run them through NeMo Relay correctly. Keep the original callable behavior stable while adding Relay lifecycle capture.

Default Guidance

  • Put a scope around the natural agent, request, workflow, or graph boundary.
  • Use managed execution APIs first:
    • Rust: tool_call_execute(ToolCallExecuteParams::builder()...), llm_call_execute(LlmCallExecuteParams::builder()...)
    • Python: tools.execute(...), llm.execute(...)
    • Node.js: toolCallExecute(...), llmCallExecute(...)
    • Go: tools.Execute(...), llm.Execute(...) or the top-level wrappers
  • Use manual lifecycle APIs only when the host framework cannot be wrapped by the managed execute helpers.

Embedded Runtime Semantics

  • Managed tool and LLM execution runs conditional-execution guardrails first on the raw input. If rejected, the runtime emits a standalone mark event and does not run request intercepts or the callable.
  • Request intercepts run after conditional guardrails and rewrite the real input that reaches execution intercepts and the callback.
  • Sanitize-request guardrails affect emitted start-event payloads only. They do not rewrite the caller-visible request or arguments.
  • Execution intercepts wrap the callback with the middleware next pattern and may short-circuit by returning their own result.
  • Sanitize-response guardrails affect emitted end-event payloads only. The value returned to application code remains the raw callback or execution-intercept result.
  • If execution fails after the start event has been emitted, the runtime still emits an end event without a semantic output payload.
  • Tool calls are named operations with JSON-compatible arguments and results. Keep the original tool callable responsible for business logic; let NeMo Relay own lifecycle events, middleware, and metadata.
  • LLM calls use an LLMRequest made of metadata plus content. Pass model names and stable call identifiers when they matter for trace export or diagnostics.
  • Manual lifecycle APIs are for framework adapters that already own execution. If you use them, every start call needs a matching end or error path with the relevant semantic payloads supplied explicitly.
  • Partial middleware APIs such as request_intercepts(...) and conditional_execution(...) are for advanced adapters that need one middleware family before calling a provider manually.
  • Streaming LLM wrappers collect chunks and finalize a response at stream end; dropping the stream early can prevent finalizers and subscribers from seeing a complete output.

Checklist

  • Scope boundary chosen before the first tool or LLM call
  • Existing tool function wrapped without losing its original arguments/result
  • Existing LLM/provider call wrapped at the right abstraction layer
  • Optional metadata, attributes, or model name attached where useful
  • Context propagation handled if the call hops threads or async tasks

Use Another Skill When

Choose another skill when the task requires a neighboring workflow:

  • Use nemo-relay-plugin-observability for traces, ATIF, or export setup.
  • Use nemo-relay-debug-runtime-integration to debug missing events or load failures.
  • Use nemo-relay-instrument-context-isolation for per-request isolation or worker-pool guidance.
  • Use nemo-relay-plugin-build for reusable, configuration-activated runtime behavior.

Related Skills

Use these skills for adjacent workflows:

  • Start onboarding with nemo-relay-get-started.
  • Add typed wrappers with nemo-relay-instrument-typed-wrappers.
  • Configure export with nemo-relay-plugin-observability.
  • Package reusable behavior with nemo-relay-plugin-build.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.