SkillForge: Self-Distilling Agents for Project-Specific Issue Resolution¹Silin Chen and Han Li contributed equally to this work.²Corresponding author: Xiaodong Gu.

To acquire project-specific knowledge without relying on historical issue reports, SkillForge synthesizes project-specific issues by rewriting functionality-critical code segments and treating the resulting test failures as resolution targets. Rather than explicitly injecting handcrafted bugs, the framework asks an LLM to reimplement repository functionality under constrained context, encouraging the rewritten code to naturally exhibit implementation mistakes similar to those introduced during real software development. More importantly, because the model must reconstruct functionality without access to the original implementation, the rewritten code reflects its general coding knowledge rather than the repository’s project-specific knowledge, thereby exposing the project-specific behaviors that the agent needs to learn. Throughout this process, supervision is derived solely from the repository’s codebase and test suite, without relying on historical issue reports or human-written bug descriptions.

Test-driven scope and trace. Given a code repository $\mathcal{R}$, SkillForge identifies test cases that exercise core repository functionalities, since these behaviors provide the most informative supervision for project-specific knowledge acquisition [3, 6]. For each passed test case, SkillForge executes it under coverage instrumentation to obtain an execution trace: the set of source files and line ranges that are exercised. This trace defines the candidate code regions for rewriting since modifications within executed regions are more likely to affect observable test outcomes. We then extract contiguous code segments from the traced regions—either complete functions or cohesive execution fragments, and attach surrounding context (e.g., preceding and following lines) for each segment.

Select critical segments. The number of traced segments can be large. We use an LLM to select a small set of critical segments that are most likely to represent the functionality of this test case. The LLM is given the test’s purpose and scenario (derived from the test code or description) along with summaries of the candidate segments (file, line range, and code content). It returns a ranked subset of top-$k$ segments with brief justifications. This step keeps the subsequent rewriting phase focused on high-impact regions. Unlike function-level rewriting approaches, SkillForge may select multiple critical segments exercised by the same test case, enabling synthetic issues that capture cross-component interactions within the repository.

Code rewriting. For each selected segment, we ask an LLM to rewrite the corresponding code by re-completing the local functionality. Crucially, the LLM is not provided with the original implementation; instead, it receives only limited contextual information: the lines before and after the segment, the segment’s location and indentation, and a high-level description of the test’s goal. The model is prompted to produce a plausible alternative implementation that preserves the intended API while potentially simplifying logic. Rather than explicitly injecting predefined faults, this “strict-mask” design exposes the gap between an agent’s general coding knowledge and the repository’s project-specific knowledge by inducing realistic implementation mistakes under constrained context.

Instance assembly and problem statement. Once the rewritten segments induce test failures, we construct a buggy repository snapshot and derive both a buggy patch and a reference patch. Following prior synthetic SWE task construction works [50, 39, 20], we execute the failing tests and use an LLM to convert the resulting failure evidence into a user-facing problem statement without exposing implementation details or repair hints. The resulting synthetic instance consists of a base commit, a buggy patch, a reference patch, a problem statement, and the associated test cases, matching the standard SWE-bench issue-resolution format. These synthetic instances serve as self-supervised tasks for acquiring project-specific knowledge before real issue resolution.

Issue Resolution Attempt For each synthesized instance, SkillForge follows the SWE-bench-style issue resolution protocol: the agent is placed in an isolated repository environment, receives the problem statement and buggy codebase, and attempts to produce a patch that resolves the failing tests. We record the resulting action trajectory (e.g., file edits, shell commands, and test runs) for subsequent skill distillation.

The objective of this stage is to distill project-specific knowledge from synthetic issue-resolution trajectories and organize it as reusable skills. Formally, given a trajectory $\mathcal{T}=\{(a_{1},o_{1}),\dots,(a_{n},o_{n})\}$ where $a_{i}$ and $o_{i}$ denote the agent’s action and the environment’s observation at step $i$, our extraction pipeline transforms $\mathcal{T}$ into two complementary skill sets within the dual-level skill repository: $\mathcal{M}_{ext}$ and $\mathcal{M}_{int}$.

