Generated banner for Nemo Fabric Build Adapter
Generated logo for Nemo Fabric Build Adapter

Nemo Fabric Build Adapter

NVIDIAOfficialPublished by NVIDIA

  • Skill
  • Tool integration
  • Software development
  • Apache-2.0
  • Medium risk

From the author

Build, migrate, review, and maintain third-party NVIDIA NeMo Fabric adapters against the public adapter contract. Use when creating adapter or target descriptors, mapping AgentConfig into an agent harness or custom-agent runtime, implementing start/invoke/stop, declaring schemas and capabilities, packaging discovery metadata, or assessing adapter conformance. Do not use for consumer applications that only call the NVIDIA NeMo Fabric SDK.
— the description by NVIDIA

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured procedure for developing third-party adapters that interface with NVIDIA NeMo Fabric. It emphasizes maintaining a thin adapter layer that focuses on target translation and lifecycle management while delegating planning and consumer-facing logic to the NeMo Fabric framework. The guide covers the entire development lifecycle, from reading the adapter contract and defining descriptors to packaging metadata, mapping configurations, and implementing lifecycle operations like start, invoke, and stop.

What it does

  • Defines the adapter boundary and stable adapter identifiers.
  • Provides instructions for creating and validating adapter and target descriptors.
  • Outlines the mapping of AgentConfig into target-native constructs.
  • Details the implementation of lifecycle methods for runtime management.
  • Explains how to handle session continuation and usage reporting.
  • Offers a checklist for validating adapter conformance before deployment.

When to use it

  • When creating a new third-party adapter for the NVIDIA NeMo Fabric ecosystem.
  • When migrating or updating an existing adapter to comply with the public contract.
  • When implementing custom-agent runtimes or target translation logic.
  • When assessing the conformance of an adapter against the NeMo Fabric contract.

Advantages

  • Ensures architectural consistency by keeping adapters thin and focused.
  • Provides clear guidance on schema usage and descriptor creation.
  • Standardizes lifecycle management and error handling across adapters.
  • Facilitates reliable session state management and telemetry integration.

Usage examples

“How do I define a new adapter descriptor for a custom NeMo Fabric integration?”
The agent will guide you through creating a *.fabric-adapter.json file, setting the contract version, declaring normalized config fields, and publishing schemas for settings and models.
“What is the correct way to implement the lifecycle methods for a Python-based adapter?”
The agent will provide a template using the common host lifecycle, showing how to implement start, invoke, and stop methods while ensuring proper state isolation.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/nvidia/nemo-fabric-build-adapter/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip nemo-fabric-build-adapter.zip -d .agents/skills

Documentation by NVIDIA

Build an NVIDIA NeMo Fabric Adapter

Build against the published southbound contract. Keep the adapter thin: let NeMo Fabric own planning and consumer-facing behavior, and let the adapter own only target translation and lifecycle state.

Read the Contract

Read the current adapter contract before changing code. Start with the overview, choose an integration shape, then follow the numbered descriptor, configuration, execution, results, registration, and verification stages. Read the custom-agent page when the target loads application-defined agents or workflows. Read the optional native OpenAI streaming page only when the adapter claims that capability.

Use the committed adapter-contract JSON Schemas or the schemas installed with the matching NeMo Fabric release for exact wire shapes. Do not reconstruct a schema from examples or copy field lists into adapter code.

Establish the Boundary

Establish the adapter boundary before defining its descriptor:

  1. Identify the adapter implementation and its stable adapter_id.

  2. Choose a harness adapter, a shared framework adapter with registered targets, or a dedicated custom-agent adapter.

  3. Reuse one shared adapter across custom agents when the framework provides stable loading and invocation semantics. Use a dedicated adapter when the agent itself is the only unambiguous execution boundary.

  4. List the normalized fields the target can actually enforce.

  5. Separate adapter-wide harness.settings, per-target workflow.settings, and typed extensions.

  6. Keep installation, environment preparation, Relay orchestration, caller scheduling, and consumer result enrichment outside the adapter.

If the requested behavior cannot be expressed by the current contract, surface the gap. Do not silently consume an unsupported northbound field or hide it in an unrelated extension.

Define the Descriptor First

