A Study of Cursorrules Files in GitHub Open Source Projects

A Study of Cursorrules Files in GitHub Open Source Projects Shuang Sun1 , Jafar Akhoundali1 , Arina Kudriavtseva1 , Sengim Karayalçin1 and Olga Gadyatskaya1 1 Leiden Institute of Advanced Computer Science, Leiden University, Einsteinweg 55, Leiden, The Netherlands

arXiv:2608.10622v1 [cs.SE] 11 Aug 2026

{s.sun, j.akhoundali, a.kudriavtseva, s.karayalcin, o.gadyatskaya}@liacs.leidenuniv.nl

Keywords:

Cursor, Cursorrules, Prompt Engineering, GitHub, Mining Software Repositories

Abstract:

Prompts are the primary mechanism for communicating with AI agents, and they directly influence the quality and reliability of AI-generated code. As AI-assisted programming becomes widely adopted, modern tools increasingly combine dynamic conversational prompts with static configuration-like prompt files. Despite the growing focus on prompt engineering, prior research has primarily focused on conversational prompts, while prompt files remain understudied. To address this gap, we conduct an empirical study of configuration prompt files in Cursor, a widely used AI-assisted code editor. We collect and analyze over 12,110 .cursorrules files from 11,427 GitHub repositories to characterize their distribution, evolution, and maintenance. Complementing this, we perform qualitative analysis on a random sample of 65 prompt files and develop a 65-code codebook capturing how developers express programming intent, project context, engineering practices, and security considerations. Our results show that .cursorrules files emerged rapidly from mid-2024. Their adoption is concentrated in small-scale, low-activity, single-maintainer repositories, suggesting toy projects rather than professional development. The content of prompt files is dominated by guidance on code quality and engineering practices, project structure and configuration, and maintainability, while security-related content appears less frequently. Our analysis shows that there is a continuity of themes and topics between the now-legacy .cursorrules files and the current standard .mdc files.

1

INTRODUCTION

AI-assisted programming has become ubiquitous. In the 2025 Stack Overflow’s annual survey (StackOverflow, 2025), 85% of surveyed professional developers reported they are using or are planning to use AI code assistants. These AI assistants are now an integral part of the software development infrastructure, becoming embedded in development environments and introducing artifacts such as prompts and AI service API calls in project files. The unprecedented speed of AI coding agents’ adoption calls for empirical research into the practices of AI assistants’ usage and their influence on software development processes. Specifically, research on prompts, the primary mechanism for communication with AI agents, is rapidly increasing. Prompts have a direct impact on the quality of AI-generated code (Della Porta et al., 2025; Nam et al., 2025; Khojah et al., 2025). It is thus important to study prompts used by practitioners as well as propose new techniques to improve prompts for achieving better performance on the target task, which is often referred to as prompt engineering. To get better output, modern AI agents and

AI-assisted programming tools often use a hybrid prompt strategy that combines dynamic conversational prompts with static prompt configuration files. Conversational prompts are short-lived instructions inside the ongoing conversation between the user and the AI agent. They influence the agent’s behavior and output within the current interaction. In contrast, static prompt configuration files are relatively stable instructions that operate continuously at a broader, project-level scope. They provide project context and shape agent behavior for all interactions within the given project, therefore, potentially achieving a deeper impact. While the engineering practices for conversational prompts have already received significant attention in the literature (Chen et al., 2025b; Ronanki et al., 2025; Sahoo et al., 2024; Chen et al., 2025a; Nam et al., 2025; Siddiq et al., 2024b; Siddiq et al., 2024a; Mao et al., 2025), the research on prompt configuration files is still limited. (Mohsenimofidi et al., 2025) and (Chatlatanagulchai et al., 2025) examined prompt files in open-source projects and analyzed their contents, focusing on AGENTS.md, a recent prompt configuration file format. However, these studies did not reveal how prompt configuration

You are an expert in TypeScript, Node.js, React, and Tailwind. Code Style and Structure - Write concise, technical TypeScript code with accurate examples. - Use functional and declarative programming patterns; avoid classes. Naming Conventions - Use PascalCase for directories and files (e.g., PixelViewer.tsx). - Favor named exports for components.

Figure 1: Example of a .cursorrules file.

files have been designed by developers in the wild, since the emergence of the AI coding assistants using such files. To better understand how such prompt configuration files have been used in practice, we examine the prompt-file ecosystem of Cursor, a widely used code editor built for AI-assisted programming (Cursor, 2025). In our work, we conduct both qualitative and quantitative analyses of the free-form .cursorrules files to investigate how prompt configuration files have been adopted by the practitioners, what topics they contain, in which open source projects they appear, and how they have evolved. We organize our investigation around four research questions. RQ1: What are .cursorrules files, and in which open source projects they appear? Here, we examine .cursorrules as files and study in what kind of projects they are located. • RQ1.1: What is the temporal dynamics of .cursorrules files creation in projects? • RQ1.2: How large are .cursorrules files and how did their size change over time? • RQ1.3: In which projects are .cursorrules files located? RQ2: What is the evolution of .cursorrules files? • RQ2.1: How are .cursorrules files updated? • RQ2.2: What are the characteristics and evolution of commit intervals for .cursorrules? • RQ2.3: How substantial are the modifications made to .cursorrules? • RQ2.4: Are .cursorrules files added or modified independently, and how do their creation and lastupdate times relate to repository lifecycles? RQ3: What are the major topics in .cursorrules? Knowing these, we can understand what developers are most concerned with when developing with Cursor. RQ4: Which security aspects are considered in .cursorrules? We examine how developers consider security issues and identify risky patterns.

Contributions. We collect a dataset of 12,110 .cursorrules files from 11,427 open-source GitHub repositories. Their analysis (RQ1&2) revealed that most .cursorrules files belong to Web application development projects; however, most of these projects are small, unpopular, and are maintained by a single contributor, indicating toy projects rather than large open-source systems. We also performed thematic analysis of 65 random Cursor prompt files, identifying the most common themes and topics that developers care about. This analysis (RQ3&4) shows that the themes and codes across the two considered file types are similar. Developers prioritize instructions about code quality and engineering practices, as well as project structure and configuration guidance, while security concerns do not receive substantial attention. Our empirical study contributes to a better understanding of the current AI coding assistants ecosystems.

2

BACKGROUND

