Respond To IssueCAUTION
Ongoing research training transformer models at scale
Overview
Ongoing research training transformer models at scale
8ca032502ee6OBSERVED · 2026-10-06What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
--- name: respond-to-issue description: Research and draft a response to a GitHub issue or question from an external contributor. when_to_use: User shares a GitHub issue URL or asks to respond to a community question; 'respond to this issue', 'draft a reply', 'answer this GitHub question'. user_invocable: true argument: "<github-issue-url-or-number>" --- # Respond to GitHub Issue Help a maintainer draft a high-quality response to a GitHub issue from an external contributor. ## Workflow ### 1. Understand the issue - Fetch the issue using `gh issue view <number> --repo NVIDIA/Megatron-LM --json title,body,comments,labels,state`. - Read the title, body, and all existing comments to understand the full context. - Identify the type: bug report, feature request, question, or discussion. ### 2. Research the codebase - Based on what the issue is asking, search the Megatron-LM codebase for the relevant code. - Read the relevant source files to understand the current behavior. - If the issue references specific files or functions, read those directly. - Check `git log --oneline -20 -- <relevant-files>` to see if there have been recent changes that address or relate to the issue. - Use `git log -S "<symbol>" --oneline` to trace when code was added or removed — this is especially useful for questions about unused/deprecated code or missing features. - If the issue is about a bug, try to confirm whether the reported behavior matches the code. - Check whether an existing PR already addresses the issue: `gh pr list --repo NVIDIA/Megatron-LM --search "<keywords>" --limit 5`. ### 3. Verify before citing Before including specific details in the response, verify them: - If citing a commit hash, confirm the commit message and diff match what you're claiming (`git show <hash> --stat`). - If citing a file path and line number, re-read the file to confirm the line content is correct. - If claiming code is unused or missing, do a thorough grep to make sure you haven't missed a reference. ### 4. Draft the response Write a response that: - Is technically accurate and grounded in the actual code (cite file paths and line numbers where helpful). - Is respectful and welcoming to external contributors. - Directly addresses the question or concern raised. - If the contributor identified a real gap or bug, acknowledge it clearly. - If there's a workaround, mention it. - If work is planned or a fix would be welcome, say so and suggest next steps (e.g., "a PR to address this would be welcome"). - Keeps the tone professional but friendly. - Is concise -- contributors appreciate direct answers, not walls of text. ### 5. Suggest follow-up actions If the issue identifies something cleanly actionable (dead code to remove, a small bug fix, a missing feature), tell the maintainer and offer to create a branch and PR to address it — don't just draft a comment. ### 6. Present to the maintainer Show the drafted response to the user (the maintainer) for review. Do NOT post it to GitHub automatically. The maintainer will decide whether to post it, edit it, or ask for changes. Format the draft as a quoted markdown block so it's easy to copy. ## Important guidelines - Never post comments to GitHub without explicit approval from the user. - If you're unsure about the answer, say so clearly in your draft and flag the uncertainty for the maintainer. - If the issue is outside the scope of what you can determine from the code, tell the maintainer what you found and what remains unclear. - Check whether similar issues exist that might be relevant: `gh issue list --repo NVIDIA/Megatron-LM --search "<keywords>" --limit 5`.
Trust audit
CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | WARN |
| L1 | Static analysis of the code | NA |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (5)
.agents/skills
.claude/skills
CLAUDE.md
examples/post_training/modelopt/conf/nvidia/NVIDIA-Nemotron-Nano-9B-v2-Base.sh
megatron/core/models/hybrid/CLAUDE.md
Gates applied: no_behavioural_pass.
8ca032502ee6full audit observations/trust-audit/skill/nvidia__respond-to-issue.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-06 | 8ca032502ee6 | CAUTION | B | 89 | first audit |
Questions
What does the Respond To Issue skill do?
Ongoing research training transformer models at scale
Is Respond To Issue safe to install?
With care. The audit graded it B (89/100) and found 5 things worth knowing before you trust this skill, listed below with the exact line each was found on.
What can Respond To Issue access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
How current is this page?
The grade is for one exact copy of the source (8ca032502ee6), read on 2026-10-06. The repository is watched, and a new audit runs when it changes — this is the first audit.