# The Committed-File Stack Signal Reference: What Each Repo File Proves

*Look up any file in a prospect's public repos and state what it proves about their stack, how it lies, the check that confirms it, and when to recheck it.*

- Canonical URL: https://www.refolk.ai/guides/committed-file-stack-signal-reference
- Pillar: Sales and go-to-market
- Format: Reference
- Published: 2026-10-26
- Last reviewed: 2026-10-26
- Reading time: 22 min
- Keywords: find companies using a library on GitHub, GitHub signals for developer tool sales, search GitHub workflows for companies using an action, technographic data from public repositories, is a dependency in package.json proof of usage, GitHub dependents list accuracy for prospecting

## Key takeaways

- A committed file earns a CRM tech-stack entry only when at least two evidence layers agree, and at least one of them is a build or deploy file such as a CI workflow or an IaC provider block.
- In Bifolco et al.'s study, GitHub's dependency graph matched only 75.17% of Java dependencies and 84.48% of Python dependencies, so read the raw manifest or lockfile, not the graph.
- GitHub now defaults the dependency graph to off for newly created public repos, so a dependents count tracks which repos opted in, not who adopted the package, and a company missing from it proves nothing.
- GitHub code search covers only the default branch and files under 384 KB, returns at most 1,000 results, and skips forks unless they have more stars than their parent, so you cannot sweep forks completely.
- In Refolk's index, 441 US Platform Engineers list Terraform and only 6 list Pulumi, a 73.5x gap, so for rarely tagged tools committed files like Pulumi.yaml carry most of the evidence.
- Stars and forks prove nothing about what an account runs, and the point scores ranking pages give them have no published method behind them.

This reference is for founders, account executives, SDR leads, and partnerships teams who have found a prospect's public GitHub org and need to know which committed files prove the account runs the stack they sell into. Each file type gets one entry: what it proves, how it lies, the check that confirms it, and how long it stays usable as evidence. The goal is a CRM tech-stack field filled from evidence instead of a keyword hit.

## How strong is each committed file as proof of stack?

Files that build or deploy something are the strongest proof that an account runs a tool. That means IaC provider blocks, CI workflows, and lockfiles. Files that only declare a need are medium or weak evidence, and stars and forks prove nothing about what an account runs. A committed file is anything stored in a repo's history. Activity such as a star, a fork, or an issue is not a committed file.

I grade every file on four levels:

- **Strong:** the file sits in the build or deploy path, so someone ships with it. It can anchor a tech-stack field once a second layer agrees.
- **Medium:** the file shows the tool was declared, installed, or called. It needs a build or deploy file next to it.
- **Weak:** the file names the tool but proves no use. It needs two other layers before it counts.
- **None:** it never goes in a tech-stack field, however many of them there are.

A file's grade depends on its layer. The further a file sits from what actually runs, the more ways it can lie.

#### Evidence layers in a public repo

1. **Activity** - Stars, forks, and issues show that someone noticed the tool
2. **Declaration** - Manifests, env templates, and bot configs show what someone said they need
3. **Resolution** - Lockfiles and SDK imports show what got installed and called
4. **Build** - Dockerfiles and CI workflows show what gets built and tested on push
5. **Deploy** - IaC provider blocks, compose, and Helm files show what the org provisions and runs

*The further a file sits from what the org deploys, the weaker it is as proof of stack.*

### Review windows, and why they are defaults

Nobody has published how long a committed file stays a reliable signal. The only documented reference point is GitHub's rule for marking a repo inactive. A repo counts as inactive when all three of these hold: no commits in over three years, Dependabot not enabled, and no published package referencing it. One unverified secondary source says code search drops repos that have not been pushed to in over a year. The windows below are my working defaults inside those lines. Count each window from the last commit that touched the file, not from the repo's last push, and shorten the windows if your own closed-won history says to.

**Build and deploy files**

| File | Proof strength | Review window |
|---|---|---|
| IaC provider block | Strong | 6 months |
| CI workflow | Strong | 6 months |
| Lockfile | Strong | 12 months |
| Compose or Helm file | Medium | 6 months |
| Dockerfile | Medium | 6 months |
| SDK import | Medium | 12 months |

**Declaration and activity signals**

| File or signal | Proof strength | Review window |
|---|---|---|
| Package manifest | Medium in service path, Weak elsewhere | 12 months |
| Bot config | Medium for ecosystem only | 6 months |
| Env template | Weak | 6 months |
| Vendor-repo issue | Weak for the account | 3 months |
| Fork | None unless commits ahead | 3 months |
| Star | None | Never evidence |