At the time of writing, Cursor supports several types of prompt configuration files and refers to them as rule files or simply rules. These files are included at the start of the large language model (LLM) context, thereby establishing context persistence and providing consistent guidance across many LLM interaction sessions. Cursor works with four types of rules. Markdown-based project rules are stored in .cursor/rules. These files are scoped to the codebase using path patterns and can be versioncontrolled. They contain metadata specifying the rule application. User and Team rules are specific to the Cursor AI environment and a user group environment on enterprise plans, respectively. Finally, the fourth type is the universal format AGENTS.md (agents.md, 2025), which does not have Cursor-specific metadata, but supports interoperability with other AI agent ecosystems, as it also can be used with Claude, Copilot, Gemini, and others. However, previously, Cursor did not have so many rule types, and it used just one format: .cursorrules (Cursor AI, 2025). A representative example of .cursorrules is shown in Figure 1. These .cursorrules files were made legacy in February 2025, when Cursor announced that these files would eventually be deprecated, and the users are recommended to move to .cursor/rules or AGENTS.md. However, at the time of writing, they are still supported and persist around the ecosystem. Studying this earlier format and its emergence can help understand the evolution of prompt configuration

files: by examining .cursorrules content, we can see what developers care about and understand better the prompt file usage patterns. .cursorrules have free formatting; no specific metadata or structure is prescribed, and their content is entirely up to the developers. Given that Cursor has been available since 2023 and is widely used in development (Dalvi, 2025), we set out to study the legacy .cursorrules files to understand how they have appeared on GitHub and what they contain. Beyond AGENTS.md and .cursorrules, similar agent rule file patterns appear in other AI coding assistants, such as CLAUDE.md for Claude Code and copilot-instructions.md for Copilot, reflecting a broader ecosystem trend toward project-level prompt files that requires attention from researchers.

3

METHODOLOGY

To answer our RQs, we use a mixed-methods approach, which includes both quantitative and qualitative analyses. Our methodology, visualized in Figure 2, consists of three phases: (1) data collection, (2) quantitative analysis of the collected data as GitHub code artifacts (answering RQ1-RQ2), and (3) qualitative analysis of the data (answering RQ3-RQ4).

3.1

Data Collection

Our dataset. We used GitHub Code Search to identify Cursor rule files, querying .cursorrules filename (e.g., filename:.cursorrules). Because GitHub limits each query to 1,000 results, we iteratively added keywords to partition the search space. We collected data in April and October 2025 and merged the snapshots, keeping the most recent version of each file. In total, we obtained 12,110 unique .cursorrules files from 11,427 repositories, covering 15 April 2024 to 30 September 2025. Metadata collection. To examine the properties of the collected files and their repositories, we identified 76 data attributes (listed in our repository (Anonymous, 2026)) extracted from GitHub API responses. These attributes characterize a .cursorrules file in terms of the file itself, its creator, commit history, repository, and repository owner. Some attributes were incomplete due to GitHub’s access limits. For counts such as commits, releases, pull requests, and contributors, we used a threshold of 100 - the maximum returned per API request. If the true value does not exceed this limit, the crawler records it; otherwise, it returns 101. For repository attributes like README file, wiki,

discussion, and license, we do not request their contents; instead, we check their existence by requesting their fixed-format links and record their presence. We retrieve commits, pull requests, contributors, and releases via the GitHub GraphQL API, which exposes totalCount fields and reduces the number of API calls. File-level commit changes show which lines are added or removed and which sections are affected. To trace a file’s evolution, we identify all commits that modify the .cursorrules file and extract their diffs. Since diffs may include multiple files, we filter them to isolate only the changes to the target file.

3.2

Quantitative Analysis

We first conduct quantitative analyses on the collected dataset. These analyses focus on RQ1 and RQ2, and provide a multi-dimensional characterization of .cursorrules files and their hosting repositories. 3.2.1

RQ1: .cursorrules files and their open-source projects

To answer this RQ, we analyze .cursorrules file creation times (RQ1.1) and file size dynamics over time (RQ1.2). To characterize repositories containing .cursorrules files (RQ1.3), we examine GitHubreported language information and repository size, counting the occurrence of each language label across all repositories. We also analyze repository activity by measuring total commits, monthly commit frequency, and the number of unique contributors. 3.2.2

RQ2: Evolution of .cursorrules files

To measure whether .cursorrules files are modified and how frequently (RQ2.1), we analyze their maintenance activity by identifying the proportion of files with at least one post-creation commit and examining the distribution of subsequent commits. This quantifies how actively .cursorrules files are maintained. For RQ2.2, we define a commit interval as the time difference between consecutive commits to the same .cursorrules file. We include only files with at least two commits, extract and sort all commit timestamps, and compute pairwise time gaps. Intervals of zero seconds are excluded. To compare maintenance patterns across creation periods while avoiding observation bias, we use a fixed 30-day window after file creation and consider only intervals within this window. We analyze files created between April 2024 and August 31, 2025, ensuring each has a full 30-day observation period. For RQ2.3, we characterize .cursorrules modifications by analyzing commit statuses and the mag-

(2) Quantitative analysis

(1) Data collection

RQ1: .cursorrules files and hosting repositories

RQ1.1: Temporal creation dynamics RQ1.2: File size

RQ2.1: Update frequency

RQ2: .cursorrules evolution

RQ1.3 Hosting repository profiles

.cursorrules files and metadata collection

RQ2.2: Commit intervals characteristics RQ2.3: Modifications introduced RQ2.4: .cursorrules files updates in context

(3) Qualitative analysis RQ3: Main themes in.cursorrules files

RQ4: Security considerations in.cursorrules files

Figure 2: Our study methodology.

nitude of changes. We compute the proportion of each status (added, modified, renamed, and removed). We quantify modification extent by examining line changes in modified commits and computing a relative change ratio, defined as lines changed divided by total lines before the commit. For RQ2.4, we examine whether .cursorrules additions and modifications occur alone or with other files by counting co-changed files in each commit. We measure when developers add .cursorrules by comparing each file’s creation timestamp to that of its repository, and assess post-update repository activity by comparing the last commit timestamps of the file and repository. Files updated within thirty days of data collection were excluded to avoid rightcensoring bias.

3.3

Qualitative Analysis

3.3.1

Data Analysis