Trajectory Normalization and Entity Alignment. Before skill distillation, we normalize the trajectories and align them with the repository’s entities. Given a target repository $\mathcal{R}$, we perform a structured analysis of the trajectory $\mathcal{T}$ to identify code-access events. By parsing shell commands (e.g., grep, sed, cat) in the trajectory, we extract a set of accessed files, represented by coordinates and line ranges. We then align these coordinates with the repository’s structural index—an AST-derived mapping from source files to their class and function hierarchies—to resolve them into cohesive code scopes (e.g., frequently accessed files or core modules). Beyond trajectory-derived accesses, files surfaced in the agent’s submission diff, the golden patch, and the test patch are additionally incorporated to ensure coverage of ground-truth edit sites. The resulting collection is denoted as a set of candidate entities $\mathcal{E}_{cand}\subseteq\mathcal{R}$. This step ensures that the extracted skills are strictly grounded in the actual codebase structure, preventing the LLM from hallucinating non-existent interfaces during subsequent extraction.

Distilling Global Diagnostic Skills ($\mathcal{M}_{ext}$). $\mathcal{M}_{ext}$ represents project-specific diagnostic knowledge as global diagnostic skills distilled from synthetic issue-resolution trajectories. Unlike repository summaries that describe what a module contains, $\mathcal{M}_{ext}$ captures how an agent should reason about a repository entity during issue resolution, including where to begin debugging, which APIs are jointly involved, and what repository-specific behaviors should be considered. These skills are organized as structured skill records and associated with the corresponding repository entities for future retrieval. For each candidate entity $\alpha\in\mathcal{E}_{cand}$, an LLM analyzes the corresponding resolution trajectories together with the repository context to distill three complementary aspects of project-specific knowledge: (i) the entity’s functional role in issue resolution, (ii) reusable reasoning strategies repeatedly validated during issue resolution , and (iii) project-specific API interactions that emerge during problem solving. These are represented as the purpose, playbook, and related_apis fields, respectively. For example,

The design of each key is specifically tailored to enhance the agent’s autonomous capabilities: (1) The purpose field identifies the role an entity plays during issue resolution, helping the agent determine whether it is a relevant debugging entry point rather than merely summarizing its implementation. (2) The playbook field captures project-specific reasoning patterns distilled from trajectories. Rather than generic debugging advice, it records repository-specific knowledge that has been validated through interaction with the repository. (3) The related_apis field records APIs that are repeatedly co-involved during issue resolution. Unlike static dependency graphs, these relationships reflect repository-specific interaction patterns observed during problem solving, allowing the agent to navigate cross-module behaviors that are not evident from structural dependencies alone.

Unlike repository summarization, which captures static code semantics, our objective is to distill actionable project-specific knowledge that emerges only when an agent attempts to solve project-specific issues.

Distilling Local Intervention Skills ($\mathcal{M}_{int}$). In contrast, $\mathcal{M}_{int}$ stores project-specific intervention knowledge that guides how a repository entity should be modified during issue resolution. Unlike $\mathcal{M}_{ext}$, which supports repository navigation and diagnosis, $\mathcal{M}_{int}$ captures concrete repair knowledge distilled from issue-resolution trajectories. This knowledge is represented as local intervention skills associated with individual repository entities. We distill this intervention knowledge from both successful and failed resolution trajectories. Successful trajectories reveal repair strategies that consistently lead to correct implementations, while failed trajectories expose repository-specific pitfalls by contrasting incorrect patches with the corresponding reference patches. The resulting knowledge is transformed into actionable intervention skills and indexed by repository entities. Combining successful and failed trajectories provides complementary supervision: the former reinforces effective repair patterns, whereas the latter helps the agent avoid recurring mistakes when modifying the same repository entities in future issue-resolution tasks. For example,

Conceptually, $\mathcal{M}_{ext}$ captures diagnostic skills for understanding repository entities and planning repository navigation, whereas $\mathcal{M}_{int}$ captures intervention skills for modifying those entities based on project-specific knowledge distilled from synthetic issue resolution.

To utilize the acquired project-specific knowledge during downstream issue resolution, SkillForge retrieves the distilled skills associated with relevant repository entities and injects them into the agent’s reasoning process. This retrieval follows a two-stage, context-aware mechanism consisting of macro-level initialization and micro-level just-in-time (JIT) intervention.

Macro-level Initialization with Global Diagnostic Skills. Before the agent begins resolving a new issue, we first establish a global semantic context using the diagnostic knowledge represented by the global skill set ($\mathcal{M}_{ext}$). Given the new issue description as a query, we employ a BM25 retriever to identify the top-$k$ most relevant skill records from $\mathcal{M}_{ext}$. The selected records—comprising the API paths, their purposes, and the associated playbooks—are prepended to the agent’s initial prompt as project-specific priors. This equips the agent with an immediate, high-level understanding of the repository’s architecture and relevant previously distilled heuristics.