## The file-by-file lookup

Each entry gives the same four things: what the file proves about the account, how it lies, the check that confirms it, and how long it stays usable. Jump to the file you found, read the entry, and leave.

> **Rule:** Two layers before the field
>
> No single file writes to a CRM tech-stack field. At least two layers must agree, and one of them must be a build or deploy file.

### Package manifest (package.json, pom or gradle file)

- **Proves:** someone declared the dependency in this directory on the default branch.
- **Lies when:** it sits in examples/ or docs/. GitHub's dependency graph parses every manifest it finds, so a demo app looks like production use. It also lies the other way. When a Maven or Gradle version is set by a variable, the graph drops that dependency, so a real dependency disappears.
- **Confirm:** a lockfile in the same directory, plus a CI workflow or IaC file that builds or deploys that directory. Read the raw file, never the graph's summary.
- **Review window:** 12 months.

### Lockfile

- **Proves:** an install actually ran and resolved versions, including transitive dependencies. GitHub only resolves transitive dependencies from lockfiles, which is why lockfiles beat manifests as evidence.
- **Lies when:** it is the only artifact in the repo. A lockfile with no CI or IaC alongside it can be an abandoned side project or a finished tutorial.
- **Confirm:** the date of the last commit that touched it, and a CI step that installs from it.
- **Review window:** 12 months.

### CI workflow (GitHub Actions YAML)

- **Proves:** the org runs the tool in automation. Say hashicorp/setup-terraform appears in a workflow on the default branch of an org-owned repo. That is close to direct proof that the team runs Terraform in its pipeline. The dependency graph also parses Actions YAML.
- **Lies when:** the repo is a template or a fork, where workflows arrive pre-written and may never have been touched. It also lies when the repo is archived.
- **Confirm:** commits to the workflow file by the org's own people after the repo was created, in a repo that is not a fork, a template, or archived.
- **Review window:** 6 months.

### Dockerfile

- **Proves:** the service is packaged as a container. The base image and install lines show the runtime and system packages.
- **Lies when:** it sits in examples/ or a dev-only folder, or builds a throwaway tutorial environment.
- **Confirm:** a CI step that builds this Dockerfile, or a compose, Helm, or IaC file that deploys the image it produces. Don't assume the dependency graph reads it. Check GitHub's table of supported ecosystems before you rely on graph data.
- **Review window:** 6 months.

### IaC provider block (Terraform provider, Pulumi.yaml)

- **Proves:** the org provisions infrastructure with that tool on that provider. If you sell to cloud or platform teams, this is the strongest single file there is.
- **Lies when:** it sits in an examples/ directory, or the repo is a module the company publishes for its customers. In that case the provider block describes how other people deploy, not how the company runs its own systems.
- **Confirm:** a non-example path, a CI workflow that runs the tool, and a last-touch date inside the window. A Pulumi.yaml at the root of an org-owned repo is a cleaner signal than one buried in a samples folder.
- **Review window:** 6 months.

### Compose or Helm file

- **Proves:** which services run together. The images it names show the databases, queues, and sidecars the app depends on.
- **Lies when:** the compose file only starts a local dev environment, or the Helm chart packages the company's own product for its customers.
- **Confirm:** per-environment values or override files, and a CI deploy step that references the file.
- **Review window:** 6 months.

### Env template (.env.example)

- **Proves:** the app expects credentials or endpoints for a named service.
- **Lies when:** variables stay behind after an integration was ripped out, or the whole template came from a starter kit.
- **Confirm:** an SDK import in service code that reads the same variable. If you find a real secret instead of a placeholder, do not use it. Your evidence stops at what the template names.
- **Review window:** 6 months.

### Bot config (Dependabot)

- **Proves:** the team maintains dependency updates. The ecosystems and directories it lists show which package managers live where. Having Dependabot enabled also keeps a repo out of GitHub's inactive category.
- **Lies when:** the config was copied from a template and nobody merges the bot's pull requests.
- **Confirm:** bot pull requests merged recently in the same repo.
- **Review window:** 6 months.

### SDK import in source code

- **Proves:** code calls the library, which a manifest alone cannot show.
- **Lies when:** the import is in test/fixtures, examples/, or vendored code. Linguist's vendor.yml marks paths such as node_modules/ and deps/ as vendored. GitHub staff have said code search does not index some vendored or machine-generated code. So vendored hits are both noisy and incomplete.
- **Confirm:** the import sits in a service path, and the manifest or lockfile in the same tree declares the package.
- **Review window:** 12 months.

