Repository-Level Issue Resolution Framework Enhanced by Procedural Knowledge Guided Scaling
Experienced developers know something before they explore: how a kind of problem is diagnosed and fixed,
and why. Lingxi recovers this procedural knowledge from a repository's own history and puts it in front of
the coding agent, so that analysis, planning and fixing follow the procedure that fits the issue at hand.
Xu Yang1, Jiayuan Zhou2, Michael Pacheco2, Wenhan Zhu2,
Pengfei He1, Shaowei Wang1,∗, Kui Liu3, Ruiqi Pan3
1University of Manitoba, Canada · 2Huawei, Canada ·
3Huawei Software Engineering Application Technology Lab, China · ∗Corresponding author
Take-homeKnowledge comes first; exploration follows. Give the agent
the procedural knowledge behind issues of the same kind, how they are understood, analyzed and fixed, and why, and its
exploration gains a direction for the issue at hand.
01 · Motivation
Implicit knowledge tells developers where to look.
How does an experienced developer approach an issue? Before they explore, they already know something.
While learning and working, developers build up implicit knowledge: how a kind of problem is understood, analyzed and solved.
A new problem rarely matches an old one exactly, so they draw a few shared patterns from many past cases, and together these
patterns guide where they look first. Knowledge comes first; exploration follows.
An experienced developer
Draws on what past cases share
Many paths lead away from a slow page. The developer follows one, through the view and the ORM to the per-item
queries, and rules out a side branch early. The numbered steps are the procedure; the why is what makes it reusable on
the next slow page, even in a different codebase. That is procedural knowledge: how a kind of problem is diagnosed
and fixed, and why. It is implicit: it lives in experience, not in the code.
Procedural knowledge
When a page loads slowly:
1Count the database queries
2Find the loop that issues them
3Confirm it in the query log
WHYper-item queries, the N+1 problem, are a common cause.
How coding agents explore today
What a coding agent brings to the same situation: three ingredients
1
The model's own knowledge
General programming know-how in its weights: strong, and growing with every model.
2
The current repository
Its code and documents, as they are now.
Codebase & documents
3
Explore and traverse
Sample, branch, retry: many trajectories.
③ explores ② with ①. So, for this issue, will the right experience come to mind?
What today's agents miss
Not reliably, for two reasons.
Current agents are good at exploring in general. Two things keep that exploration from being guided by the
procedure that fits the issue at hand.
Without task-specific direction ③ exploration
Knowing how to explore, but not how this issue is best explored
Models are trained on large amounts of code and already know, in general, how to explore a repository: search, read,
reproduce, test. What they cannot know in advance is how this task is best approached in this repository: which practice
applies, what to check first, and how the fix must fit the existing code.
Nothing ensures the right practice is recalled at the right moment, and private codebases were never in the training data.
So gains come from more attempts: more samples, more retries. Coverage grows; direction for this issue does not.
In prior work: test-time scaling that samples many candidates and selects one, e.g. Trae, DARS, DEI.
At the surface procedural knowledge
Procedural knowledge missing, or history reused as raw data
Many agents use none: they work from the code and documents as they are now, which record the current state but not how
similar issues were handled. Those that do draw on history reuse it as raw data: past issue reports and patches, retrieved
as text. What was changed survives; the procedure behind it is lost: how the issue was diagnosed, and why this fix.
A copied change helps only when the new issue looks almost the same. The procedure behind it is what carries over.
Issue report
kept as raw data
Lost: procedural knowledge
How it was diagnosedroot-cause steps
Why this fixfix pattern
How to verifychecklist · tests
How to fit indesign practices
Final patch
In prior work: code graphs and ASTs of the current repository, e.g. Agentless, AutoCodeRover, CGM; similar
past issues as text, e.g. SemAgent.
What Lingxi doesLingxi recovers the procedure from the repository's own past
issues and their patches, abstracts it so it transfers to similar issues, and, when a new issue arrives, puts the relevant pieces
in front of the agent. The past fix is where the knowledge comes from; what the agent receives is the procedure.
02 · Method
Recover the procedure offline; guide every new issue.
Lingxi works in three phases. Phase 1 runs once per repository, over its history. Phases 2 and 3 run for each new issue:
the retrieved knowledge first steers the analysis, then the planning and the fix.
Overview of Lingxi, simplified from Figure 3 of the paper. The numbered labels match the three phases described below: 1 knowledge construction, 2 knowledge-guided analysis scaling, 3 issue resolution.
1Phase 1 · offline knowledge construction
From issue-specific to transferable knowledge.
A past fix leaves only two things: the issue report and the final patch. The procedure in between is missing,
so a knowledge agent recovers it in two steps. In Step 1 it reasons in reverse: it starts from the patch,
navigates the repository snapshot where the issue occurred, and explains why each edit fixes the issue. In Step 2
it abstracts the result so that it transfers to issues that are similar but not identical.
Knowledge is built per repository from its own history; for each target issue, only issues created before it are used.
Step 1 · reverse reasoning
Issue-specific knowledge
Starting from the patch, the knowledge agent explains why each edit fixes the issue, along 14 aspects.
general root-cause analysis stepsbug categorizationfeature
Fixing
Ready for planning and fixing
Change
general fix pattern
Verify
general fix checklist
Fit
design patterns & code practices
General root-cause analysis steps · same issue · step 2
"Identify the request handling flow and URL resolution process
Review how URL configuration is managed during request processing
Analyze object creation patterns and resource usage
Check for performance optimization opportunities like caching/memoization
Verify thread-safety and resource cleanup mechanisms
Test behavior with different URL configuration scenarios"
The issue: every request built a fresh URL resolver instead of reusing the cached one, wasting memory and time. Step 1 names
the class and the memoized function that was bypassed. Step 2 turns this into a way to diagnose similar problems in any codebase:
follow the request flow, look at which objects are created on every request, and check whether an existing cache is being bypassed.
2Phase 2 · knowledge-guided analysis scaling
One piece of knowledge per analysis agent.
A new issue arrives. Lingxi first summarizes it into four fields, then retrieves the knowledge of similar past
issues: an embedding search keeps the top 20, a reranker orders them, and the three most relevant are kept.
Why one source per agent? Put all retrieved knowledge into one long prompt and the model tends to lose what is
buried in the middle. Instead, each piece of knowledge guides its own analysis agent: three pieces, three agents, each following
a different procedure and writing its own report. Analysis synthesis then keeps what is supportive, complementary, accurate and
complete, and produces one consolidated analysis. The relevant knowledge is no longer left to recall; it is put in front of the agent.
← swipe to see the whole flow →
3Phase 3 · issue resolution
Plan and fix with analysis and issue-fixing knowledge.
The analysis says what is wrong; Phase 3 turns it into a patch with two agents. The issue-fixing part of the
retrieved knowledge guides both of them.
From phase 2
Consolidated analysis
Root cause · scope · constraints
What is wrong, where it sits in the code, and what the change must not break, merged from the parallel analyses.
From the knowledge base
Issue-fixing knowledge
General fix pattern
General fix checklist
Design patterns & code practices
→ shapes what the plan changes, and how the change fits the codebase
Planning agent
Explore → reproduce → plan
A root-cause assessment and a line-level change plan, informed by the analysis and the issue-fixing knowledge. The agent explores the code, reproduces the issue, and links each planned change to the problem it addresses.
Fixing agent
Implement → test → refine
Apply the change, run the reproduction test, and refine until it passes: the final patch. The checklist tells it what to verify. Both agents work with four tools: directory view, file view, keyword search and a string-replace editor.
03 · Evaluation
Does it pay off, and which knowledge helps?
All experiments use SWE-bench Verified: 500 real GitHub issues from 12 open-source Python projects, each checked by hidden tests.
Pass@1 is the share of issues whose single generated patch passes. For each target issue, knowledge comes only from issues created
before it.
Experiments with commercial models completed before Sept 2025
RQ1 · overall effectiveness
With the same base model, Lingxi resolves the most issues.
LingxiCompared framework, same base modelPass@1 (%)
← swipe to see all three groups →
How to readEach group uses one base model, so within a group only the framework differs. The baselines are
the top leaderboard entries that use the same base model; multi-model ensembles are excluded.
What it showsWith Claude 4 Sonnet, Lingxi reaches 74.6%, 4.2 points above the strongest compared frameworks,
OpenHands and Augment v1 (70.4%). With Kimi-K2, 70.3 versus 65.4. With GPT-4.1 mini, Lingxi nearly doubles mini-SWE-agent: 45.2
versus 23.9. Across groups, a stronger model lifts the same framework (the red line), and Lingxi is on top in every group. The
knowledge adds to the model; it does not replace it.
+6.5 ppRaw pairs → transferable knowledge68.30 → 74.80, both with parallel analysis
+2.3 ppParallel analysis, guided by knowledge72.48 → 74.80, both with transferable knowledge
How to readWhere does the gain come from: the knowledge, or the parallel agents? Each row removes or replaces
one part of Lingxi. The 218 issues are a statistical sample (95% confidence, 5% margin of error).
What it showsWithout knowledge, Pass@1 is 67.4 to 67.7. Raw issue–patch pairs, the fix without the procedure,
reach 68.3. Transferable procedural knowledge brings the largest step, to 74.8. Parallel analysis builds on that: with knowledge it
adds 2.3 points, because each path follows its own piece of knowledge and the findings combine; without knowledge, parallel analyses
of the same issue report land close to a single one. The two work together.
Differences are absolute percentage points; the paper's Table 3 reports the same results as relative Δ. The 218-issue
subset is a different scope from the 500-issue results in RQ1.
RQ3 · which knowledge helps, and when
Design practices matter most, and roles shift by stage.
Number of the 20 issues in which each knowledge aspect was decisive, by stage
Knowledge aspect
Analysisstage 1
Planningstage 2
Fixingstage 3
Totalall stages
Root-cause analysis steps
7
·
·
7
Relevant architecture
7
·
·
7
Bug categorization
3
·
·
3
Feature / functionality
3
·
·
3
Design patterns & coding practices
·
11
4
15
General fix pattern
·
6
8
14
Fix checklist
·
3
8
11
How to readWe took 20 issues that Lingxi resolved and its knowledge-free variant did not. Two authors compared
the two trajectories of each and marked which knowledge aspect was decisive at each stage (Cohen's κ = 0.66). A number counts the
issues in which that aspect was decisive at that stage; each stage column sums to 20.
What it showsIn analysis, root-cause analysis steps and relevant architecture dominate. In planning, design
patterns and coding practices take over. In fixing, fix patterns and checklists lead. Overall, design patterns and coding practices
matter most.
What a design practice looks like · sympy-23413
The Hermite normal form is wrong for rectangular matrices.
Two practices in the retrieved knowledge, from earlier sympy issues, became concrete actions in this issue:
Process the full structure, not a shape heuristicfrom sympy #10785
→
process all rows, not min(m, n)
Add boundary guardsfrom sympy #17130
→
stop when the columns run out: if k < 0: k = 0; break
Same pipeline, without knowledge
→
blamed the return statement, patched only the surface, and failed
Models know these practices in general. Retrieved knowledge brings the right one to mind, for this issue.
04 · Limitations & outlook
Knowledge helps most when the agent follows it.
127 of the 500 issues remain unresolved. We sampled 20 of these failures and asked why. In 15, the relevant knowledge was available,
and the agent set it aside and followed its own reasoning (the paper calls this uninformed autonomy); in 5, the retrieved knowledge was
too sparse to steer the repair. How and when knowledge reaches the agent matters as much as recovering it.
Upper bound · oracle selector, not a system result
79.2%
If three patches were sampled after Lingxi's analysis and an oracle always picked a passing one when it exists, 396 of 500 would
pass. Lingxi has no such selector; the number marks the headroom for better patch selection.
Next steps
Extend knowledge guidance from analysis into patch generation.
Balance agent autonomy with knowledge guidance.
Validate beyond Python: the knowledge is procedure rather than syntax, but SWE-bench Verified covers Python only.
05 · Discussion
From paper to practice: what code never records.
From the paperProcedural knowledge, how issues are diagnosed and fixed and why,
adds what the current code cannot show.
It complements tools you may already use. Take one question, from astropy issue #14182: an RST table is written
with a single header row, and the request is to let the writer add further header rows, such as units. On a time axis, three kinds of
tool give three kinds of answer.
PAST
LingxiProcedures and rationales from historical fixes
From #386 · feature & functionality
Supports reading/writing fixed-width formatted data
Handles configurable header structures
Supports various header configurations through header_rows
PRESENT
DeepWikiCode-grounded documentation, architecture and Q&A
io.ascii · RST page illustrative
RST format in io/ascii/rst.py
Built on the fixed-width classes
Header and data classes per format
INTENDED CHANGE
OpenSpecProposal, requirements, design and implementation tasks
Proposal · RST header rows illustrative
Why units in RST output
What accept header_rows
Tasks ☐ argument ☐ write rows ☐ test
Same astropy question, three kinds of answer: complementary perspectives, not exclusive capabilities. The DeepWiki and
OpenSpec entries are illustrative; the Lingxi entry is quoted from the transferable knowledge of astropy #386.
Related plugin · Lingxi Advisor
Procedural knowledge for your coding agent
Lingxi builds its knowledge offline, which is not convenient day to day. Lingxi Advisor
is a separate plugin built on the same idea: it brings procedural knowledge into everyday coding agents. Works with
iCode and OpenCode.
Runtimeuse it
When the agent is unsure, it searches the procedural knowledge prepared for this
repository and applies it, with sources.
Preparemine it
Derives procedural knowledge from a past issue and its patch, one at a time or in
batches.
Disclaimer. Lingxi Advisor is a related plugin, not a reproduction of this paper: it shares the paper's core idea,
procedural knowledge for coding agents, but its pipeline is its own and it is not the system evaluated in the paper. All numbers on
this page come from the research implementation, and the Distinguished Paper recognition applies to the paper. Installation and supported
platforms are in the plugin README.
06 · Cite
Cite this work.
Lingxi appears at ISSTA 2026 (Distinguished Paper). If you use it, please cite:
@inproceedings{yang2026lingxi,
title = {Lingxi: Repository-Level Issue Resolution Framework
Enhanced by Procedural Knowledge Guided Scaling},
author = {Yang, Xu and Zhou, Jiayuan and Pacheco, Michael and
Zhu, Wenhan and He, Pengfei and Wang, Shaowei and
Liu, Kui and Pan, Ruiqi},
booktitle = {Proceedings of the ACM SIGSOFT International Symposium
on Software Testing and Analysis (ISSTA)},
year = {2026},
note = {Distinguished Paper Award. Preprint: arXiv:2510.11838}
}