Micro-level JIT Injection of Local Intervention Skills. While the macro-level injection provides initial guidance, flooding the context with all local intervention skills ($\mathcal{M}_{int}$) at once would introduce significant noise. Instead, SkillForge dynamically injects $\mathcal{M}_{int}$ based on the agent’s real-time actions. At each interaction step, SkillForge monitors the agent’s executed shell commands to extract the specific file paths it is currently accessing. If an accessed file matches an entry in $\mathcal{M}_{int}$, the corresponding intervention cues and reflections are appended to the agent’s context as an auxiliary observation for the subsequent reasoning step. This dynamic mechanism ensures that the agent receives targeted, pitfall-avoidance guidance exactly when it navigates to a relevant codebase region, ensuring the injected skills are strictly aligned with the agent’s current code interaction context.

Unlike existing methods that retrieve semantically similar records from a centralized knowledge store, SkillForge grounds project-specific knowledge directly to repository entities. Consequently, retrieval is triggered by the agent’s interaction with the corresponding code entities rather than solely by semantic similarity. This entity-grounded design ensures that diagnostic and intervention knowledge is delivered precisely when the agent reaches the relevant repository context, reducing retrieval ambiguity while maintaining tight alignment between the injected knowledge and the code under inspection.

We aim to evaluate SkillForge by answering four research questions (RQs):

RQ1 (Effectiveness of SkillForge): What is the impact of SkillForge on issue resolution performance compared to other self-evolving methods?

RQ2 (Ablation Study): How do the different components of SkillForge individually affect its effectiveness?

RQ3 (Impact of Hyperparameters): How do the key hyperparameters influence the overall performance of SkillForge?

RQ4 (Efficacy across Diverse Repositories): Does SkillForge consistently demonstrate effectiveness across various repositories?

We evaluate SkillForge on SWE-bench Verified [34], a human-validated benchmark released by OpenAI, which has been widely adopted as the standard for evaluating software engineering agents. The benchmark consists of 500 tasks sourced from popular Python repositories on GitHub.

We additionally evaluate on the full SWE-bench Pro [7], consisting of 731 instances across Python, JavaScript, TypeScript, and Go repositories. This benchmark contains more challenging long-horizon software engineering tasks that better reflect realistic multi-file issue resolution.

We compare SkillForge with representative approaches that acquire project-specific knowledge from different supervision sources.

History-driven project-specific knowledge acquisition. These methods acquire project-specific knowledge from historical issue-resolution issues, and reuse the distilled knowledge to assist future issue resolution.

• •

  SWE-Exp [5]: A framework that distills diagnostic patterns and repair strategies from prior agent trajectories, utilizing a dual-agent architecture to provide actionable guidance for new tasks.

• •

  EvoCoder [28]: A multi-agent continual learning framework that uses trajectory-based reflection to progressively refine problem-solving strategies based on previously resolved cases.

• •

  MemGovern [43]: MemGovern converts human debugging traces from GitHub into structured memory, enabling code agents to leverage prior problem-solving knowledge for improved issue resolution.

Online project-specific knowledge acquisition. These approaches adapt agents during the resolution of the current issue by distilling project-specific knowledge from substantial online reasoning trajectories through test-time exploration:

• •

  SAGE [16]: A plan-learning method that distills reusable problem-solving guidance from ongoing agent attempts to iteratively improve performance on the current instance.

• •

  SWE-Debate [26]: A multi-agent competitive framework that evolves stronger fix strategies through structured debate over competing reasoning trajectories.

• •

  Live-SWE-agent [47]: A live self-evolving software agent that autonomously updates its own scaffold during runtime while solving software engineering tasks.

Variants of SkillForge. To isolate the source of project-specific knowledge in SkillForge, we compare against two controlled variants while keeping the same downstream reused mechanism:

• •

  SkillForge w/ SWE-Smith. A controlled synthesis variant that replaces our functionality-level repository probing with SWE-Smith single-function rewriting.

• •

  SkillForge w/ LLM Summary. A static repository-understanding variant that replaces trajectory-distilled project-specific knowledge with LLM-generated repository summaries.

We evaluate SkillForge from both effectiveness and cost-efficiency perspectives.

Pass@1 denotes the percentage of issues successfully resolved on the first attempt, following the evaluation protocol of [2, 49]. It directly measures the framework’s ability to generate correct patches without relying on repeated repair iterations.

