Clone gpgpu-sim for issue triage and answer questions instead of only triaging

[JRPan]

Why

On #558 the triage bot ended with:

The simulator source code (GPGPU-Sim) is fetched at build time and is not present in this repository, so I could not inspect the actual implementation in gpu-simulator/gpgpu-sim/src/.

That was accurate — gpu-simulator/gpgpu-sim is not a submodule (there is no .gitmodules), it is cloned at build time by clone_gpgpusim in .github/scripts/lib/common.sh, and the triage job only checked out the framework. Most issues here are about the simulator core, so the bot could not ground the majority of what it was asked to triage.

Separately, #558 was a question, and the bot answered it with "the claim holds up" and "nothing needed from the reporter" — correct, and of no use to the person who asked.

What changed

gpgpu-sim is cloned for triage. Reuses the existing fork-aware .github/scripts/clone-gpgpusim.sh at the default branch. Non-fatal: a failed clone emits a warning, triage continues against the framework alone, and the skill is told to say so. The resolved branch@sha goes into the posted comment so every citation is traceable. Cost is ~2 s and 50 MB — the repo is smaller than the framework the job already checks out.

The skill has two paths, off an explicit classification.

	bug / other	question
Output	### AI Triage, maintainer-facing — unchanged	### Answer, reporter-facing
Passes	classify + triage	classify + 2 parallel researchers + compose

Path A answers the question: the mechanism, the config flags with their registered defaults (from option_parser_register, not the help string — the two sometimes disagree), and a mandatory Limits worth knowing section for hardcoded assumptions and unmodeled behavior.

Question triage fans out. Two researchers take complementary angles (mechanism vs. configuration/limits) and a compose pass verifies their citations against the source before using them. opencode's own task tool hangs against the local provider, so the fan-out is separate processes joined with wait; the optional LLAMACPP_B_URL repo var routes the second researcher to another llama.cpp server so the two do not queue on one instance.

Output extraction no longer depends on the write tool. The agents print their reply ending in a LABELS: line and bash extracts issue-triage.md / issue-labels.txt — the same pattern pr-ai-review.yml already uses after the empty-output failures. All four agents are read-only (bash: false): issue bodies are attacker-controlled text, so the model that reads them gets no shell.

New repo vars, all optional: OPENCODE_MODEL, OPENCODE_MODEL_LABEL, LLAMACPP_B_URL.

Testing

Ran the workflow's own extracted run: block against #558 on the runner host, both paths, two models.

• Classified question; labels question, simulator, ai-triage.
• Every citation in both runs was checked line-by-line against the source. No fabrications.
• The answer found addrdec.cc:236-238 — "H100 has 8 SMs per GPC. GPC abstraction is not yet implemented, so we hardcode 8 here…" — plus assert(n_chiplet <= 2) at l2cache.cc:1198 and the -inter_chiplet_queue_* flags. That is the substance of the maintainer's own hand-written reply on AccelSim V2 #558, recovered from the code.
• It also quoted -gpgpu_n_chiplet_partition's default as 1 (the registered value). The old run had repeated the help string's "Default: 2"; code and help string disagree.
• Wall clock: ~19-25 min for the question path vs ~4 min for the old single pass. With one server the two researchers serialize; with LLAMACPP_B_URL set they finished 0.04 s apart.

🤖 Generated with Claude Code