### Issue on the vendor's repo

- **Proves:** a person ran into a real problem with the tool. A company email domain on an issue filed against hashicorp/terraform-provider-aws is a strong signal about that person.
- **Lies when:** the person was working on a personal project, contributes to open source in their own time, or has since left the company.
- **Confirm:** the person's current employer, then a committed file in that employer's org that names the same tool.
- **Review window:** 3 months.

### Fork

- **Proves:** someone clicked fork. On its own, it says nothing about stack.
- **Lies when:** it is an unmodified copy, which most forks are. Code search leaves forks out unless you add fork:true, and only indexes a fork that has more stars than its parent. So you cannot sweep forks completely.
- **Confirm:** commits ahead of the parent, made by the org's own people, in an org-owned fork.
- **Review window:** 3 months, and only while those commits ahead are recent.

### Star

- **Proves:** nothing about what the account runs.
- **Lies when:** always, as stack evidence. Ranking pages score stars anyway. One gives a star 1 point and an issue 8, with no published basis for either number.
- **Confirm:** a committed file. If there isn't one, the star stays out of the field.
- **Review window:** none. A star never goes in the tech-stack field.

## What do GitHub's dependency graph and dependents list actually measure?

The dependency graph is GitHub's parsed view of the manifests and lockfiles in a repo. The dependents list is the reverse: the public repos GitHub thinks depend on a package. Both are wrong often enough that they work as leads, not evidence, and the dependents list now counts repos that opted in, not repos that adopted the package.

Bifolco, Romano, Nocera, Francese, Scanniello, and Di Penta sampled 297 Java and 338 Python projects and checked the graph against what the repos actually declared. Their dependents analysis covered 2,068,441 dependents.

**24.83% - Java dependencies that GitHub's dependency graph reported incorrectly**

First snapshot in Bifolco et al.'s study, where Python came out better at 84.48% correct.

| Metric | Java | Python |
|---|---|---|
| Dependencies correct, snapshot 1 | 75.17% | 84.48% |
| Dependencies correct, snapshot 2 | 73.25% | 77.86% |
| Dependents incorrect (EASE paper) | 3.38% | 29.06% |
| Repos with all dependents correct | 13.30% | 21.88% |
| Manifest vs graph match | 77% | 96% |

The two publications disagree on dependents. The conference paper reports 29.06% of Python dependents wrong, but the extended journal abstract says dependents are inaccurate by up to 10%. I can't reconcile the two. If the exact figure matters to you, the replication package is public. Either way, the pattern holds: Python dependents were the least reliable figure in the study, even though Python dependencies were the most reliable.

The documented causes:

- **Occurrence not found:** GitHub lists a dependent whose manifest no longer contains the package. The authors name this as the main reason dependents come out wrong. These stale entries inflate the list.
- **Display cap:** the authors suspect the graph shows only 100 manifests or lockfiles per repo.
- **Variable versions:** GitHub documents that it drops versions set by variables.
- **Loose dependencies:** the graph does not automatically include them.
- **Used-by threshold:** the "Used by" count only appears once more than 100 repositories depend on the package.
- **Public only:** GitHub only works out dependents for public repos, so private usage never shows up.

### The opt-in change

GitHub first let users turn the dependency graph off for public repos, then made off the default for newly created public repos. It also disables the graph on inactive repos. One maintainer confirmed that a repo has to have the graph explicitly enabled to count as a dependent, and saw new dependents per day fall from about 3k to about 100. So the dependents list now measures security-tooling habits, not adoption. That is the honest answer on GitHub dependents list accuracy for prospecting: it gives you a list of opted-in repos, not a market map.

> **Watch out:** Absence from dependents proves nothing
>
> A company missing from a dependents list may simply have the graph turned off. Before you mark the account as a non-user, search its manifests directly.

## What do code search and the dependency graph miss?

Both see only the default branch, and both have size and count caps. Code search also has a 1,000-result ceiling that cuts results off without telling you, and it leaves out most forks. If you use either one to find companies using a library on GitHub, you are looking at a partial view.

| Limit | Code search (REST) | Dependency graph |
|---|---|---|
| Branch | Default only | Default only |
| File size | 384 KB | 10 MB (older doc: 0.5 MB) |
| Count cap | 1,000 results / 4,000 repos | 150 manifests per repo |
| Forks | Excluded unless more stars than parent | Available |
| New public repos | Indexed | Off by default |