Avg Cost represents the average end-to-end monetary cost per evaluated issue, measured in U.S. dollars [9]. The reported cost amortizes offline pre-computation over the evaluated instances and includes all stages of the framework pipeline, including synthetic issue generation, trajectory collection, skill distillation, and online issue resolution. MemGovern [43] constructs a pre-constructed $\sim$150K-card experience base from public GitHub issues using GPT-5.1; since the associated preprocessing cost is unavailable, it is excluded from Avg Cost.

We implement SkillForge with Mini-SWE-Agent [40], a bash-based agent scaffold [15, 16, 46], and evaluate DeepSeek-V3.2 [29] and GPT-5-mini [38] with default inference settings.

For SWE-bench Verified, synthesis is temporally isolated. For each target instance, we first roll back the repository before both the golden patch and golden test patch; on this rolled-back snapshot, an LLM localizes semantically relevant tests because extracting the full test suite from every snapshot is time- and compute-intensive. We synthesize issues only from this filtered subset, yielding 577 synthesized issues. SkillForge itself does not require historical issue-resolution data; in the temporal evaluation protocol, the agent may retrieve only skills distilled from synthesized issues in the same repository whose source commits predate the target instance’s gold commit, ensuring that no current-instance or future information is used.

For the two variants, we extract relevant functions from the baseline agent’s trajectory, then apply either SWE-Smith-style single-function rewriting or an LLM summary of how those functions are jointly used; both keep SkillForge’s skill format and injection interface. Across all stages, temperature is 0, the action budget is 250 steps, BM25 retrieves top-$5$ skills, and Table I reports Pass@1 averaged over three runs.

Table I summarizes the main results on SWE-bench Verified. SkillForge achieves 72.2% and 60.6% Pass@1 with DeepSeek-V3.2 and GPT-5-mini, outperforming all baselines by absolute margins of +5.8% and +5.6% over Mini-SWE-Agent. Among history-driven project-specific knowledge acquisition methods, MemGovern is the strongest competitor (69.2%/58.0%), yet SkillForge still surpasses it by +3.0%/+2.6%. One possible reason is that history-driven project-specific knowledge acquisition methods are bounded by the coverage and quality of repository history: knowledge distilled from prior repository histories only reflects previously observed issue types, often remains coarse or instance-tied, and external debugging discussions improve coverage only by weakening repository specificity. Among online project-specific knowledge acquisition methods, SkillForge also surpasses SAGE (67.2%/56.0%) and SWE-Debate (68.2%/56.4%), with gains of +5.0%/+4.6% and +4.0%/+4.2%, respectively, while avoiding the high per-issue exploration cost of methods such as SWE-Debate. For DeepSeek-V3.2, it also outperforms Live-SWE-agent (67.0%, $0.050) by +5.2%. Compared with Mini-SWE-Agent and history-driven project-specific knowledge acquisition methods, the main cost difference of SkillForge lies in the offline pre-computation stage, where it synthesizes project-specific issues and distills skills from their resolution trajectories. Therefore, the reported Avg Cost includes amortized offline pre-computation; once this repository-level skill repository is built, the online cost of resolving each real issue remains close to that of the underlying agent.

Table II further reports results on SWE-bench Pro. SkillForge achieves 34.1% Pass@1 with DeepSeek-V3.2 and 51.7% with GPT-5-mini, improving over Mini-SWE-Agent by +5.8% and +4.1%, respectively, with both gains statistically significant ($p$-value $<$ 0.05). It also outperforms the strongest available Pro baselines, exceeding Live-SWE-agent by +1.7%/+2.6% and SWE-Exp by +4.7%/+3.2% under the two backbones.

Among the controlled variants, SkillForge w/ SWE-Smith reaches 68.0%/$0.088 and 56.4%/$0.071 under DeepSeek-V3.2 and GPT-5-mini, respectively, while SkillForge w/ LLM Summary reaches 68.7%/$0.069 and 54.4%/$0.065. These results show that skill injection alone is insufficient: both simply summarizing trajectory-extracted functions and rewriting one function at a time underperform the full method. SWE-Smith rewrites one function at a time, whereas SkillForge starts from a repository functionality exposed by a core test, follows its execution trace, and rewrites multiple coordinated functions or code segments that are naturally composed to realize that functionality. This functionality-level synthesis captures inter-function coordination, API coupling, and project-specific repair pitfalls, while more naturally surfacing the current LLM’s repository-misaligned coding tendencies.

