Submit GitHub Bug Issue

Purpose

File actionable QA findings as GitHub issues in the active repository: NVIDIA/TensorRT-Model-Connect.

Use this skill for bug issue submission only. Use $submit-github-pr for pull requests and $write-git-messages for commit, PR, squash, or rebase messages.

Ground Rules

• Treat GitHub as the active repository: https://github.com/NVIDIA/TensorRT-Model-Connect.git.
• Use the local github remote when Git operations are needed.
• Do not push branches or change repository files unless the user explicitly asks for code or skill edits.
• Do not create duplicate issues. Search first and reuse an existing issue when it already captures the same root cause.
• Keep claims evidence-based. Do not invent repro results, labels, issue numbers, hardware, CI behavior, severity, or suspected code locations.
• Prefer English issue text for GitHub unless the user explicitly requests another language.
• Never read, print, transform, or replay tokens/passwords from Git credential helpers. Use an already authenticated gh session.

Workflow

1. Authenticate And Resolve The Repository

gh auth status
gh repo view NVIDIA/TensorRT-Model-Connect \
  --json nameWithOwner,url,defaultBranchRef
git remote get-url github

If gh is unavailable, unauthenticated, or cannot read the repository, stop and ask the user to authenticate outside the sandbox. Do not fall back to extracting credentials or unauthenticated REST calls for this private repository.

2. Gather Evidence

Read the source artifact before drafting. For QA reports, extract:

• finding ID and severity
• concise symptom
• exact repro command or test case
• observed exit code, output, logs, or artifact path
• expected behavior
• affected model, strategy, command, or component
• environment details
• evidence count or case IDs
• suspected source path only when the evidence supports it

If the finding is too vague to create an actionable issue, ask for the missing critical detail instead of filing a weak report.

For a CI-generated finding, anchor the report to the exact source commit and the public, automated TRTMC Internal CI / Automated premerge gate status. Include a minimal public reproduction whenever possible. Internal CI logs, artifacts, package details, runner details, and internal URLs are private evidence: do not copy them into a Source issue. When authorized internal evidence is needed to establish the root cause, summarize only the public, actionable conclusion and preserve the Source-versus-Internal publication boundary.

3. Check Issue Templates

Check local templates:

find .github -maxdepth 3 -type f \
  \( -path ".github/ISSUE_TEMPLATE/*" -o -name "ISSUE_TEMPLATE.md" \) \
  -print

When a local template exists, follow it. When no local template exists, use the inline fallback bug format in the draft step below.

4. Check Labels

Verify that the requested label exists before creating the issue:

gh label list --repo NVIDIA/TensorRT-Model-Connect --limit 100

For bug reports, use bug when it exists. If it does not exist, create the issue without inventing a replacement label and report that the label was missing.

5. Search For Duplicates

Search open issues using concrete terms from the finding: CLI flags, model names, failing command, error string, source path, and root-cause wording.

gh issue list \
  --repo NVIDIA/TensorRT-Model-Connect \
  --state open \
  --search "<symptom terms>"

If a strong duplicate exists, do not file a new issue. Report the existing issue URL and explain the match. If the match is weak, file the new issue and mention related issues in the body only when relevant.

6. Draft The Issue

Use a concise title that starts with Bug: and names the failing behavior, not only the component or severity.

Default bug format when the repository has no template:

## Summary

<One short paragraph describing the bug and why it is wrong.>

## Environment

- Binary/version: <value if known>
- TensorRT/CUDA/platform/GPU: <values if known>
- Source run: <QA run, CI run, machine, or date if known>

## Affected Scope

<Commands, strategies, models, components, or cases affected. Use bullets or a
small table when useful.>

## Steps To Reproduce

```bash
<minimal command sequence>
```

## Actual Behavior

<Observed output, exit code, logs, generated artifacts, or failure mode.>

## Expected Behavior

<The contract the product should satisfy.>

## Impact

<Why this matters for users, CI, correctness, reliability, or debuggability.>

## Suspected Location

<Source path or subsystem, only when evidence supports it.>

Omit sections that are truly inapplicable, but keep Summary, Steps To Reproduce, Actual Behavior, Expected Behavior, and Impact for normal QA bugs.

7. Create The Issue

Create only after the user has authorized issue creation. Avoid writing a temporary body file unless the user asked for a local artifact; gh accepts stdin:

gh issue create \
  --repo NVIDIA/TensorRT-Model-Connect \
  --title "Bug: <concise symptom>" \
  --body-file - \
  --label bug

Omit --label bug when the label check proved it is absent. Do not create a label unless the user explicitly requested label administration.

8. Verify And Report

After creation, verify the issue state, URL, title, and labels:

gh issue view <number> \
  --repo NVIDIA/TensorRT-Model-Connect \
  --json number,title,state,labels,url

Report back with:

• issue URL and number
• label status, especially whether bug was applied
• template status
• duplicate-search result
• exact evidence or repro that was not independently verified
• any limitation, such as missing label or incomplete environment details

Multiple Findings

File one issue per root cause. Do not bundle unrelated failures into a single issue just because they came from the same QA report. If several cases share the same root cause, include them as affected scope/evidence in one issue.