A new preprint does not claim to solve the central question of what happens between a written specification and the code that may follow it. Instead, it introduces SpecMine, a public GitHub corpus designed to make that question measurable. The collection brings together specification-like files, their full commit histories, parsed structural features, selected pull requests, and typed references to code and other repository artifacts.
A large but filtered census
The scale is the headline finding. The broad census contains 470,795 spec.md or specs.md files across 73,030 repositories, with the files attributed to 17 named tools. A separate Kiro census contains 98,574 artifacts across 12,910 repositories. The two figures describe separate components of the corpus, not a single combined total.
Those numbers reflect a documented collection and filtering pipeline, not a raw search dump. The process produced 822,901 partition rows, then 575,633 distinct files after blob-URL deduplication, and finally 470,795 retained files after the documented filters. Exclusions included 97,757 package-cache files, 376 vendored-dependency files and 6,705 specs first committed before 2024.
Because large API searches can return short pages under rate limiting, the census used adaptive file-size partitioning and retries. The construction checks also tested idempotence and deterministic convergence, meaning that repeating the process should not keep changing the result. A manual review of 30 specs spanning 10 named tools found the tool attribution correct in every case.
A snapshot from a new period
The dates give the corpus a clear time stamp. SpecMine Version 1.0 is described as a July 2026 snapshot, and 99.7% of its specs were first committed in 2025 or later. Fully 92% were first committed in 2026. The result is a record concentrated in the recent emergence of these artifacts, rather than a long history of specification practice.
When specifications meet code
SpecMine then narrows its lens to changes made through pull requests. For 11 named tools, the pull-request layer screened repositories with at least 10 stars, covering 949 repositories and 963 repository-tool targets. It captured 5,992 spec-touching pull requests across 581 repositories. That layer is a selected sample, not a second census of every repository in the release.
Within that sample, 81.2% of spec-touching pull requests also modified code in the same reviewed changeset. The number is a useful sign that specifications and implementation files often appear together in a change, but the paper labels the measure a starting heuristic rather than ground truth. A same-change match still does not settle the larger question of how a specification becomes code.
Following the references
The release adds a broader form of traceability than co-change alone. Its census-wide index contains 2,421,323 typed references linking specifications to code and other repository artifacts. It also lists 266,230 OpenSpec change artifacts and 435,401 OpenSpec task-to-code references resolved against repository trees. Those records give future users a way to study named links into a project, not just files that happened to move together.
Each spec is enriched with its full commit history and 39 parsed structural features. That combination can show how a document changes over time and what its internal structure contains, while the reference fields connect it to the surrounding repository. The result is a dataset for inventory and traceability questions, not an answer about whether a particular specification was actually implemented.
What the numbers cannot say
The broad file count also carries a sampling warning. The filename census mixes serious projects with tutorials, template clones and one-off experiments. Only 923 of the 73,030 repositories have 100 stars or more. Because the pull-request layer used selected tools and a star screen, its 81.2% co-change figure should be read as describing that sample.
The artifacts come from public GitHub repositories collected under API terms, and 28,698 carry a recognized SPDX license. The document identifies itself as arXiv version 3 dated 1 Sep 2026, and the Version 1.0 release is described as having three tiers. Together, those details define a public research release, but the evidence remains descriptive: it maps artifacts and their links rather than showing that spec-driven development improves software, reviews or merges.
Paper data and sources
Original title: SPECMINE: A Large-Scale Corpus of Spec-Driven Development Artifacts
Authors: Shyam Agarwal, Bogdan Vasilescu
Journal/Repository: arXiv
Status: Preprint, not yet peer-reviewed
First online: 2026-08-25
DOI: Not available
Original paper · Full text