Skip to content

feat(triage): add code-grounding skill for issue-to-code mapping - #1

Draft
guyoron1 wants to merge 1 commit into
upstream-mainfrom
skills/code-grounding
Draft

feat(triage): add code-grounding skill for issue-to-code mapping#1
guyoron1 wants to merge 1 commit into
upstream-mainfrom
skills/code-grounding

Conversation

@guyoron1

@guyoron1 guyoron1 commented Aug 20, 2026

Copy link
Copy Markdown
Owner

Draft. Ports the useful half of two QualityFlow skills (lsp-tracer, feature-finder) into a fullsend-shaped skill for the triage agent. Opened on the fork for review before anything goes upstream.

Why — evidence from live runs

I pulled three Triage transcripts from fullsend-ai/.fullsend. Triage already grounds itself in the repository, and does it by hand.

  • The workflow checks out target-repo on every triage run (reusable-triage.yml:139), and the agent runs with cwd /sandbox/workspace/target-repo.
  • Run 32309336136 made 40 Bash calls, including cat .../drivers/install/driver.go ("understand recent rework"), cat .../drivers/scm/driver.go ("check for completion hooks"), and ls walks of the package tree.
  • The resulting comment was concrete: "the afterScenario hook in suite/init.go calls DeallocateRepo and CleanupScenario but performs no artifact collection… DeallocateRepo and Finalize are the right places to hook artifact collection."

So this is not a new capability — it is a procedure for something the agent already does per-run without guidance.

Precedent: this argument was already accepted for the code agent

fullsend#815 (merged 2026-05-14) added gopls to the code agent for exactly this reason:

The code agent relies entirely on grep/glob/Read for code navigation. Without a language server, it misses type-aware resolution — interface implementations, cross-package references, embedded struct fields, and call hierarchy.

That statement applies verbatim to triage today. fullsend-ai#815 also demonstrated the payoff end-to-end: 17 LSP calls in a sandbox test, including incomingCalls — which is the blast-radius question this skill's Step 4 asks and text search answers worst.

Two mechanics from fullsend-ai#815 matter here:

  • The harness plugins: field is generic and "mirrors the Skills pattern", so giving triage a plugin needs no code change.
  • The LSP tool is only registered when lspServers comes from a marketplace plugin definition; --plugin-dir alone loads the plugin without registering the tool (verified in feat(#814): make review agent multi-forge (GitHub + GitLab) fullsend-ai/agents#815: 23 tools vs 31). fullsend pre-populates the marketplace structure at bootstrap, so this is handled — but it is why the plugin path, not an ad-hoc binary, is the right mechanism.

What the skill adds

  • A repeatable discovery path: extract candidates from the issue → locate → read enough to be right → establish blast radius.
  • Grounding discipline: never name a path that was not opened; say so explicitly when the code could not be located, rather than describing the change abstractly.
  • A budget rule: skip grounding for duplicates, questions, and blocked issues — triage's timeout is 10 minutes and it runs on every issue.
  • Graceful degradation: prefer LSP where available, fall back to text search, and record which mode was used because it changes how much confidence a finding carries.

The open question: gopls is not in triage's image

Triage runs on ghcr.io/fullsend-ai/fullsend-sandbox. That image does not include gopls — images/code/Containerfile installs it (GOPLS_VERSION=0.22.0) and images/sandbox/Containerfile does not.

So this PR deliberately does not add plugins/gopls-lsp to harness/triage.yaml. Wiring the plugin without a language server in the image would be broken on arrival. The skill is written to work today on text search and to get better for free if semantic lookup reaches triage.

Making LSP available to triage would need one of:

  1. Add language servers to the sandbox image — this is #678 extended to triage's image. Helps every agent on that image; grows the base for agents that will never use it.
  2. Move triage to the code image — brings the Go toolchain and gitleaks along, on every issue including spam.
  3. A third image between the two — related to #772 and #5680, both tracking sandbox image layering.
  4. Leave it text-only — the skill still improves the discovery procedure; only blast-radius accuracy stays a lower bound.

I have no basis for choosing: the cost of options 1 and 2 falls on every triage run, and gopls in fullsend-ai#815 is installed via go install, so whether the sandbox image can carry gopls without the full Go toolchain is a question for someone who knows the image budget. Note also #1170 — plugin bootstrap currently hardcodes the Go PATH addition.

Not included

feature-finder's Jira-shaped input contract and lsp-tracer's Go-specific gopls bootstrap were dropped — this repo is forge-neutral and multi-language, so only the method transferred.

🤖 Generated with Claude Code

Triage already reads the target repository at runtime — the workflow
checks out target-repo on every run and transcripts show the agent
walking package trees and reading source before writing its analysis.
That navigation is currently improvised per run with ls and cat.

Add a code-grounding skill that codifies it: extract candidate symbols
from the issue, locate them, read enough surrounding code and repo
guidance to be right, establish the blast radius, and state findings so
they can be checked — never naming a path that was not opened.

The skill prefers semantic LSP queries where a language server is
available and falls back to text search where it is not, recording
which mode was used. It carries an explicit budget rule so grounding is
skipped for issues that will not reach implementation.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant