Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

Commencer

maintain-observability

Étoiles73

Forks40

Mis à jour1 juillet 2026 à 15:57

Maintain or extend NeMo Relay observability surfaces across ATIF, OpenTelemetry, and OpenInference

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

NVIDIA

NVIDIA/NeMo-Relay

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	maintain-observability
description	Maintain or extend NeMo Relay observability surfaces across ATIF, OpenTelemetry, and OpenInference
author	NVIDIA Corporation and Affiliates
license	Apache-2.0

Maintain Observability Surfaces

Companion Guidance

Use karpathy-guidelines alongside this skill for implementation or review work. Keep changes scoped, surface assumptions, and define focused validation before editing.

Use this skill when changing event fields, exporter behavior, subscriber config, or binding parity for ATIF, OpenTelemetry, or OpenInference.

Surfaces To Keep In Sync

Core event model and emitted fields
crates/core/src/observability/atif.rs
crates/core/src/observability/otel.rs
crates/core/src/observability/openinference.rs
FFI and binding-native wrappers where the config or lifecycle is exposed
Python, Go, and Node.js config objects and subscriber/exporter methods
Docs under docs/about/concepts/subscribers.md and docs/export-observability-data/about.md

Design Checklist

Is this an event-model change, exporter-config change, or lifecycle change?
Do all bindings expose the same logical knobs and semantics?
Are mark events, start/end events, and orphan cases still handled correctly?
Do examples and docs reflect the same lifecycle: create, register, run, deregister, flush, shutdown?
Are span or trajectory fields still derived from the intended event data?

Validation

Run the affected Rust crate tests plus just test-rust if event fields changed.
Run just test-python, just test-go, and just test-node when binding-native config or lifecycle changed.
Update docs and examples in the same branch.

References

docs/about/concepts/subscribers.md
docs/export-observability-data/about.md
docs/export-observability-data/code-examples.md
crates/core/src/observability/atif.rs
crates/core/src/observability/otel.rs
crates/core/src/observability/openinference.rs
validate-change

Plus depuis ce dépôt

même dépôt

draft-release-notes

NVIDIA/NeMo-Relay

Compare NeMo Relay release branches and draft or update the documentation-site release notes. Use when preparing a release-notes update under docs/about-nemo-relay/release-notes, reviewing release-to-release changes, or gathering evidence for a current release summary.

2026-07-0873

contribute-docs

NVIDIA/NeMo-Relay

Contribute documentation or example changes that stay aligned with NeMo Relay public behavior

2026-07-0273

nemo-relay-build-plugin

NVIDIA/NeMo-Relay

Build and package reusable NeMo Relay runtime behavior as a config-activated plugin with validation and rollback-safe registration

2026-07-0273

add-binding-feature

NVIDIA/NeMo-Relay

Add or change a public NeMo Relay API surface across the core runtime and every affected binding

2026-07-0173

maintain-optimizer

NVIDIA/NeMo-Relay

Maintain or extend the NeMo Relay adaptive surface across config, plugins, docs, and bindings; use this when users still say optimizer

2026-07-0173

maintain-packaging

NVIDIA/NeMo-Relay

Maintain NeMo Relay package metadata, module paths, generated artifacts, and release-facing build surfaces

2026-07-0173

name	maintain-observability
description	Maintain or extend NeMo Relay observability surfaces across ATIF, OpenTelemetry, and OpenInference
author	NVIDIA Corporation and Affiliates
license	Apache-2.0

Maintain Observability Surfaces

Companion Guidance

Use karpathy-guidelines alongside this skill for implementation or review work. Keep changes scoped, surface assumptions, and define focused validation before editing.

Use this skill when changing event fields, exporter behavior, subscriber config, or binding parity for ATIF, OpenTelemetry, or OpenInference.

Surfaces To Keep In Sync

Core event model and emitted fields
crates/core/src/observability/atif.rs
crates/core/src/observability/otel.rs
crates/core/src/observability/openinference.rs
FFI and binding-native wrappers where the config or lifecycle is exposed
Python, Go, and Node.js config objects and subscriber/exporter methods
Docs under docs/about/concepts/subscribers.md and docs/export-observability-data/about.md

Design Checklist

Is this an event-model change, exporter-config change, or lifecycle change?
Do all bindings expose the same logical knobs and semantics?
Are mark events, start/end events, and orphan cases still handled correctly?
Do examples and docs reflect the same lifecycle: create, register, run, deregister, flush, shutdown?
Are span or trajectory fields still derived from the intended event data?

Validation

Run the affected Rust crate tests plus just test-rust if event fields changed.
Run just test-python, just test-go, and just test-node when binding-native config or lifecycle changed.
Update docs and examples in the same branch.

References

docs/about/concepts/subscribers.md
docs/export-observability-data/about.md
docs/export-observability-data/code-examples.md
crates/core/src/observability/atif.rs
crates/core/src/observability/otel.rs
crates/core/src/observability/openinference.rs
validate-change