Create one self-contained *.fabric-adapter.json before implementing target translation:

  • Set the current contract_version, a globally stable adapter_id, adapter_kind, and runner binding.

  • Declare only normalized config.accepts fields the implementation enforces.

  • When accepting instructions.system, declare the exact supported config.system_instruction_modes. New descriptors must not rely on the legacy omitted-value behavior, which means replace only.

  • Declare mcp.auth.oauth2 or mcp.auth.service_account only when the adapter implements the corresponding MCP authentication mode.

  • Publish closed settings_schema, model_schema, tool_definition_schema, and extension_schemas where applicable. Use model_schema only for static model/provider compatibility and model settings; keep credential validity and provider availability in startup validation.

  • New adapters that consume models.<role>.top_p or .max_tokens should declare the corresponding normalized config.accepts field. Existing descriptors that declare either name through extension_schemas.model remain compatible and receive it in AgentModelConfig.extensions.

  • Declare runtime requirements and telemetry outputs without secret values.

  • Leave optional capability flags false unless the installed NeMo Fabric runtime exposes and tests that adapter operation. Set capabilities.streaming only when the adapter implements native OpenAI Chat Completions streaming through invoke_openai_stream. Relay-backed ATOF streaming is independent and does not require this capability.

If the adapter loads registered targets, list their types in target_types. Create one *.fabric-target.json per target. The target record owns its adapter_id, type-specific entry point, and workflow settings schema. It uses the same contract_version as the Adapter Descriptor.

Validate descriptor schemas without importing adapter code. Keep all schema references local to the descriptor document; do not rely on HTTP or file references.

Package Discovery Metadata

Install the descriptor in the standard shared-data location. For setuptools:

[tool.setuptools.data-files]
"share/nemo-fabric/adapters/acme" = ["acme.fabric-adapter.json"]
"share/nemo-fabric/targets/acme" = ["email.fabric-target.json"]

Depend on nemo-fabric-adapter-contract for typed standard-library dataclasses. Install its optional pydantic extra only for Pydantic interoperability. Add nemo-fabric-adapters-common only if the adapter chooses its lifecycle or Relay helpers. A bare adapter package should not depend on the NeMo Fabric runtime.

For a TypeScript adapter, depend on nemo-fabric-adapter-contract. Import descriptor, configuration, runtime-context, request, and result types from the package root, matching the Python package's single model namespace. TypeScript types do not validate data received from a process or network boundary; validate untrusted values against the JSON Schemas included with the package.

Map AgentConfig

Accept a validated AgentConfig and translate each declared field once at the adapter boundary:

  • Resolve named model roles into target-native model clients or settings.

  • Apply normalized instructions and runtime limits only when declared. Validate instructions.system.mode at the adapter startup boundary as well as during planning; replace discards the harness default, while append preserves it and adds the configured content after it.

  • Convert MCP servers, tool definitions, tool policy, and skills into native target constructs.

  • Resolve workflow entry points and construction settings during start in the task environment.

  • Read identity, environment, artifacts, and telemetry from RuntimeContext, not from workflow settings.

Reject unsupported values with stable, safe error codes. Do not log complete configs, environment values, headers, credentials, or arbitrary user input.

Use typed extension models and publish their schemas at the exact descriptor extension point. Never treat extensions as an unchecked dictionary escape hatch.

Implement the Lifecycle

Implement exactly one start, zero or more ordered invoke operations, and one stop for each NeMo Fabric runtime.

  • Construct and retain target state in start.

  • Accept AgentRunRequest and RuntimeContext, then return one AgentRunResult from invoke.

  • Make stop safe after partial startup and failed invocation.

  • Isolate mutable state between independent runtimes.

  • If the descriptor declares capabilities.streaming, implement async invoke_openai_stream(request, context, emit). Execute the target exactly once, await emit(chunk) only for the openai.chat_completions.chunk/v1 profile, and return one AgentRunResult. Each chunk requires non-empty id and model, a nonnegative integer created, the exact chat.completion.chunk discriminator, and structurally valid choices. An invocation that emits no chunks is valid.

  • Do not add an adapter streaming method for Relay-backed Runtime.invoke_stream(); execute ordinary invoke and use the provided telemetry context.