As manually analyzing all files was infeasible, we randomly selected 65 prompt files – 51 .cursorrules and 14 newer .mdc files. Each file serves as a self-contained artifact showing how developers guide Cursor’s AI-assisted programming behaviors. We performed thematic analysis of the sample following (Braun and Clarke, 2006), identifying recurring patterns of meaning and abstracting them into themes. This method suits our study well as it allows themes to emerge directly from developers’ expressions without predefined categories. We followed the approach used in similar software engineering studies (Ebert et al., 2022; Bernardo et al., 2024). Codebook construction. We conducted an open and descriptive coding, using inductive coding strategies (Saldaña, 2021). A single coder first coded 41 files, producing 136 distinct codes for semantic and functional concepts in the text. The coder then refined them for clarity and boundaries, yielding 101 codes. Coding was performed manually in Atlas.ti1 , 1 https://atlasti.com/

without using any AI-assisted features. Using this initial codebook, another author familiarized themselves with the data and independently coded the same five .cursorrules samples, yielding a Krippendorff’s Alpha of 0.674. After discussing disagreements and refining code definitions, we merged overlaps, removed redundancies, and added three codes. The codebook was updated to 65 codes. A second round of coding on five additional files increased Alpha to 0.897, confirming high consistency (Lombard et al., 2002). All authors agreed that the codebook had reached conceptual stability. With the refined codebook, the first coder re-coded 41 files and coded 10 new files. No new codes emerged, confirming theoretical saturation (Aldiabat and Le Navenec, 2018) for .cursorrules files. Cross-type coding. To validate the codebook across Cursor’s prompt-file ecosystem, we coded 14 .mdc files, whose frontmatter metadata (e.g., description, globs, scopes) led to a new code, Rule File Description, Scopes & Nested Structures. Some .mdc files contain examples for generating prompts or rules, giving rise to another new code, Prompt/Rule Example/Template. No further changes emerged, suggesting the codebook remained theoretically saturated across file types. Building the themes. We reviewed and grouped the codes into themes and iteratively refined them through author discussions to ensure coherence and adequate representation. Final themes and representative codes appear in Table 4.

4

RESULTS

In this section, we present the results of our empirical study on rule files in GitHub repositories. As our analyses rely on different metadata fields, the sample sizes vary slightly across analyses. For each analysis, we report the corresponding sample size.

Month

File size (bytes, log scale)

103 102 101

20 2024-0 2024-04 2024-05 2024-06 2024-07 2024-08 2024-19 2024-10 2024-11 2025-02 2025-01 2025-02 2025-03 2025-04 2025-05 2025-06 2025-07 25 8 -09

20 2 20 4-04 2 20 4-05 2 20 4-06 2 20 4-07 2 20 4-08 2 20 4-09 2 20 4-10 2 20 4-11 2 20 4-12 2 20 5-01 2 20 5-02 2 20 5-03 2 20 5-04 2 20 5-05 2 20 5-06 2 20 5-07 2 20 5-08 25 -09

0

104

-05

1000

105

23

Count

2000

2901 2593 2485 2114 2221 2344 1771 1666 1504 1197 1609 1012 1097 951 889 1143 1265 1241 738 900 823 783 510 4 4 6 8 118 668403 548 4 5 9 11 82 Commits Files Created

20

3000

Figure 3: Monthly counts of commits and .cursorrules file creations in open-source GitHub repositories.

RQ1: What are .cursorrules files and in which open source projects they appear

RQ1.1: .cursorrules files creation. Figure 3 shows the monthly distribution of file creations, together with the number of commits for comparison. The first .cursorrules file in our dataset was created on May 29, 2023, and has remained unchanged since then (this outlier is not shown in the figure). The second file appeared nearly a year later, on April 15, 2024. From Figure 3, we see that .cursorrules file creation begins in mid-2024, accelerates toward September 2024, and then stabilizes, with a noticeable decline in the summer of 2025. This decline can be explained by Cursor’s transition to a more fine-grained .cursor/rules files, with a general .cursorrules file being replaced by AGENTS.md.2 RQ1.2: Size of .cursorrules files. Across 12,085 sampled files in our dataset, the file sizes range from 11 bytes to 303.67 KB. The first quartile is 1.73 KB, the median is 3.26 KB, while the third quartile is 5.97 KB, indicating that most files are relatively small while a few are extremely large. The statistical data for each month are visualized in Figure 4. As shown in the figure, all five statistics become more stable from September 2024 onward, while they fluctuated considerably before that period, possibly indicating a gradual stabilization of file sizes over time. These trends suggest a narrowing range of file sizes and, possibly, more consistent file structures over time. RQ1.3: Projects with .cursorrules files. We identified 250 programming languages in repositories containing .cursorrules files. The top 20 languages account for 84.2% of occurrences, while the remaining 230 form a long tail of 15.8%. As shown in Figure 5, web development technologies account for more than half of the usage, with JavaScript (15.8%), CSS (13.7%), TypeScript (13.2%), and HTML (9.0%) collectively representing 51.7%. Over2 https://cursor.com/docs/context/rules

Figure 4: Monthly summary of .cursorrules file sizes.

Percentage (%)

4.1.1

max

15.8

16 14 12 10 8 6 4 2 0

15.8

13.713.2 9.0 7.0

6.3 4.5 1.7 1.5 1.3 1.2 1.1 1.1 1.1

1.0 1.0 0.9 0.9 0.9 0.9

cri pt Typ CS eS S cri p HT t ML Sh P ell Do ytho cke n Ma rfile k PL efile Po pgSQ we L r Ba Shell tch fil Ru e by Sw if SC t SS Go C+ + Vu e C PH P Jav Ot a he r

Quantitative Analysis Results

Jav aS

4.1

File Creation Time / Year-Month Q1 median Q3

min

Programming Languages

Figure 5: Programming language distribution across repositories containing .cursorrules files (in %). The “Others” category aggregates all languages outside the top 20.

all, .cursorrules files appear in a wide variety of project types. Repository sizes and scales also vary substantially. Most repositories are relatively small, with 75.0% of them under 11 MB, while the maximum reaches 8.76 GB. The number of files per repository ranges from 1 to 69880. The distribution of both sizes and scales has a strongly right-skewed distribution driven by a small number of huge, large-scale repositories. This result shows that .cursorrules files are used across projects of various sizes and scales, but predominantly in relatively small repositories. We remark that these results might be affected by the fact that we only analyze open-source, public repositories. The distribution of commit counts shows a median of 29 commits, whereas the mean of 213.7 is inflated by a small number of highly active repositories. Activity tiers show 62.5% repositories contain 50 or fewer commits, 30.3% have 51-500, and only 7.2% exceed 500. To analyze maintainer structures, we compute proportions of single-maintainer, teammaintained, and large-team repositories. Of 11,427 repositories, 68.5% are maintained by a single contributor, while 31.5% involve multiple maintainers. Only 3.4% repositories involve large teams with more than ten contributors. Overall, most repositories are small-scale and managed by one or a few individuals. RQ1 Takeaway: .cursorrules files scale up from mid-2024, appearing primarily in web-oriented

