NeMo Relay Plugin Builder
Guides reusable NeMo Relay runtime behavior into configurable plugins.
The skill specifies least-privilege-oriented JSON-compatible configuration, avoidance of credentials and raw production payloads, side-effect-free validation, PluginContext ownership, and rollback on partial failure. It does not define user confirmation, concrete permission boundaries, detailed data flows, or operational rollback procedures, so 5 points are deducted.
The validation, diagnostics, registration, and partial-failure workflow is internally coherent, and a benchmark report is included. However, there are no committed tests for this skill's key paths, dependency versions, reproducible implementation details, or substantial abnormal-input and error-message examples, so 11 points are deducted.
Audience, use cases, non-use cases, runtime surfaces, and language bindings are relatively clear, supporting accurate triggering. Chinese-language support, environment compatibility, and deeper non-fit boundaries are not documented, so 4 points are deducted.
The main skill document is well layered and covers configuration, bindings, failure modes, and a checklist. The skill card supplies Apache 2.0, ownership, version, and evaluation metadata, but recommended Instructions and Examples sections are missing; the author format is flagged, maintenance responsibility, changelog, and update path are incomplete, and the supplied license metadata is NOASSERTION, so 6 points are deducted.
The material directly addresses configuration shape, deterministic validation, PluginContext registration, disabled-component validation, and rollback, which is enough to guide the core design statically. It lacks directly usable generated code, verified representative outputs, and quantified comparison with alternatives; the static cap therefore limits the score to 7.
A pinned revision, evaluation tasks, metrics, and results provide limited auditability. The evaluation material is not independently reproducible evidence for the skill's key paths, and committed tests plus corroborating sources are absent, so 6 points are deducted.
- The benchmark report is static claimed evidence and does not replace independent execution of key plugin paths; add real tests, dependency versions, and rollback-failure tests.
- The documentation lacks complete per-binding code examples, compatibility ranges, Chinese-language guidance, and operational rollback procedures.
- Before publication, reconcile the NOASSERTION license metadata with the Apache-2.0 declaration and identify maintainers and the update channel.
What does this skill do, and when should you use it?
This skill guides developers in packaging reusable, process-level NeMo Relay behavior behind shared configuration. It emphasizes stable plugin kinds, JSON-compatible configuration, deterministic side-effect-free validation, and rollback-safe registration through PluginContext. It covers runtime surfaces such as subscribers, guardrails, request intercepts, and execution intercepts. It is intended for behavior reused across applications, teams, or startup paths, not one-off request logic or configuration that depends on live runtime objects.
It guides the agent to decide whether a plugin is needed, select an initial runtime surface, design a snake_case configuration shape, and define stable diagnostics. It requires validation before initialization, stopping registration when errors are found, registering behavior through PluginContext, and testing activation, disabled components, validation failures, and rollback after partial registration failure. For dynamic plugins requiring structured CLI editing, it also directs authors to declare the config_schema capability and reference a local Draft 7 or Draft 2020-12 JSON Schema file. The skill itself does not provide a concrete plugin implementation or execute these operations automatically.
- A NeMo Relay developer needs to package subscribers or guardrails for reuse across multiple applications.
- A platform team needs to validate operator-supplied shared plugin configuration before changing runtime behavior.
- An engineering team needs configuration-based enablement, disablement, or staged rollout for request or execution intercepts.
- A plugin author needs to ensure failed registration does not leave partially activated runtime behavior.
What are this skill's strengths and limitations?
- Covers plugin boundaries, configuration design, validation, registration, testing, rollback, and documentation.
- Clearly separates side-effect-free validation from runtime registration.
- Addresses JSON configuration compatibility across Rust, Python, Node.js, files, tests, and deployment systems.
- Includes concrete guidance for config_schema, disabled-component validation, and sensitive-data handling.
- It is a design and implementation guide, not a runnable plugin, script, or test suite.
- It does not specify a NeMo Relay version, build tool, runtime command, or platform matrix.
- Implementers must define the plugin kind, fields, diagnostic format, and runtime behavior themselves.
- The plugin approach is unsuitable for one-off request or tenant behavior and configurations containing clients, credentials, or framework objects.
How do you install this skill?
Install the specific skill with the skills CLI described in the repository README:
npx skills add nvidia/skills --skill nemo-relay-plugin-build --yes
You may target Codex explicitly:
npx skills add nvidia/skills --skill nemo-relay-plugin-build --agent codex --yes
The README does not document additional manual installation steps for this individual skill.
How do you use this skill?
After installation, invoke the skill when building configurable NeMo Relay plugins. For example: “Design and validate a NeMo Relay plugin for reusable request interception, register it through PluginContext, and ensure failed activation rolls back cleanly.” The specific plugin code, build commands, and runtime environment setup are not provided.
How does this skill compare with similar options?
For one-off or tenant-local behavior, the skill points to scope-local middleware. For direct tool or LLM call instrumentation, it points to nemo-relay-instrument-calls. For choosing an exporter path without packaging a plugin, it points to nemo-relay-plugin-observability.