For native OpenAI streaming, the SDK owns the authenticated loopback HTTP transport with chunked NDJSON framing. The common host validates the transport, removes its credentials from the adapter payload, and supplies the emit callback. Do not persist or log stream credentials, write chunks to stdout, add SSE framing, or forward other target-native event profiles.

For a Python adapter that opts into the common host:

from nemo_fabric_adapter_contract.models import AgentConfig
from nemo_fabric_adapter_contract.models import AgentRunRequest
from nemo_fabric_adapter_contract.models import AgentRunResult
from nemo_fabric_adapter_contract.models import AgentRunStatus
from nemo_fabric_adapter_contract.models import RuntimeContext
from nemo_fabric_adapters.common import lifecycle


class TargetRuntime:
    async def start(self, payload):
        config: AgentConfig = payload["config"]
        ...

    async def invoke(
        self,
        request: AgentRunRequest,
        context: RuntimeContext,
    ) -> AgentRunResult:
        native = await self.target.run(request.input)
        return AgentRunResult(
            status=AgentRunStatus.SUCCEEDED,
            output={"response": native.text},
        )

    async def invoke_openai_stream(self, request, context, emit):
        async for chunk in self.target.stream(request.input):
            await emit(chunk)
        return AgentRunResult(
            status=AgentRunStatus.SUCCEEDED,
            output={"response": self.target.final_text},
        )

    async def stop(self):
        ...


def main() -> None:
    lifecycle.serve(TargetRuntime, config_loader=AgentConfig.from_mapping)

The common host decodes the internal lifecycle envelope before calling the adapter and encodes its terminal result afterward. Adapter code does not parse the transport envelope or infer failure from fields inside output. Return AgentRunStatus.FAILED with an AgentRunError when the target completes with a failed outcome. Raise an exception when the adapter cannot produce a normalized terminal result.

Support Warm Session Continuation

When later invocations must use earlier conversation state, retain that state on the adapter runtime created during start. Prefer a target-native live session whose lifetime and retention behavior are suitable for the deployment. Do not substitute a framework's development-only in-memory checkpointer in a production adapter. If the target has no suitable facility, retain the adapter-owned history required to construct its next native request.

Bound retained history so a live runtime cannot grow memory or model input without limit. When consumers need control, publish a typed adapter-wide harness.settings or target-specific workflow.settings field with explicit units, defaults, validation bounds, and overflow behavior. Do not overload runtime.max_turns, which limits one invocation's agent loop.

Keep session state separate from invocation state. Conversation context, required artifact references, and live workspace state may persist until stop; timeout state, invocation counters, terminal markers, result assembly, usage, and telemetry scopes reset for each invoke. Independent runtime instances must never share mutable continuation state.

Normalize usage per invocation in AgentUsage. If the target reports cumulative session totals, retain a session-local baseline and difference successive observed counters rather than summing cumulative snapshots or using only the last model response. Missing or reset counters remain unknown. Report cached_input_tokens when available and declare whether input_tokens includes cache with input_tokens_include_cache; omit the flag when the target's semantics are unknown. Preserve available usage on unsuccessful terminal results. Do not infer missing cost or promote estimates to cost_usd.

Test observable continuation rather than merely calling invoke twice: make the second result depend on the first turn without caller-side replay, then prove another runtime cannot observe that context. Refer to the LangGraph custom-agent example for an adapter-owned history pattern.

For in-process Relay SDK telemetry where the adapter owns the invocation-level Agent scope, wrap that scope with relay_request_context(context.request_id, request.relay_session_root) from nemo_fabric_adapters.common.utils. The helper uses a UUID request ID as Relay's propagated root and always returns nemo_fabric_request_id metadata, including for non-UUID request IDs. When the caller sets the typed AgentRunRequest.relay_session_root to a UUID string Relay accepts, that value becomes the root instead, a UUID request ID stays the parent (otherwise the session root is), and nemo_fabric_session_root is added to the metadata, so the caller's invocations share one Relay session. Context keys do not control propagation. An unusable session root falls back to a usable UUID request ID without raising; if neither value is usable, the helper returns nullcontext() without setting propagation. Do not apply this pattern to an external Relay gateway or an upstream integration that creates an isolated scope context unless its boundary accepts a per-turn propagation context.

Handle Custom Agents