Table 1: Commit-interval statistics by modification count. Min (s)

Median (d)

Avg (d)

Max (d)

1 2 3 4 >4

4 6 4 17 1

2.20 1.22 0.98 0.96 0.74

22.45 13.35 8.88 8.71 5.23

315.81 359.01 260.10 279.60 223.51

repositories (51.7%), which are typically small, lowactivity, single-maintainer projects, despite a long tail of large and popular repositories.

24.1% 10.2% 10.8%

0 0-1

50 11-

3.9%

0.5% 0.1% 0 0 0 0 0 0 -3 200 200 10 51 101 301- 1001- > Lines Changed

0 -10

Figure 6: Distribution of the number of lines changed per modified commit.

RQ2: What is the evolution of .cursorrules files?

100 Share of commits (%)

RQ2.1: .cursorrules file updates. Among all collected .cursorrules files, 67.3% were never changed after creation, while 32.7% were modified at least once. Most modified files were changed only once (16.1%), while a smaller proportion (5.1%) had more than four updates. As shown in Figure 3, the number of commits involving .cursorrules files increased markedly over time. From only a few commits per month in mid2024, activity rose steadily, surpassing 2,000 commits per month in January 2025 and peaking at over 2,900 in June 2025. Thus, the usage of .cursorrules files is rising steadily over time. The number of distinct contributors per file exhibits a strong skew. Most .cursorrules files (95.8%) were handled by a single contributor. Files with two contributors account for 3.9%, while those with three or more contributors represent only 0.3% combined. Compared with the relatively lower incidence of single-maintainer repositories in our dataset, this indicates that .cursorrules files are typically managed individually. RQ2.2: Commit intervals Table 1 summarizes commit interval statistics grouped by modification count. Files edited only once show a median interval of 2.20 days, while those modified more than four times have a median of 0.74 days. The mean interval follows a similar trend, decreasing from 22.45 days for single-modification files to 5.23 days for the most frequently updated group. This shows that files receiving more modifications are updated more regularly and with shorter delays between commits. We also examined temporal trends. The median interval decreased from 189.4 hours in June 2024 to 16.0 hours in December 2024 and then stabilized between 13 and 19 hours from January 2025 onward. The overall mean interval (71.0 hours) stayed much higher than the median (18.7 hours), indicating that once a .cursorrules file is updated, it is usually updated frequently. RQ2.3: Size of modifications. The commit sta-

5000 4000 3000 2000 1000 0

80 60 40 20 0

20 2 20 4-04 2 20 4-05 2 20 4-06 2 20 4-07 2 20 4-08 2 20 4-09 2 20 4-10 2 20 4-11 2 20 4-12 2 20 5-01 2 20 5-02 2 20 5-03 2 20 5-04 2 20 5-05 2 20 5-06 2 20 5-07 2 20 5-08 25 -09

4.1.2

50.4% Number of Commits

Group

File Creation Month

0 0.1 0.1 0.2

0.2 0.3 0.3 0.4

0.4 0.5 0.5 0.6

0.6 0.7 0.7 0.8

0.8 0.9 0.9 1.0

>=1.0

Figure 7: Monthly distribution of .cursorrules commits by relative change ratio. Each color interval represents a ratio range.

tus distribution shows that most updates were new file additions or modifications to existing ones, with few deletions or renames.Specifically, 50.2% of commits are added and 48.0% modified, while only a small fraction are renamed (1.4%) or removed (0.5%). Figure 6 illustrates the distribution of the number of lines changed in modified commits. Over 50.4% of all commits changed fewer than 10 lines, and 74.5% changed fewer than 50 lines. Only 0.6% of commits modified more than 1,000 lines. Therefore, most updated to .cursorrules are minor. We further examined how the number of changed lines compares to the total size of each file. As shown in Figure 7, most commits involved small proportional changes, typically under 10%. Large changes (ratio > 1.0), where the modified lines exceeded the file’s prior size, became less common from 2024 to 2025. Overall, the share of high-ratio modifications declined, especially in the ≥100% category, indicating a shift toward more incremental updates. RQ2.4: Relationship with the repository lifecycle. As shown in Table 2, when .cursorrules files were added, 60.7% of the commits affected more than ten files, only 14.9% added .cursorrules independently. This suggests that many .cursorrules additions occur as part of batch operations. Similarly, when .cursorrules are modified, 19.4% of com-

added modified

1

2-10

>10

472 (14.9%) 566 (19.4%)

773 (24.4%) 1194 (40.8%)

1926 (60.7%) 1163 (39.8%)

Table 3: Delay between .cursorrules creation and repository initialization. Time Interval

# Files

Percentage

0<∆t≤24 hours 24h<∆t≤7 days 7<∆t≤30 days ∆t>30 days

3856 1414 1210 3001

40.7% 14.9% 12.8% 31.7%

mits changed only the .cursorrules file, and 60.2% modified at most 10 files. We next analyzed the delay between repository creation and .cursorrules creation. As shown in Table 3, about 40.7% of .cursorrules files were added within the first 24 hours after repository creation, while 31.7% were introduced more than 30 days later. To investigate immediate additions in more detail, we analyzed the first three hours after repository creation in five-minute intervals. The result shows that 63.4% of those files created within three hours are added within the first 20 minutes, and 82.8% are added within the first two hours. This indicates that when developers add .cursorrules immediately after creating a repository, they typically do so within minutes rather than hours. We also examined monthly trends of ∆t. Figure 8 reports monthly shares of creation timing categories from April 2024 through September 2025. The share of files created more than 30 days after repository initialization decreased substantially over this period, while the share created shortly after repository initialization increased. This shift suggests growing developer awareness or adoption of .cursorrules during repository setup over time. Finally, comparing file last-update times with repository last-update times shows that most repositories remain active after a .cursorrules update. Among 11,780 files, 2.6% of repositories had no updates after the file’s last change, indicating that the file was the final recorded modification. A majority of repositories, 54.2%, received further updates within 30 days of the .cursorrules update, and 43.3% remained active for more than 30 days after the update. These figures indicate that .cursorrules updates commonly occur within active projects and are often part of continued development. RQ2 Takeaway: .cursorrules files are often left unchanged after creation (67.3%), and most updates to them are small. They tend to be added in