What the table means in practice:

- **Default branch only.** Work on a feature branch is invisible to both tools. A team migrating to your category on a branch shows no signal until it merges.
- **Rate and size.** Code search needs authentication and allows 10 requests per minute. Results come back at most 10 pages of 100 items, from up to 4,000 matching repos.
- **Query shape.** Queries are capped at 256 characters and five operators. The REST endpoint uses the legacy syntax, so a query that works in the web UI may behave differently over the API.
- **Graph caps move.** GitHub's docs have given 0.5 MB and 20 manifests, now give 10 MB and 150, and GitHub Enterprise Server 3.16 gives 600. Check the troubleshooting page before you trust any cap.
- **Skipped directories are not published.** GitHub says there are limits on the size, number, and location of manifests, but it does not publish which directories it skips, such as vendored, examples, or fixtures folders. Test a known repo yourself before assuming either way.

To search GitHub workflows for companies using an action, scope a code search to the org and the workflow folder. I have not verified exactly how the path: and filename: qualifiers behave, so run each query against a repo you already know before you trust it on a prospect.

**One-org code search sweep, one query per signal file**

```
org:ORGNAME path:.github/workflows hashicorp/setup-terraform
org:ORGNAME filename:Pulumi.yaml
org:ORGNAME required_providers
org:ORGNAME filename:package.json "PACKAGE-NAME"
org:ORGNAME filename:Dockerfile "IMAGE-OR-PACKAGE"
org:ORGNAME filename:.env.example "SERVICE_VARIABLE"
org:ORGNAME path:.github filename:dependabot.yml
```

*Replace ORGNAME and the package strings; run each line as its own query and log the total count it returns.*

> **Tip:** Split until every query is under 1,000
>
> When a query reaches the 1,000-result ceiling, it stops without telling you. Split it by language: or path: until each piece returns fewer than 1,000 hits and no response shows incomplete_results=true.

## Where do profile skills run out and committed files take over?

For common tools, the skill tags on people's profiles give you plenty of people to reach. For rarely tagged tools, those tags undercount so badly that committed files carry most of the evidence. The gap is large enough to change where you search.

In Refolk's index of professional profiles, the Platform Engineer counts by infrastructure-as-code skill look like this:

| Segment | Count | Sample employers |
|---|---|---|
| US + Terraform | 441 | Deloitte, Block, Slalom, Citizens |
| Germany + Terraform | 140 | SAP, Bosch Digital, Allianz Technology, Synthesia |
| US + Pulumi | 6 | Backblaze, S&P Global, Second Front |
| US vs Germany, Terraform | 3.15x | Derived |
| Terraform vs Pulumi, US | 73.5x | Derived |

**73.5x - Terraform vs Pulumi tags on US Platform Engineer profiles**

In Refolk's index, 441 US Platform Engineers list Terraform and 6 list Pulumi, so a rarely tagged tool has to be found through committed files.

Read the counts as lower bounds. They only include people who listed the skill, so the 6 Pulumi profiles can't tell you whether Pulumi is rarely used or just rarely tagged. Committed files can. A Pulumi.yaml in an org-owned repo is evidence no matter what anyone wrote on a profile. In Germany, 10 of the 25 sampled Terraform profiles were in Berlin, which tells you where a German Terraform search will cluster.

This is where repo evidence and people data have to meet. A file tells you the account runs the tool, but it doesn't tell you who to email. Joining the two by hand means going from org to repo to file, then to the company, then to the people. [Refolk](/) runs that whole chain as one plain-English search over the public GitHub graph and professional profiles.