We investigate two questions: (1) whether both forms of project-specific knowledge are necessary for issue resolution, and (2) whether project-specific knowledge distilled for one LLM backbone transfers to another.

We investigate the sensitivity of SkillForge to two key hyperparameters governing project-specific knowledge acquisition and utilization: (1) the number of retrieved global diagnostic skill records per issue ($k_{r}$), and (2) the number of code segments rewritten to synthesize project-specific issues ($k_{s}$).

To evaluate $k_{r}$, we conducted a hyperparameter study on the Django and Sphinx repositories using GPT-5-mini, varying $k_{r}$ from 0 to 7, as well as a “full” condition where all relevant skill records were retrieved. Figure 4(a) reports Pass@1 as a function of $k_{r}$ across the two repositories. Without retrieving project-specific knowledge ($k_{r}=0$), the agent achieves 62.3%. Performance improves steadily as $k_{r}$ increases, reaching its peak at $k_{r}=5$ (69.7%). Beyond this point, the full retrieval condition drops slightly to 67.5%, suggesting that lower-ranked skill records introduce redundant project-specific knowledge that competes for the limited context window. Both repositories show the same overall pattern, indicating that a moderate number of retrieved skills is preferable across different repository structures.

To evaluate $k_{s}$, we varied the number of code segments rewritten during issue synthesis on both repositories. With no rewriting ($k_{s}=0$), the system reduces to the baseline (62.3%). Rewriting a single segment ($k_{s}=1$) increases performance to 63.2%. Performance peaks at $k_{s}=5$, where each synthesized issue exposes sufficiently rich project-specific knowledge by involving multiple interacting repository entities. Increasing $k_{s}$ to 7 results in a slight decrease, as larger perturbations tend to generate overly complex issues that reduce the quality of the distilled project-specific knowledge. The same trend is consistently observed across repositories, suggesting that functionality-level synthesis benefits from a moderate rewriting scope rather than either single-segment perturbations or overly broad rewrites.

Notably, across all settings of $k_{r}$ and $k_{s}$, SkillForge consistently outperforms the baseline without project-specific knowledge, demonstrating that proactively acquired project-specific knowledge remains effective across a broad range of synthesis and retrieval configurations.

To assess whether SkillForge generalizes across different repositories, we analyze performance at the repository level. Due to space constraints, we report results for the seven repositories with the largest numbers of evaluation instances. Figure 5 compares three methods—Baseline, SWE-Exp, and SkillForge—across these seven repositories under both DeepSeek-V3.2 and GPT-5-mini.

SkillForge delivers improvements over the baseline on all seven repositories under both backbones without any regression. With DeepSeek-V3.2, the per-repo gains reach up to +13.6% (Sphinx); under GPT-5-mini, gains reach up to +15.6% (Scikit-learn). In contrast, SWE-Exp shows inconsistent behavior and suffers regressions on three repositories. Under DeepSeek-V3.2, Matplotlib drops by $-$11.8% and Astropy by $-$4.5%; under GPT-5-mini, Astropy regresses by $-$9.1% and Pydata by $-$2.0%. Because SkillForge derives project-specific knowledge directly from each target repository through self-distillation, the resulting knowledge naturally reflects repository-specific APIs, implementation patterns, and architectural organization. Representing this knowledge as entity-grounded skills enables precise retrieval during downstream issue resolution, leading to consistently robust improvements across diverse repositories.

To provide a more concrete view of how SkillForge changes the behavior of a repair agent, we present a case study on Django issue #11206. The bug concerns formatting extremely small Decimal values when a fixed number of decimal places is explicitly requested. In the buggy version, calling nformat(Decimal("1e-200"), ".", decimal_pos=2) returns "1.00e-200", i.e., scientific notation, whereas users expect a fixed-point representation such as "0.00". Correctly fixing this issue requires reasoning about when a value should be treated as numerically zero at a given precision, without breaking existing formatting behavior for other magnitudes or types.

Figure 6 contrasts two repair trajectories on this issue using the same GPT-5-mini backbone: one without project-specific knowledge and one with SkillForge retrieving project-specific knowledge in the form of entity-grounded skills. The baseline agent locates the relevant formatting module and identifies the condition responsible for scientific notation. It then adopts a simple exponent-based heuristic to determine whether a value should be treated as zero. Although this modification fixes the observed failing example, it fails to capture the repository’s intended numeric semantics and ultimately fails all FAIL_TO_PASS tests (0/2).