1.0 0.8 68% 0.6 98% 96% 99% 96% 0.4 0.2 0.0

75%

50% 25% 50%

20 24 20 -04 24 20 -05 24 20 -06 24 20 -07 24 20 -08 24 20 -09 24 20 -10 24 20 -11 24 20 -12 25 20 -01 25 20 -02 25 20 -03 25 20 -04 25 20 -05 25 20 -06 25 20 -07 25 20 -08 25 -09

Commit Type

Proportion

Table 2: Distribution of file counts in commits involving .cursorrules files.

month

0 < t 3h

3 < t 24h

t category 24h < t 7d

7d < t 30d

t > 30d

Figure 8: Monthly trend of creation-timing categories (∆t) for .cursorrules April 2024 - September 2025.

batch commits, while subsequent modifications are more localized and involve fewer other files. Commit activity has risen steadily since mid-2024.

4.2

Qualitative Analysis Results

4.2.1

RQ3: What are the major topics in .cursorrules?

Theme Code Quality and Engineering Practices accounts for the largest share at 30.4%. Typical guidance in this theme instructs Cursor about tooling, performance considerations, coding style, naming conventions, and general best practices. For example, “Write clean, simple, readable code and follow the project’s naming conventions.” The member code Coding Example/Template captures cases where developers provide examples or templates to help Cursor better understand the programming requirements and generate more appropriate code. In the sampled .cursorrules files, these examples are typically single positive demonstrations. In contrast, several .mdc files begin to include paired examples, a correct version alongside a wrong one, providing both positive and negative guidance to more explicitly shape Cursor’s behavior. For example, “Correct Example (GitHub compatible): ..., Incorrect Example (GitHub incompatible due to icons): ...”. Themes and representative codes are presented in Table 4, with the full codebook and top 10 codes in both .cursorrules and .mdc files are available in (Anonymous, 2026). Project Structure and Configuration at 18.3% is the second-largest theme, reflecting that developers commonly specify languages, stacks, and directory layout. For example, “This project uses FastAPI for the backend and Python 3.11, organizes modules under the services directory.” Beyond these general patterns, the member code Project Context & Explanation shows an additional trend in the sampled .mdc files tend to provide more explanatory information. For example, “This project runs on a vite-based node server ... This means that ... the server will

Table 4: Themes and Representative Codes Theme

Representative Codes

Access Control

Access Control Authentication & Authorization Token Handling Role-Based Access Control Agent Behaviors and Rule Files Exclusion Behaviors Structure Cursor Role Definition Rule File Description, Scopes & Nested Structures Project Structure and Configura- Languages, Stacks & Usage Guidance tion Project Structure & Architecture Project Context & Explanation Project & Environment Configuration Build, Deployment, and CI/CD CI/CD Deployment & Release Management System Input, Data Flow, and Database Design & Operations System State Validation & Sanitize Guidance State Mangement & Consistency Data Fetching

already be running and you don’t need to re-run it. This also means that you will avoid at all costs to automatically create new live server ...” Additionally, several .mdc files offer specific guidance related to path-related behaviors. For example, “All file paths must be relative or use full URL imports”. Agent Behavior & Rule Files Structure at 14.1% is the third largest theme, which regulates behaviors of Cursor rather than the code output, e.g., rules for what to do, how to do it, in what role, and within what contextual assumptions. Member codes Rule File Description, Scopes & Nested Structures and Prompt/Rule Example/Template newly emerge in the sampled .mdc files, results in a slightly higher proportion of this theme in .mdc files (18.4%) compare to .cursorrules files(13.0%). Content from the theme Security is less frequent at 4.2%. This includes both security design considerations and what we identified as potential security smells. However, the code Security Awareness, Mechanisms & Practices shows a clear difference between sampled .cursorrules and .mdc files. In .cursorrules files, it is the ninth most frequent code at 3.0%, whereas in .mdc files it drops to 0.6% and ranks 41st. This difference may be partly due to their different scopes: .cursorrules files are unrestricted, while each .mdc file has a defined scope. The sampled .mdc files may simply not be securityrelated, which could contribute to the lower frequency of security content. Other themes emerged with lower prevalence, but they remain noteworthy. The Access Control theme describes rules that integrate identity, permissions, and resource boundaries directly into the project. Common instructions like “Implement proper authentication and authorization”, “Use proper token permissions”, and “Validate user permissions before any operation” focus on authentication and authorization mechanisms. Developers also describe how access

Theme

Representative Codes

Architecture and Integration

Dependency Management & Injection HTTP Architecture Modular Architecture & Scalability Routing Code Quality and Engineering Coding Example/Template Practices Best Practices Coding Style Code Review Maintainability and Evolution Code Readability & Maintainability Comment Reusability System Currency & Iteration Security Security Awareness, Mechanisms & Practices Security Smells Testing and Error Handling Error & Exception Handling Testing Logging & Monitoring/Tracking Debugging & Troubleshooting

control should be implemented in different environments. For example, for Laravel, “use built-in features like Sanctum, Policies, and authentication scaffolding”. Build, Deployment, and CI/CD emphasizes following official documentation and best practices for frameworks, libraries, and deployment tools (React, Next.js, Vue.js, FastAPI, Vercel AI SDK, PyTorch, Transformers, etc.). Instructions enforce standardized workflows, CI/CD (GitHub Actions, ArgoCD), containerization (Docker, Knative), build/test commands, and file handling. System Input, Data Flow, and System State focuses on safe, efficient, and reliable data and state management. Key points that developers mention include input validation, secure handling of sensitive data, proper database transactions and caching, structured state management, and systematic file and data pipeline handling to ensure integrity and performance. For example, Pydantic should validate inputs, transactions should be handled atomically, caching should be used for speed, etc. Architecture and Integration describes modular, scalable, and maintainable architectures with clear separation of concerns, and reusable components. Key ideas developers mention include dependency management, API versioning, repository patterns, event/listener decoupling, dynamic routing, and consistent route organization. Integration guidance covers combining frontend and backend components, managing shared state, middleware, data pipelines, and handling dependencies securely and up to date. Maintainability and Evolution focuses on code readability and clear documentation. Code should be readable, self-documenting, and concise, with descriptive names, early returns, and minimal duplication. Projects should be structured into small, focused files with reusable components, logical organization, and separation of configuration, and robust version