For a shared framework adapter, select the registered target with FabricConfig.workflow.target_id. Use the selected Adapter Target Descriptor's spec.entrypoint.kind for adapter-scoped resolution semantics and ref for the factory identity. Validate workflow.settings against that target's spec.settings_schema.

  • Define only entry-point kinds that the shared adapter resolves unambiguously. The v1alpha2 contract does not define a global kind catalog.

  • Map a declared factory intent to the corresponding target-native factory. The current NeMo Agent Toolkit reference maps fabric.agent.react to its ReAct workflow factory.

  • Supply factories an adapter-defined build context containing already resolved native values; do not require custom agents to parse FabricConfig or AgentConfig.

  • Use a dedicated adapter without an artificial workflow entry point when the selected adapter already identifies one application-owned agent.

Compare the NeMo Agent Toolkit shared adapter with the dedicated LangGraph example before choosing the custom-agent boundary.

Validate Before Handoff

Complete these checks before handing off an adapter:

  1. Install the built wheel in an isolated adapter environment.

  2. Confirm discovery below share/nemo-fabric and inspect the resolved adapter and target descriptors in Fabric().plan(...).

  3. Exercise one accepted normalized config and rejection for unsupported fields and each declared schema.

  4. Run doctor(...) with both missing and satisfied requirements.

  5. Test start, success, target failure, malformed output, repeated invocation, stop, partial-start cleanup, EOF cleanup, and two-runtime isolation.

  6. If native OpenAI streaming is claimed, test empty and multi-chunk streams, malformed and oversized records, invalid chunks, sequence and identity mismatches, a missing end record, early consumer close without cancellation, a separate terminal result, one active turn, and exactly one target invocation.

  7. Test Relay correlation separately if telemetry support is claimed.

  8. Report the adapter package version, contract version, required-profile result, and every optional capability as supported or unsupported.

Do not claim automated NeMo Fabric conformance until the published conformance suite exists and the exact adapter release passes it.

Files

evals/evals.json