I ran this search: `Engineering managers at companies with a Pulumi.yaml at the root of an org-owned public repo` - [see the full result list](https://www.refolk.ai/s/kg4m1gaerw).

*Returns engineering managers matched to companies whose own public repos commit a root-level Pulumi.yaml, with the repo behind each match.*

## How do I verify a file signal for one account?

Run seven steps in order: tag the repos, search each signal file, classify hits by path, corroborate across two layers, check freshness, attribute ownership, and write the evidence. One account takes an SDR and an AE about 40 minutes plus attribution and write-up. No published source documents this as a sales procedure. It is my synthesis of what the platform limits and failure modes require.

#### File signal to CRM field

1. **List and tag the org's repos** - Pull every public repo in the org and tag each one as fork, archived, template, or live. SDR, about 10 minutes; done when no repo is untagged.
2. **Run one code search per signal file** - Search for each file type with the org: qualifier and stay under 10 requests per minute. SDR, about 15 minutes; done when every query returns under 1,000 hits and no response shows incomplete_results=true.
3. **Classify every hit by path** - Sort each hit into root, service directory, examples/, docs/, test/fixtures, or vendor/. AE, about 10 minutes; done when only root and service-directory hits are left as candidate evidence.
4. **Corroborate across two layers** - Pair each candidate file with a second layer, for example a manifest with a lockfile and a CI workflow or IaC file. AE; done when at least two layers agree and one of them is a build or deploy file.
5. **Check freshness per file** - Find the date of the last commit that touched each evidence file and compare it with that file's review window and GitHub's 3-year inactive line. About 5 minutes; done when every evidence file has a date.
6. **Attribute the repo** - Confirm that each evidence repo belongs to the company's org and not to an employee's personal account. Done when every evidence file has an owner of record.
7. **Write the evidence to the CRM** - In the tech-stack field, record the file URL, commit SHA, last-touch date, proof grade, and a review date. Done when another rep could reopen every file from the record alone.

Step 6 is where most mistakes happen. An engineer's personal repo full of Terraform is a strong signal about that person, but it says nothing about what their employer runs. When matching personal accounts to employers is the slow part, Refolk resolves the person behind a GitHub handle to a current employer. The account-level field still needs a file in the org's own repos.

**CRM tech-stack evidence record**

```
Tool: Terraform
Proof grade: Strong
Layer 1: IaC provider block | FILE-URL | SHA COMMIT-SHA | last touched YYYY-MM-DD | path: service
Layer 2: CI workflow (hashicorp/setup-terraform) | FILE-URL | SHA COMMIT-SHA | last touched YYYY-MM-DD
Repo status: org-owned | not a fork | not archived | not a template
Attribution: org repo
Signals not used as evidence: dependents count, stars, forks
Review date: YYYY-MM-DD (last touch + 6 months)
Gaps: anything private or off the default branch is unknown, not absent
```

*One block per tool; keep the commit SHA so the evidence survives later edits to the file.*

## How do file signals mislead? Failure modes and false positives

File signals fail in two directions. False positives make a demo, a copy, or an abandoned project look like production use. False negatives make a real user disappear because of how the platform parses or indexes files. Each failure below comes with the check that catches it.

1. **Dependents or used-by count read as adoption.** A repo missing from the count gets read as "not a user", when it may just have the graph turned off. Check: search the repo's manifests directly.
2. **Manifest in examples/ or docs/.** The graph parses every manifest it finds, so a demo app looks like production. Check: look at the path, and whether a matching deploy artifact exists.
3. **Version set by a variable.** In Maven and Gradle, the graph drops the dependency, which gives a false negative. Check: read the raw pom or gradle file.
4. **Search reaching the 1,000-result ceiling.** The cut-off is silent, and accounts past result 1,000 never appear. Check: split queries by language: or path: until each returns fewer than 1,000.
5. **Forks.** Search leaves them out, and the ones that do appear are often unmodified copies. Check: compare the fork's commits ahead of its parent.
6. **Star or fork used as proof of stack.** Ranking pages score these as intent. One claims fast follow-up "can 3-5x your outbound reply rates" with no method behind it. They prove nothing about what a company runs. Check: corroborate with a committed file.
7. **Lockfile without CI or IaC.** It can be an abandoned side project. Check: the date of the last commit that touched it, measured against the 3-year inactive rule.
8. **Template repos.** Workflows and configs arrive pre-written, so they show what the template author chose, not the org. Check: commits to the file by the org's own people.
9. **Archived repos.** The files are frozen at whatever the stack was then. Check: archived status from step 1. At most, log the file as past stack.
10. **Employee side projects.** A personal repo shows one person's habits. Check: attribution in step 6. Personal repos never fill an account field.

Sweeping forks completely is structurally impossible. Forks are only indexed when they have more stars than their parent, so the stars-and-forks signals that ranking pages promote are exactly the ones search can't list in full. Measure them as a sample, never as a census.

Nobody has published what share of code search hits fall in forks, templates, examples, or archived repos, and I have not measured it either. If you need that number for a forecast, take a sample of a few hundred hits from your own sweeps and classify them before you rely on any ratio.

#### Path class vs freshness for one hit

Horizontal axis runs from Example, vendored, or fork path to Org-owned service path. Vertical axis runs from Last touched outside window to Last touched inside window.

| Quadrant | What it means |
| --- | --- |
| Live demo | Do not write it; look for a matching deploy file in a service path |
| Candidate evidence | Corroborate with a second layer, then write it with SHA and review date |
| Noise | Discard it and note the path pattern so the next sweep filters it out |
| Past stack | Log it as historical and ask about migration in discovery |

*Only a fresh file in an org-owned service path can go in a tech-stack field, and even then it needs a second layer.*

> A keyword hit proves a string exists. A file in a deploy path proves someone ships it.

## How do I keep tech-stack evidence current?

Re-run the sweep for each account on its review date, and re-check GitHub's own limits before every large sweep, because the platform rules have changed before and will change again. Evidence that passed six months ago can quietly fail today.

What to re-check, and where:

- **Graph caps and parsing rules:** GitHub's troubleshooting page for the dependency graph. The documented manifest size and count caps have already changed between doc versions.
- **Supported files:** GitHub's table of supported package ecosystems, before you assume a file type feeds the graph.
- **Dependents defaults:** GitHub's changelog. The move to off by default for new public repos changed what a dependents count means overnight.
- **Search caps and syntax:** GitHub's REST search docs, for rate limits, result caps, and legacy-syntax differences.
- **Your own windows:** once you have closed-won and closed-lost outcomes tied to evidence dates, compare them against the default windows and tighten whichever ones over-promise.

When a review date comes up, open the recorded commit SHA and the current default branch side by side. If the file is gone, moved into examples/, or untouched past its window, downgrade the field rather than leaving the old value in place.

#### Before the tech-stack field is written

- [ ] Every repo in the org is tagged as live, fork, archived, or template.
- [ ] No code search query reached 1,000 results or returned incomplete_results=true.
- [ ] Every hit is classified by path, and none from examples/, docs/, test/fixtures, or vendor/ counts as use.
- [ ] At least two layers agree, and one of them is a build or deploy file.
- [ ] The last commit touching each evidence file falls inside its review window and inside the 3-year inactive line.
- [ ] Every evidence repo is owned by the company's org, not an employee's personal account.
- [ ] The record holds the file URL, commit SHA, last-touch date, proof grade, and review date.
- [ ] No star, fork, or dependents count appears as evidence in the field.

## Frequently asked questions

### Is a dependency in package.json proof that a company uses a library?

No. A manifest entry only proves someone declared the dependency in that directory. It is medium-grade evidence when it sits in a service path and weak when it sits in examples/ or docs/, because GitHub's dependency graph parses every manifest it finds, demo apps included. Before you treat it as usage, look for a lockfile in the same directory and a CI workflow or IaC file that builds or deploys that directory.

### How accurate is GitHub's dependents list for prospecting?

It's not accurate enough to count as evidence. Bifolco et al. found up to 29.06% of Python dependents were wrong in one paper, but their journal version gives a figure of up to 10%. Also, GitHub now defaults the dependency graph to off for newly created public repos, so the list only counts repos that opted in. Treat it as a lead list, check each repo's manifests directly, and never read a missing company as a non-user.

### How do I search GitHub workflows for companies using an action?

Use code search with the org: qualifier and the action's name, such as hashicorp/setup-terraform, scoped to workflow files. Code search only covers the default branch, needs authentication, allows 10 requests per minute, and returns at most 1,000 results without telling you it stopped. Test any path: qualifier against a repo you already know before you rely on it, and split broad queries until each one returns fewer than 1,000 hits.

### Do GitHub stars and forks count as buying signals for developer tool sales?

Not as stack evidence. A star proves someone clicked a button, and most forks are unmodified copies. Ranking pages give these activities point scores without publishing a method. A fork only counts once it has commits ahead of its parent, made by the org's own people, in an org-owned fork. A star never goes in a tech-stack field, though it can tell you who to research next.

### How long does a committed file stay valid as stack evidence?

Nobody has published a decay rate. The only documented reference point is GitHub's rule that marks a repo inactive after three years without commits. I use working windows inside that line: 6 months for build and deploy files, 12 months for lockfiles, manifests, and imports, and 3 months for activity like issues. Count from the last commit that touched the file, and adjust if your closed-won data says otherwise.

### What does it mean if a prospect has no matching files in public repos?

It means nothing about their stack. GitHub only works out dependents for public repos, so private usage never shows up, and code search skips non-default branches, files over 384 KB, and most forks. An empty result means public evidence is missing. Log it as unknown rather than no, and ask about the stack in discovery.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/committed-file-stack-signal-reference*