Table 5: Theme-level distribution of coded instances and average frequency per code. Theme

Share (%)

Avg./code

Code Quality and Engineering Practices Project Structure and Configuration Maintainability and Evolution Cursor Behaviors and Role Context System Input, Data Flow and State Management Testing and Error Handling Architecture and Integration Security Build, Deployment, and CI/CD Access Control

30.4% 18.3% 14.4% 8.2% 7.3% 6.0% 5.8% 4.2% 2.8% 1.0%

2.51% 3.36% 1.44% 1.63% 0.67% 1.00% 1.44% 1.80% 0.69% 0.14%

control practices should be used. Testing and Error Handling includes prioritizing early error detection using guard clauses and early returns, implementing proper exception handling with clear and user-friendly messages, creating custom error types when needed, and logging errors for debugging and monitoring. It also includes testing strategies such as unit, integration, and end-to-end tests, proper async testing, test-driven development where appropriate, high coverage on critical paths, and the use of tools like PHPUnit, Laravel Dusk, Jest, Playwright, or go test to ensure reliability and maintainability. In terms of specific codes, Languages, Stacks and Usage Guidance is the most frequent code in both .cursorrules and .mdc files, which instruct the coding assistant on the specific languages and stacks to use and which persona to adopt, e.g., instructing it to act as “FastAPI backend developer with deep knowledge of Python 3.11” or “Expert in TypeScript, Node.js and React.” Exclusion Behaviors is also common, shaping Cursor’s behavior through negative constraints such as forbidden actions or behaviors to avoid. These rules direct Cursor to generate more compliant output. For example, “DO NOT write complicated and confusing code”. Coding Example/Template shows over 3 times higher proportion in .mdc (6.8%) than in .cursorrules files (1.9%). Given that the sampled .mdc files also introduce paired examples, this difference may suggest that their coding examples are both more developed and more frequent than those in the sampled .cursorrules files. RQ3 Takeaway: Code quality and engineering practices dominate the sampled rule files (30.4%), with Language, Stacks & Usage Guidance as the most frequent individual code. Coding examples differ by format, with .mdc files containing more frequent examples and introducing paired ones. 4.2.2

RQ4: Which security aspects are considered in .cursorrules?

We use the code Security Awareness, Mechanisms & Practices to capture explicit best practices, experience, and awareness expressed in rule files. This

content appears with multiple security aspects, but it is relatively infrequent, accounting for roughly 2.5% across all sampled rule files (including .mdc). Specifically, when security is discussed, developers typically mention: (1) security mechanisms and defensive techniques, such as “Implement proper CSRF protection and security measures”, “Use Laravel’s prepared statements to prevent SQL injection”, or “Follow the Checks-Effects-Interactions pattern to prevent reentrancy and other vulnerabilities”. (2) input validation and sanitization, such as “validate all input data” or “sanitize all incoming data to prevent injection attacks”; (3) secure data handling and storage was also mentioned, such as “Use Expo’s secure store for sensitive data”; (4) general awareness or meta-level reminders without concrete action, such as “Security best practices are followed”, or “Security concerns”. Apart from this code, the theme Access Control also captures security-related content and accounts for 1.9% across the sampled rule files. This theme consists of 7 member codes (e.g., Authentication & Authorization, Role-Based Access Control), all focusing on the design and implementation of access control mechanisms, i.e., who can access what resources under what conditions. Together with Security Awareness, Mechanisms & Practices, the combined proportion reaches roughly 4.4%, which suggests that developers are sometimes aware of security needs, but overall treat security considerations only occasionally. In addition to explicit security guidance, we also identified security smells in the files. These smells are not direct vulnerabilities but patterns that may indicate risky practices or unintended exposure of internal information. They include exposed local paths, hardcoded parameters that may represent secrets, links to internal or private resources, and inconsistent or contradictory instructions that could lead to insecure code generation. Such smells are relatively rare, about 1.5% of all coded instances, but they are present and indicate that instructions in rule files may unintentionally introduce security risks. Representative security smell examples are: (1) Information Exposure Smell. Potential disclosure of internal file paths, configuration details, or system metadata. Examples include exposed local paths (“/Users/md/Dropbox/dev/.../BTC-USD15m.csv”) or internal metadata (“betas=[output128k-2025-02-19]”). (2) Hard-coded Sensitive Parameter Smell. Secrets or internal parameters that are embedded directly in rule files. For example, “‘budget tokens’ :’120790’”; hard-coded default values used as secrets,

such as “‘SECRET KEY‘: Used for signing JWT tokens. Defaults to ‘banana’ if not provided”. (3) Internal Resource Exposure Smell. Internal or private resources that are exposed, revealing system structure or internal tooling. For instance, private workspace URLs such as “https://www.notion.so/... backend ...450db1a?pvs=21”. (4) Inconsistency Smell. Contradictory or duplicated instructions. For example, one .cursorrules instructs Cursor:“Use camelCase for component names (e.g., AuthWizard [sic])”, and later: “Use PascalCase for component names (e.g., AuthWizard)”. The presence of these smells has practical consequences. Exposed paths can reveal project structure or private data, hard-coded parameters may encourage insecure handling of sensitive values, and internal resource links can leak information about internal documentation or system organization. Conflicting instructions introduce uncertainty into the Cursor’s behavior and increase the likelihood of unpredictable or inconsistent code generation, which is itself a security concern. RQ4 Takeaway: Security-related guidance appears infrequently in .cursorrules files, accounting for about 4.4% of all coded instances. Potential security smells are also present but rare (1.5%).

5

DISCUSSION

Analysis of findings. Our mixed-methods analysis shows that .cursorrules files in open-source GitHub projects mostly occur in small, unpopular, single-maintainer projects that are not actively maintained. Many of these projects were likely used for testing the Cursor AI or educational purposes (i.e., toy projects). A smaller fraction of the files occurs in popular and large repositories, indicating that these are active open-source projects strongly engaging with Cursor. Over time, .cursorrules files have become slightly better maintained, with shorter update cycles and more localized modifications. Since this format was declared legacy in February 2025, we expect these files to become rarer, being replaced by more current prompt configuration formats. Our qualitative content analysis shows that the themes and topics that organically emerged in .cursorrules files also occur in the more recent .mdc files, and there is a topical continuity between the formats. Therefore, we believe that our qualitative analysis is also relevant for these more recent files. The qualitative analysis results by (Mohsenimofidi et al., 2025) and (Chatlatanagulchai et al., 2025), which investigated AGENTS.md and other markdown-

