feat(triage): add code-grounding skill for issue-to-code mapping - #1
Draft
guyoron1 wants to merge 1 commit into
Draft
feat(triage): add code-grounding skill for issue-to-code mapping#1guyoron1 wants to merge 1 commit into
guyoron1 wants to merge 1 commit into
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.target-repoon every triage run (reusable-triage.yml:139), and the agent runs with cwd/sandbox/workspace/target-repo.cat .../drivers/install/driver.go("understand recent rework"),cat .../drivers/scm/driver.go("check for completion hooks"), andlswalks of the package tree.afterScenariohook insuite/init.gocallsDeallocateRepoandCleanupScenariobut performs no artifact collection…DeallocateRepoandFinalizeare 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:
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:
plugins:field is generic and "mirrors the Skills pattern", so giving triage a plugin needs no code change.lspServerscomes from a marketplace plugin definition;--plugin-diralone 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
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/Containerfileinstalls it (GOPLS_VERSION=0.22.0) andimages/sandbox/Containerfiledoes not.So this PR deliberately does not add
plugins/gopls-lsptoharness/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:
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 andlsp-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