[
  {
    "id": "nemo-fabric-build-adapter-001-new-python-adapter",
    "question": "Build a third-party Python adapter package for AcmeHarness. It must accept normalized models, instructions, MCP servers, and tool policy, support repeated invocations, and expose registered workflows selected by target ID. Define the adapter and target descriptors, lifecycle, discovery metadata, and validation approach.",
    "expected_skill": "nemo-fabric-build-adapter",
    "expected_script": null,
    "ground_truth": "The agent builds against the published adapter contract. It defines a self-contained acme.fabric-adapter.json before implementation, declares only enforced normalized fields and capabilities, lists supported target types, and creates one *.fabric-target.json per registered workflow target with the same contract version, adapter_id, typed entry point, and closed workflow settings schema. It installs adapter and target descriptors under share/nemo-fabric/adapters and share/nemo-fabric/targets, maps the validated AgentConfig at the adapter boundary, implements start/invoke/stop with isolated runtime state, returns safe normalized outcomes, and validates discovery, planning of both resolved descriptors, doctor checks, lifecycle failures, cleanup, and runtime isolation.",
    "expected_behavior": [
      "Routes to nemo-fabric-build-adapter",
      "Uses the published adapter contract and committed JSON Schemas",
      "Defines a named *.fabric-adapter.json before implementing target translation",
      "Declares only normalized fields and capabilities the adapter enforces",
      "Lists supported target types and defines one *.fabric-target.json per registered workflow target",
      "Keeps adapter and target contract versions aligned and validates workflow settings against the target descriptor",
      "Installs discovery metadata under share/nemo-fabric/adapters and share/nemo-fabric/targets",
      "Maps a validated AgentConfig into target-native values at the adapter boundary",
      "Implements one start, ordered invoke calls, and one stop with isolated runtime state",
      "Tests discovery, resolution of both descriptors in plan, doctor, failures, cleanup, and two-runtime isolation"
    ]
  },
  {
    "id": "nemo-fabric-build-adapter-002-native-openai-streaming",
    "question": "Extend our third-party Python adapter, which uses the common Fabric host, with native OpenAI Chat Completions streaming. The target SDK yields chunks and a separate terminal result. What descriptor capability, lifecycle method, adapter-owned output rules, and tests are required?",
    "expected_skill": "nemo-fabric-build-adapter",
    "expected_script": null,
    "ground_truth": "The agent sets capabilities.streaming only when the adapter implements async invoke_openai_stream(payload, emit). The adapter invokes the target exactly once, awaits emit only for structurally valid openai.chat_completions.chunk/v1 mappings, translates target failures at the adapter boundary, and returns one separate JSON-compatible terminal outcome. It relies on the common host for authenticated loopback NDJSON transport and consumer lifecycle, does not emit SSE or log credentials, and tests empty and multi-chunk streams, invalid target chunks, target failure, one active turn, a separate terminal result, and exactly one target invocation.",
    "expected_behavior": [
      "Routes to nemo-fabric-build-adapter",
      "Declares capabilities.streaming only with an invoke_openai_stream implementation",
      "Invokes the target exactly once and awaits emit for each valid chunk",
      "Returns a separate JSON-compatible terminal outcome",
      "Uses the openai.chat_completions.chunk/v1 profile and valid chat.completion.chunk records",
      "Relies on the SDK-owned authenticated loopback NDJSON transport rather than SSE or stdout",
      "Tests empty and multi-chunk streams, invalid target chunks, target failure, one active turn, a separate terminal result, and exactly one target invocation",
      "Does not conflate native OpenAI streaming with Relay-backed ATOF streaming"
    ]
  },
  {
    "id": "nemo-fabric-build-adapter-003-consumer-integration-negative",
    "question": "Add NeMo Fabric to our existing application so it can choose Codex or Hermes Agent, validate configuration, invoke the selected harness, and return normalized results. We are not creating a new harness adapter.",
    "expected_skill": null,
    "expected_script": null,
    "ground_truth": "This is consumer-side SDK integration, not third-party adapter authoring. The agent must not route it to nemo-fabric-build-adapter and should use nemo-fabric-integrate when that skill is available.",
    "expected_behavior": [
      "Does not route to nemo-fabric-build-adapter",
      "Recognizes the request as consumer Python SDK integration",
      "Routes to nemo-fabric-integrate when it is available",
      "Does not propose a fabric-adapter.json descriptor or adapter lifecycle"
    ]
  },
  {
    "id": "nemo-fabric-build-adapter-004-first-party-maintenance-negative",
    "question": "Add a new first-party adapter inside the NVIDIA NeMo Fabric repository, including workspace packaging, catalogs, CI wiring, repository tests, and release metadata.",
    "expected_skill": null,
    "expected_script": null,
    "ground_truth": "This is repository-internal first-party adapter development. The portable third-party adapter skill must not handle it; the agent should use the repository's contribute-adapter maintainer workflow instead.",
    "expected_behavior": [
      "Does not route to nemo-fabric-build-adapter",
      "Recognizes the request as first-party NeMo Fabric repository maintenance",
      "Routes to the contribute-adapter maintainer workflow when it is available",
      "Keeps repository packaging, catalogs, CI, and release wiring out of the portable integration skill"
    ]
  },
  {
    "id": "nemo-fabric-build-adapter-005-system-instruction-composition",
    "question": "Our third-party harness has a native system prompt. Add normalized NeMo Fabric system instructions so consumers can either replace that prompt or append policy text after it. Define the descriptor claims, translation behavior, validation, and tests.",
    "expected_skill": "nemo-fabric-build-adapter",
    "expected_script": null,
    "ground_truth": "The agent declares instructions.system in config.accepts and explicitly lists replace and append in config.system_instruction_modes. Planning rejects modes outside that declaration, and the adapter validates the mode again at startup before applying it. Omitting instructions.system preserves the harness-native prompt, replace discards it, and append preserves it and adds the configured content afterward. Tests cover omission, both supported modes, an unsupported mode, descriptor validation, and startup failure without silently falling back.",
    "expected_behavior": [
      "Routes to nemo-fabric-build-adapter",
      "Declares instructions.system in config.accepts",
      "Declares the exact supported values in config.system_instruction_modes",
      "Preserves the harness-native prompt when instructions.system is omitted",
      "Implements replace and append with distinct composition semantics",
      "Validates the selected mode during planning and again at adapter startup",
      "Rejects unsupported modes instead of falling back or silently ignoring them",
      "Tests omission, replacement, append composition, descriptor claims, and unsupported-mode failure"
    ]
  },
  {
    "id": "nemo-fabric-build-adapter-006-relay-request-correlation",
    "question": "Our in-process third-party adapter uses the common Fabric host and owns the invocation-level NeMo Relay Agent scope. Propagate each Fabric request ID into Relay while preserving useful correlation for both UUID and non-UUID request IDs, and let a caller group invocations into one Relay session. Explain the boundary and validation.",
    "expected_skill": "nemo-fabric-build-adapter",
    "expected_script": null,
    "ground_truth": "The agent wraps the adapter-owned invocation-level Agent scope with relay_request_context(context.request_id, request.relay_session_root) from nemo_fabric_adapters.common.utils. A UUID request ID becomes Relay's propagated root, while every request ID is also emitted as nemo_fabric_request_id metadata; non-UUID values remain metadata only. A typed AgentRunRequest.relay_session_root UUID that Relay accepts becomes the root instead, with a UUID request ID as parent (otherwise the session root is also the parent) and nemo_fabric_session_root in the metadata; unusable session roots fall back to a usable UUID request root, otherwise the helper returns nullcontext() without setting propagation. Context keys do not control propagation. The adapter does not apply this pattern to an external Relay gateway or an upstream integration that creates an isolated scope unless that boundary accepts a per-turn propagation context. Tests cover UUID and non-UUID IDs, valid and unusable session roots, metadata, scope cleanup, and the unsupported boundary without leaking scope state.",
    "expected_behavior": [
      "Routes to nemo-fabric-build-adapter",
      "Uses relay_request_context with RuntimeContext.request_id",
      "Uses a UUID request ID as Relay's propagated root",
      "Always preserves the original value as nemo_fabric_request_id metadata",
      "Keeps non-UUID request IDs in metadata without treating them as propagated UUID roots",
      "Passes request.relay_session_root so its typed UUID becomes the propagated root, with a UUID request ID as parent and the session root as parent otherwise",
      "Falls back to the request root for a missing or unusable session root",
      "Applies the helper only when the adapter owns the invocation-level Agent scope",
      "Does not claim the same behavior for external gateways or isolated upstream scope boundaries",
      "Tests UUID and non-UUID correlation, valid and unusable session roots, plus scope cleanup"
    ]
  },
  {
    "id": "nemo-fabric-build-adapter-007-warm-session-continuation",
    "question": "Our custom-agent harness has no durable resume support, but sequential invocations on one live Fabric runtime must retain conversation context. Add warm continuation without inventing a cold-resume API or a shared transcript service. What state belongs where, and how should we test it?",
    "expected_skill": "nemo-fabric-build-adapter",
    "expected_script": null,
    "ground_truth": "The adapter creates and retains a target-native session with suitable deployment retention semantics or adapter-owned history on its per-runtime instance during start. It does not substitute a framework's development-only in-memory checkpointer in a production adapter. Each invoke appends the new request to that live state while resetting invocation-only timeout, counters, results, usage, and telemetry. Retained history has a deliberate bound; if consumers control it, the adapter publishes a typed setting with explicit units, defaults, validation bounds, and overflow behavior rather than overloading runtime.max_turns. Stop discards the state, and independent runtimes never share it. The implementation does not add durable resume, a Fabric-owned transcript store, or generic adapter-common history utilities. Tests require a second result that depends on the first turn without caller replay, direct evidence that prior context reaches the target, a history-bound case, and separate-runtime isolation.",
    "expected_behavior": [
      "Routes to nemo-fabric-build-adapter",
      "Uses the existing start, ordered invoke, and stop lifecycle",
      "Retains target-native or adapter-owned context on the per-runtime instance",
      "Avoids framework checkpointers that are documented only for development or testing",
      "Bounds retained history and documents any consumer-controlled setting and overflow behavior",
      "Separates retained session state from invocation-only state",
      "Does not introduce cold resume, durable storage, or a new resume method",
      "Does not put framework-specific conversation history in adapter-common",
      "Tests a context-dependent second invocation without caller replay",
      "Tests that prior context reaches the target and that the history bound is enforced",
      "Tests isolation between independent runtimes and cleanup at stop"
    ]
  }
]

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server, Needs Python

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
NVIDIA
Publisher
NVIDIA (Official)
Source
NVIDIA/skills · skills/nemo-fabric-build-adapter · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download nemo-fabric-build-adapter.zip