based files for AI agents, also reveal similar patterns: a larger focus on architecture and project structure with relatively lesser focus on issues like security. Threats to validity. Quantitative Research. Our quantitative analysis and its external validity are limited by the constraints of interacting with GitHub repositories. Because the GitHub API does not return complete results (Akhoundali et al., 2025) and our search strategy had to partition the query space to bypass the 1,000-result limit, some .cursorrules files may not have been retrieved. In addition, the dataset combines two snapshots (April and October 2025). Although this increases coverage, it also introduces some uncertainty when interpreting temporal trends. Also, our analysis focuses exclusively on public repositories, while private projects may have different patterns and behaviors. Regarding construct validity, we introduce a composite indicator of repository completeness and maturity. While its elements are commonly associated with well-documented and community-oriented projects, it should still only be interpreted as a coarse structural indicator. Finally, repository-level attributes are capped, so activity in highly active repositories is only lower-bounded. Qualitative Research. The key limitation of the qualitative study is our small sample size (65), which is not a representative sample of the whole dataset. This restricts the breadth of phenomena that can be observed and the representativeness of the resulting themes. While we observed coding stabilization on our sample, analyzing more files could potentially reveal new codes and themes. Second, although the coding and theme construction followed the standards of thematic analysis, the resulting codebook and themes inevitably reflect the authors’ interpretations. These factors should be taken into account when interpreting the qualitative results. As is common in thematic analysis, its findings cannot be interpreted as generalizable to the whole population.

6

RELATED WORK

LLMs are being applied to various software development tasks (Dong et al., 2025; Sergeyuk et al., 2026). Prompts can influence the quality of the produced code (Della Porta et al., 2025; Nam et al., 2025), and the recent literature actively investigates how to design effective prompts. Prompt engineering refers to various prompt improvement techniques and methodologies that enhance LLM performance in the relevant areas and tasks (Chen et al., 2025b; Liang et al., 2025; Ronanki et al., 2025; Sahoo et al., 2024).

Mining software repositories and analysis of open source projects is a very active research area (de F. Farias et al., 2016). Closest to our work, several studies have examined prompts in the context of software repositories and development practices. Prompt collections analysis. (Siddiq et al., 2024a) qualitatively examined prompts in 9 code generation benchmarks for writing quality issues. (Li et al., 2025a) analyzed 92 GitHub prompt repositories, quantitatively studying prompt sources, prompt storage practices, and prompt quality in terms of length, grammar, and readability. Prompts for specific development tasks. (Tafreshipour et al., 2025) inspected the evolution of prompts from the PromptSet dataset (Pister et al., 2024). (Tafreshipour et al., 2025) reports that prompt changes are usually limited to specific elements and are mostly introduced during feature development, and they are frequently not documented in the commit messages. (Rzig et al., 2025) report that PromptSet prompts frequently suffer from bias, vulnerability to injection attacks, and suboptimal performance. (Mao et al., 2025) analyzed the PromptSet prompts and constructed a dataset of prompt templates from open source LLM apps. Considering actual prompt usage by developers, (Desmond and Brachman, 2024) and (Nam et al., 2025) qualitatively examined prompt editing behavior in an enterprise. (Zhong et al., 2025) characterized developers’ interactions with ChatGPT, studying the most common tasks, programming languages, and the session structure, while (Siddiq et al., 2024b) have shown that ChatGPT frequently produced low-quality code in these interactions. Prompt configuration files analysis. Closest to our study, (Mohsenimofidi et al., 2025) investigated the usage of AI configuration files in more mature open-source repositories, showing that only 5% of repositories in their original sample contained such files. They identified 116 repositories containing AGENTS.md files and analyzed these files regarding the included headers, writing style, and the changes introduced to these files. Compared to our study, we examine a larger sample of .cursorrules quantitatively, and we do not restrict ourselves to more established software projects, while our qualitative analysis did not start with any preconceived file structure as organized in the headers. (Chatlatanagulchai et al., 2025) further extend (Mohsenimofidi et al., 2025) by collecting and analyzing CLAUDE.md, AGENTS.md, and copilot-instructions.md from projects shared in the AIDev dataset (Li et al., 2025b). They found that these files evolve via frequent, small additions, and that, among the 16 available instruction types, developers prioritize functional context, while

non-functional requirements like security and performance rarely receive attention. In our study, we observed that developers relatively frequently mention non-functional requirements such as code quality and maintainability, whereas security-related concerns receive comparatively little attention. The key novelty of our study is that we investigated .cursorrules, a once-standard free-format prompt configuration files for Cursor. Our analysis reveals the emergence and usage of these files in open-source software projects.

7

CONCLUSION

In this work, we have empirically investigated the .cursorrules files in open-source GitHub repositories. In our mixed-methods study, we identified the behavior and properties of .cursorrules files as part of open-source repositories, as well as the common themes and topics that developers mention in these prompt configuration files. Future research can build on our thematic analysis to perform a larger-scale study using LLMs to code all files in our dataset, as well as to extend the analysis to other prompt configuration file types.

REFERENCES agents.md (2025). GitHub - agentsmd/agents.md: AGENTS.md — a simple, open format for guiding coding agents — github.com. https://github.com/ agentsmd/agents.md. [Accessed 22-Jan-2026]. Akhoundali, J., Hamidi, H., Rietveld, K., and Gadyatskaya, O. (2025). Eradicating the unseen: Detecting, exploiting, and remediating a path traversal vulnerability across GitHub. In Proceedings of AsiaCCS, pages 542–558. Aldiabat, K. M. and Le Navenec, C.-L. (2018). Data saturation: The mysterious step in grounded theory methodology. The qualitative report, 23(1):245–261. Anonymous (2026). Anonymous Github — anonymous.4open.science. https://anonymous.4open. science/r/cursorrules/. Bernardo, J. H., Da Costa, D. A., Medeiros, S. Q. d., and Kulesza, U. (2024). How do machine learning projects use continuous integration practices? An empirical study on GitHub actions. In Proceedings of MSR, pages 665–676. Braun, V. and Clarke, V. (2006). Using thematic analysis in psychology. Qual. Res. Psychol., 3(2):77–101. Chatlatanagulchai, W., Li, H., Kashiwa, Y., Reid, B., Thonglek, K., Leelaprute, P., Rungsawang, A., Manaskasemsak, B., Adams, B., Hassan, A. E., et al. (2025). Agent READMEs: An empirical study of context files for agentic coding. arXiv preprint arXiv:2511.12884.