In contrast, the skill-enhanced agent follows a longer but more structured reasoning process. After accessing the same module, the retrieved project-specific knowledge highlights two repository-specific insights: (i) preserve the existing Decimal formatting pipeline instead of introducing alternative representations, and (ii) reason about numerical equivalence using the repository’s precision semantics rather than a simple exponent heuristic. Guided by these insights, the agent derives a threshold-based solution that integrates naturally with the existing formatting logic. It further validates the implementation using representative boundary, precision-sensitive, and extreme-value test cases before committing the fix, ultimately passing all FAIL_TO_PASS tests (2/2).

This example illustrates how proactively acquired project-specific knowledge reshapes the agent’s reasoning process during issue resolution. With skill injection, the agent (i) adopts a more faithful mathematical model of the bug (value-based thresholding versus exponent-based heuristics), (ii) preserves important design constraints of the existing implementation (e.g., maintaining Decimal-level operations and respecting the original formatting path), and (iii) naturally gravitates toward a test-driven workflow that exercises subtle edge cases. In contrast, the baseline trajectory quickly converges to a plausible but brittle local heuristic that fails under systematic evaluation, underscoring the value of skill-enhanced reasoning for non-trivial software bugs.

We manually inspected the quality of the distilled skills and synthesized problem statements. For the distilled skills, we verified that they are grounded in the corresponding repository entities, resolution trajectories, and golden patches, providing correct and actionable project-specific guidance without hallucinated APIs or misleading advice. For the synthesized problem statements, we verified that they faithfully describe the observable failures induced by functionality-level rewriting without leaking implementation details.

We also compared the issue-type distribution of synthesized issues with that of real SWE-bench issues from the same repositories. The two distributions do not overlap, suggesting that the synthesized issues do not merely reproduce the same categories of real issues used for evaluation. Instead, they tend to expose finer-grained model biases in how the current LLM uses project-specific functions, APIs, and cross-function interactions. Thus, the benefit of SkillForge is less about teaching the agent to solve similar issue types and more about surfacing project-specific function-use pitfalls that can transfer across different real issue categories.

Recent SWE agents [35, 41, 36, 4, 48, 55, 54, 56, 17, 11, 19] have increasingly moved beyond one-shot issue solving toward self-evolving behavior, where the agent improves by distilling reusable guidance from prior histories, trajectories, and execution feedback. These methods can be broadly grouped by the source of their evolution signal. One line of work evolves from repository history. EvoCoder [28] and SWE-Exp [5] accumulate past interaction trajectories and distill abstract problem-solving patterns to guide future tasks. ExpeRepair [32] organizes previously resolved bugs into structured memories for later patch generation, while MemGovern [43] harvests community debugging traces from GitHub to improve the agent’s decision-making process. Another line of work evolves from online trajectories produced on the current instance. SWE-Debate [26] iteratively strengthens solutions through multi-agent debate, SAGE [16] abstracts high-level guidance from trial-and-error grounding during test-time scaling, and Live-SWE-agent [47] evolves its own runtime scaffold while solving the current task. Unlike these reactive paradigms, SkillForge targets the cold-start problem in project-specific issue resolution. Instead of acquiring project-specific knowledge only after accumulating repository history or online exploration trajectories, it proactively derives such knowledge directly from the repository by synthesizing project-specific issues, and represents this knowledge as entity-grounded skills for future issue resolution.

Recent work [53, 18, 42] has explored synthesizing software issues or executable environments to improve software engineering agents. Existing methods primarily view synthesized instances as scalable training data. SWE-Smith [50] constructs synthetic bug-fixing tasks by independently rewriting individual API-level functions. R2E-Gym [20] generates executable SWE environments through test generation and commit back-translation to support large-scale agent training. BugPilot [39] synthesizes feature-development tasks that unintentionally introduce bugs, producing realistic development scenarios for subsequent model training.

In contrast, SkillForge uses synthetic issues for a fundamentally different purpose: proactive project-specific knowledge acquisition rather than training models. Instead of maximizing the number or diversity of synthesized tasks, SkillForge aims to expose project-specific knowledge that cannot be readily inferred from static repositories alone. Its issue construction also differs in granularity: rather than rewriting isolated API-level functions, randomly selecting several functions for joint rewriting, or generating new features, SkillForge starts from repository-tested functionalities and uses test execution traces to identify the code regions that jointly implement the same functionality. Solving the resulting issues reveals how the agent’s general coding priors diverge from project-specific implementation patterns and API interactions.