# Lens Respond To Issue > Research and draft a maintainer response to a GitHub issue or community question on the NeMo Lens repo. Grounds the answer in the actual code and docs, verifies every citation, and hands the draft back for approval rather than posting it. - Skill: `nvidia-nemo/lens-respond-to-issue` (Agent Skill) - Install (CLI): `npx skillmds@latest add nvidia-nemo/lens-respond-to-issue` - Raw SKILL.md: https://api.skillmd.com/api/skills/nvidia-nemo/lens-respond-to-issue/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - License: Apache-2.0 - Author: NVIDIA NeMo (https://skillmd.com/u/nvidia-nemo) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/nvidia-nemo/lens-respond-to-issue --- # Respond to a GitHub issue Draft a high-quality maintainer response to an issue on `NVIDIA-NeMo/Lens`, grounded in what the code actually does. Most questions here come from users of a library they did not choose directly — lens arrives as an optional dependency of Megatron-LM, NeMo-RL, or NeMo-Gym. Assume the reporter knows their own framework well and lens barely at all. ## 1. Read the issue ```bash gh issue view --repo NVIDIA-NeMo/Lens --json title,body,comments,labels,state,author ``` Read the body and every existing comment before forming a view. Classify it — the templates label them `bug`, `enhancement`, or `question` — and note which consumer repo the reporter is coming from, since that usually determines the answer. ## 2. Route it Most questions land in one of a few buckets. Check the likely cause before reading code at random: | Symptom | Look first at | |---|---| | "No spans / nothing exported" | `NEMO_LENS_ENABLED` is `false` by default; then check whether the caller left `enabled` false on this rank (lens does no rank filtering of its own) | | "Works locally, nothing in my backend" | `OTEL_EXPORTER_OTLP_*` is the SDK's business, not lens's; check their endpoint before reading lens code | | "Some spans missing" | span groups — `default` is only `job`, `checkpoint`, `evaluate`. They likely want `per_step` or `all` | | "ImportError / no-op behavior" | the optional-dependency contract — `docs/design/optional-dependency.mdx`, `fallbacks.py` | | "Attribute or metric I expected isn't there" | `semconv.py` for the real name; then whether it's classified as a resource attribute, span attribute, or metric | | "Colliding trace IDs across ranks" | `SeedIndependentIdGenerator` — a known, fixed bug worth linking | | "How do I add X to my repo" | it's a consumer-side question; point at their `telemetry/` package, not lens | ## 3. Research the code - Search `src/nemo/lens/` for the relevant module — the layout table in `AGENTS.md` says which file owns what. - Read the source. Do not answer a behavior question from the docs alone; the docs are authoritative for intent, the code for what shipped. - `git log --oneline -20 -- ` — was this recently changed or already fixed? - `git log -S "" --oneline` — when did this appear or disappear? Useful for "why is this gone" and "was this ever supported". - Check whether a PR is already in flight: `gh pr list --repo NVIDIA-NeMo/Lens --search "" --limit 5` - Check for related issues: `gh issue list --repo NVIDIA-NeMo/Lens --search "" --limit 5 --state all` If the report involves a released version, check whether the behavior differs from `main` — `package_info.py` carries the version, and the docs are split between nightly (`docs/`) and the frozen `0.1.0` snapshot. ## 4. Verify before citing Every concrete claim in the draft gets checked: - Citing a file and line? Re-read it and confirm the line says what you claim. - Citing a commit? `git show --stat` and confirm it does what you say. - Claiming something is unused, missing, or unsupported? Grep thoroughly enough to be sure — a wrong "that's not supported" from a maintainer is expensive. - Quoting an env var? Confirm the exact name and prefix in `config.py`. The `USER_ID` key maps to the `user` field; that mismatch is easy to get wrong. - Recommending a config? Confirm the default in the `from_env()` table. ## 5. Draft Write a reply that: - Answers the actual question first, in the first line or two. - Cites `file:line` where it helps the reader verify you. - Acknowledges a real bug or gap plainly when the reporter found one. They did you a favor; say so. - Gives the workaround if one exists, even a clumsy one. - Says whether a fix is planned, and that a PR would be welcome if it would be. - Stays short. Contributors want an answer, not an essay. - Stays welcoming — many reporters are first-time contributors to an NVIDIA repo. If the honest answer is "that's a Megatron-LM / NeMo-RL / NeMo-Gym question", say so and point at the right repo, but answer the lens-shaped part first rather than bouncing them cold. ## 6. Offer the follow-up If the issue exposes something cleanly actionable — a doc page that is wrong, a missing fallback signature, a one-line fix — tell the maintainer and offer to open a branch and PR. Don't stop at drafting a comment when the fix is small. If it touches the public surface — `__all__`, a `fallbacks.py` signature, a `NemoLensConfig` field, a `SpanRegistry` method — say so explicitly. The consumer mirror obligation applies (Megatron-LM, NeMo-RL, NeMo-Gym each carry their own copy of that contract) and it is easy to forget from an issue thread. ## 7. Hand the draft back Show the draft to the maintainer as a fenced markdown block they can copy. **Do not post it.** Posting is the maintainer's decision, always. ## Guidelines - Never post or edit anything on GitHub without explicit approval. - Flag your own uncertainty in the draft rather than smoothing it over — the maintainer needs to know which parts they are vouching for. - If the code cannot settle the question, say what you established and what remains open. That is a useful answer; a confident wrong one is not. - Don't promise a timeline, a release, or a roadmap position on the project's behalf.