Chen, B., Zhang, Z., Langrené, N., and Zhu, S. (2025a). Unleashing the potential of prompt engineering for large language models. Patterns. Chen, Z., Wang, C., Sun, W., Yang, G., Liu, X., Zhang, J. M., and Liu, Y. (2025b). Promptware engineering: Software engineering for LLM prompt development. arXiv preprint arXiv:2503.02400. Cursor (2025). Cursor Docs — cursor.com. https://cursor. com/docs. [Accessed 22-Jan-2026]. Cursor AI (2025). Rules — Cursor Docs — cursor.com. https://cursor.com/docs/context/rules. [Accessed 22Jan-2026]. Dalvi, R. (2025). Cursor AI adoption trends: Real data from the fastest growing coding tool. https://opsera.ai/blog/cursor-ai-adoption-trendsreal-data-from-the-fastest-growing-coding-tool/. [Accessed on 22-Jan-2026]. de F. Farias, M. A., Novais, R., Júnior, M. C., da Silva Carvalho, L. P., Mendonça, M., and Spı́nola, R. O. (2016). A systematic mapping study on mining software repositories. In Proc. of SAC, pages 1472–1479. Della Porta, A., Lambiase, S., and Palomba, F. (2025). Do prompt patterns affect code quality? A first empirical assessment of ChatGPT-generated code. In Proc. of EASE, pages 181–192. Desmond, M. and Brachman, M. (2024). Exploring prompt engineering practices in the enterprise. arXiv preprint arXiv:2403.08950. Dong, Y., Jiang, X., Qian, J., Wang, T., Zhang, K., Jin, Z., and Li, G. (2025). A survey on code generation with LLM-based agents. arXiv preprint arXiv:2508.00083. Ebert, V., Graziotin, D., and Wagner, S. (2022). How are communication channels on GitHub presented to their intended audience? – A thematic analysis. In Proc. of EASE, pages 40–49. Khojah, R., de Oliveira Neto, F. G., Mohamad, M., and Leitner, P. (2025). The impact of prompt programming on function-level code generation. IEEE Transactions on Software Engineering. Li, H., Masri, H., Cogo, F. R., Bangash, A. A., Adams, B., and Hassan, A. E. (2025a). Understanding prompt management in GitHub repositories: A call for best practices. IEEE Software. Li, H., Zhang, H., and Hassan, A. E. (2025b). The rise of AI teammates in software engineering (SE) 3.0: How autonomous coding agents are reshaping software engineering. arXiv preprint arXiv:2507.15003. Liang, J. T., Lin, M., Rao, N., and Myers, B. A. (2025). Prompts are programs too! Understanding how developers build software containing prompts. Proceedings of the ACM on Software Engineering, 2(FSE):1591– 1614. Lombard, M., Snyder-Duch, J., and Bracken, C. C. (2002). Content analysis in mass communication: Assessment and reporting of intercoder reliability. Human communication research, 28(4):587–604. Mao, Y., He, J., and Chen, C. (2025). From prompts to templates: A systematic prompt template analysis for real-world LLMapps. In Proceedings of FSE, pages 75–86.

Mohsenimofidi, S., Galster, M., Treude, C., and Baltes, S. (2025). Context engineering for AI agents in opensource software. arXiv preprint arXiv:2510.21413. Nam, D., Omran, A., Murillo, A., Thakur, S., Araujo, A., Blistein, M., Frömmgen, A., Hellendoorn, V., and Chandra, S. (2025). Understanding and supporting how developers prompt for LLM-powered code editing in practice. Pister, K., Paul, D. J., Joshi, I., and Brophy, P. (2024). PromptSet: A programmer’s prompting dataset. In Proc. of LLM4Code, pages 62–69. Ronanki, K., Arvidsson, S., and Axell, J. (2025). Prompt engineering guidelines for using large language models in requirements engineering. In Euromicro Conf. on Soft. Eng. and Adv. Applications, pages 245–262. Springer. Rzig, D. E., Paul, D. J., Pister, K., Henkel, J., and Hassan, F. (2025). Developer prompts in practice: An empirical study of bias, security, and optimization. In Proceedings of ESEM. Sahoo, P., Singh, A. K., Saha, S., Jain, V., Mondal, S., and Chadha, A. (2024). A systematic survey of prompt engineering in large language models: Techniques and applications. arXiv preprint arXiv:2402.07927. Saldaña, J. (2021). The coding manual for qualitative researchers. Sergeyuk, A., Zakharov, I., Koshchenko, E., and Izadi, M. (2026). Human-AI experience in integrated development environments: A systematic literature review. Empirical Software Engineering, 31(3):55. Siddiq, M. L., Dristi, S., Saha, J., and Santos, J. C. (2024a). The fault in our stars: Quality assessment of code generation benchmarks. In Proceedings of SCAM, pages 201–212. IEEE. Siddiq, M. L., Roney, L., Zhang, J., and Santos, J. C. D. S. (2024b). Quality assessment of ChatGPT-generated code and their use by developers. In Proc. of MSR, pages 152–156. StackOverflow (2025). The 2025 Developer Survey. https:// survey.stackoverflow.co/2025/. [Accessed on 22-Jan2026]. Tafreshipour, M., Imani, A., Huang, E., de Almeida, E. S., Zimmermann, T., and Ahmed, I. (2025). Prompting in the wild: An empirical study of prompt evolution in software repositories. In Proc. of MSR, pages 686– 698. IEEE. Zhong, S., Zou, Y., and Adams, B. (2025). DeveloperLLM conversations: An empirical study of interactions and generated code quality. arXiv preprint arXiv:2509.10402.

Related documents

• What's Inside a GitHub Repository? An Empirical Study on the Contents of 10K Projects#200580
• Growth#1179746
• A Low-Cost Human-in-the-Loop Investigation of Toxicity on GitHub at Scale#411122
• Deforking the World of Code: A Project-Provenance Map that Recovers Cross-Forge Fork Families that Platform Graphs Cannot See#321906
• Social Popularity of GitHub Projects: A Lifeline or a Liability?#329166