Fork Intelligence

Fork Intelligence

Systematic methodology for discovering valuable work in GitHub fork ecosystems. Stars-only filtering misses 60-100% of substantive forks — this skill uses branch-level divergence analysis, upstream PR cross-referencing, and domain-specific heuristics to find what matters.

Validated empirically across 10 repositories spanning Python, Rust, TypeScript, C++/Python, and Node.js (tensortrade, backtesting.py, kokoro, pymoo, firecrawl, barter-rs, pueue, dukascopy-node, ArcticDB, flowsurface).

Self-Evolving Skill: This skill improves through use. If instructions are wrong, parameters drifted, or a workaround was needed — fix this file immediately, don't defer. Only update for real, reproducible issues.

FIRST — TodoWrite Task Templates

MANDATORY: Select and load the appropriate template before any fork analysis.

Template A — Full Analysis (new repository)

1. Get upstream baseline (stars, forks, default branch, last push)
2. List all forks with pagination, note timestamp clusters
3. Filter to unique-timestamp forks (skip bulk mirrors)
4. Check default branch divergence (ahead_by/behind_by)
5. Check non-default branches for all forks with recent push or >1 branch
6. Evaluate commit content, author emails, tags/releases
7. Cross-reference upstream PR history from fork owners
8. Tier ranking and cross-fork convergence analysis
9. Produce report with actionable recommendations

Template B — Quick Scan (triage only)

1. Get upstream baseline
2. List forks, filter by timestamp clustering
3. Check default branch divergence only
4. Report forks with ahead_by > 0

Template C — Targeted Fork Evaluation (specific fork)

1. Compare fork vs upstream on all branches
2. Examine commit messages and changed files
3. Check for tags/releases, open issues, PRs
4. Assess cherry-pick viability

---

Signal Priority Order

Ranked by empirical reliability across 10 repositories. See signal-priority.md for details.

---

Pipeline — 7 Steps

Step 1: Upstream Baseline

UPSTREAM="OWNER/REPO"
gh api "repos/$UPSTREAM" --jq '{forks_count, pushed_at, default_branch, stargazers_count}'

Step 2: List All Forks + Timestamp Clustering

# List all forks with activity signals
gh api "repos/$UPSTREAM/forks" --paginate \
  --jq '.[] | {full_name, pushed_at, stargazers_count, default_branch}'

Timestamp clustering: Forks sharing exact pushed_at with upstream are bulk mirrors created by GitHub's fork mechanism and never touched. Group by pushed_at — forks with unique timestamps warrant investigation. This alone eliminates 85%+ of noise.

# Filter to unique-timestamp forks (skip bulk mirrors)
gh api "repos/$UPSTREAM/forks" --paginate \
  --jq '.[] | {full_name, pushed_at, stargazers_count}' | \
  jq -s 'group_by(.pushed_at) | map(select(length == 1)) | flatten'

Step 3: Default Branch Divergence

BRANCH=$(gh api "repos/$UPSTREAM" --jq '.default_branch')

# For each candidate fork
gh api "repos/$UPSTREAM/compare/$BRANCH...FORK_OWNER:$BRANCH" \
  --jq '{ahead_by, behind_by, status}'

The status field meanings:

• identical — pure mirror, skip
• behind — stale mirror, skip
• diverged — has original commits AND is behind (interesting)
• ahead — has original commits, up-to-date with upstream (rare, most valuable)

Important: Always compare from the upstream repo's perspective (repos/UPSTREAM/compare/...). The reverse direction (repos/FORK/compare/...) returns 404 for some repositories.

Step 4: Non-Default Branch Analysis (CRITICAL)

This is the single biggest methodology improvement. Across all 10 repos tested, 50%+ of the most valuable fork work lived exclusively on feature branches.

Examples:

• flowsurface/aviu16: 7,000-line GPU shader heatmap only on shader-heatmap
• ArcticDB/DerThorsten: 147 commits across conda_build, clang, apple_changes
• pueue/FrancescElies: Duration display only on cesc/duration
• barter-rs: 6 of 12 top forks had work only on feature branches

# List branches on a fork
gh api "repos/FORK_OWNER/REPO/branches" --jq '.[].name' | head -20

# Check divergence on a specific branch
gh api "repos/$UPSTREAM/compare/$BRANCH...FORK_OWNER:FEATURE_BRANCH" \
  --jq '{ahead_by, behind_by, status}'

Heuristics for which forks need branch checks:

• Any fork with pushed_at more recent than upstream but ahead_by == 0 on default branch
• Any fork with more than 1 branch
• Branch count > 10 is suspicious — likely non-trivial work (ArcticDB: Rohan-flutterint had 197 branches)

Step 5: Commit Content Evaluation

gh api "repos/$UPSTREAM/compare/$BRANCH...FORK_OWNER:BRANCH" \
  --jq '.commits[] | {sha: .sha[:8], message: .commit.message | split("\n")[0], date: .commit.committer.date[:10], author: .commit.author.email}'

What to look for:

• Commit email domains reveal institutional contributors (@man.com, @quantstack.net)
• Subtract merge commits from ahead_by count (e.g., akeda2/pueue showed 35 ahead but 28 were upstream merges)
• Build system changes (CMakeLists.txt, Cargo.toml, pyproject.toml) indicate platform enablement
• Protobuf schema changes indicate architectural-level features
• Test files alongside source changes signal production-intent work

Step 6: Fork-Specific Signals

# Tags/releases (strongest independent maintenance signal)
gh api "repos/FORK_OWNER/REPO/tags" --jq '.[].name' | head -10
gh api "repos/FORK_OWNER/REPO/releases" --jq '.[] | {tag_name, name, published_at}' | head -5

# Open issues on the fork (signals independent project maintenance)
gh api "repos/FORK_OWNER/REPO/issues?state=open" --jq 'length'

# Check if repo was renamed (strong divergence intent signal)
gh api "repos/FORK_OWNER/REPO" --jq '.name'

Step 7: Cross-Fork Convergence + Upstream PR History

# Check upstream PRs from fork owners
gh api "repos/$UPSTREAM/pulls?state=all" --paginate \
  --jq '.[] | select(.head.repo.fork) | {number, title, state, user: .user.login}'

Cross-fork convergence: When multiple forks independently solve the same problem, it signals unmet upstream demand:

• firecrawl: 3 forks adopted Patchright for anti-detection
• flowsurface: 3 forks added technical indicators independently
• kokoro: 2 independent batched inference implementations
• barter-rs: 4 forks added Bybit support

Upstream PR cross-reference catches:

• Rebased/force-pushed work invisible to compare API
• Work that was merged upstream (fork shows 0 ahead but was historically significant)
• Declined PRs with valuable code that the fork still maintains

---

Tier Classification

After running the pipeline, classify forks into tiers:

---

Domain-Specific Patterns

Different codebases exhibit different fork behaviors. See domain-patterns.md for full details.

---

Quick-Scan Pipeline (5-minute triage)

For rapid triage of any new repo:

UPSTREAM="OWNER/REPO"
BRANCH=$(gh api "repos/$UPSTREAM" --jq '.default_branch')

# 1. Baseline
gh api "repos/$UPSTREAM" --jq '{forks_count, pushed_at, stargazers_count}'

# 2. Forks with unique timestamps (skip mirrors)
gh api "repos/$UPSTREAM/forks" --paginate \
  --jq '.[] | {full_name, pushed_at, stargazers_count}' | \
  jq -s 'group_by(.pushed_at) | map(select(length == 1)) | flatten | sort_by(.pushed_at) | reverse'

# 3. Check ahead_by for each candidate
# (loop over candidates from step 2)

# 4. Check upstream PRs from fork authors
gh api "repos/$UPSTREAM/pulls?state=all" --paginate \
  --jq '.[] | select(.head.repo.fork) | {number, title, state, user: .user.login}'

---

Known Limitations

---

Report Template

Use this structure for the final analysis report:

# Fork Analysis Report: OWNER/REPO

**Repository**: OWNER/REPO (N stars, M forks)
**Analysis date**: YYYY-MM-DD

## Fork Landscape Summary

| Metric                                | Value  |
| ------------------------------------- | ------ |
| Total forks                           | N      |
| Pure mirrors                          | N (X%) |
| Divergent forks (ahead on any branch) | N      |
| Substantive forks (meaningful work)   | N      |
| Stars-only miss rate                  | X%     |

## Tiered Ranking

### Tier 1: Major Extensions

(fork details with ahead_by, key features, files changed)

### Tier 2: Targeted Features

...

### Tier 3: Infrastructure/Packaging

...

## Cross-Fork Convergence Patterns

(themes that multiple forks independently implemented)

## Actionable Recommendations

- Cherry-pick candidates
- Feature inspiration
- Security fixes

---

Post-Change Checklist

After modifying THIS skill:

1. [ ] YAML frontmatter valid (no colons in description) 2. [ ] Trigger keywords current in description 3. [ ] All ./references/ links resolve 4. [ ] Pipeline steps numbered consistently 5. [ ] Shell commands tested against a real repository 6. [ ] Append changes to evolution-log.md

Post-Execution Reflection

After this skill completes, reflect before closing the task:

0. Locate yourself. — Find this SKILL.md's canonical path before editing. 1. What failed? — Fix the instruction that caused it. 2. What worked better than expected? — Promote to recommended practice. 3. What drifted? — Fix any script, reference, or dependency that no longer matches reality. 4. Log it. — Evolution-log entry with trigger, fix, and evidence.

Do NOT defer. The next invocation inherits whatever you leave behind.

Domain-Specific Fork Patterns

Fork behavior varies significantly by project domain. These patterns were identified across 10 repositories.

Scientific/ML Libraries

Repos studied: pymoo (459 forks), kokoro (650 forks), tensortrade (1,191 forks)

Key pattern: Researchers fork, implement their algorithm, publish a paper, and move on — with zero social engagement. No stars, no issues, no PRs. The fork exists only as a code artifact of their research.

Signals to prioritize:

• New files in algorithm/model directories (not just config changes)
• Academic email domains in commit authors
• Commit messages referencing paper titles, arXiv IDs, or conference names
• Large file-count changes (pymoo/AnonymeMeow: 300 files, 2 new PSO algorithms, 0 stars)

Traps to avoid:

• Highest-starred fork is often a pure mirror (pymoo: 26-star msu-coinlab = zero original commits)
• Jupyter notebooks committed to forks are usually personal experiments, not reusable features
• "Framework" renames (changing project name in README) with no code changes

Fork types by frequency:

1. Algorithm implementations (most valuable, hardest to find) 2. Benchmark/dataset additions 3. Personal experiment notebooks (low value) 4. Course assignment submissions (no value)

Trading/Finance

Repos studied: backtesting.py (1,392 forks), barter-rs (312 forks), flowsurface (225 forks), dukascopy-node (105 forks), tensortrade (1,191 forks)

Key pattern: Exchange connector additions dominate. The most valuable fork work is in private repositories (trading firms keep alpha-generating code private).

Signals to prioritize:

• New exchange adapter files (e.g., bybit.rs, deribit.rs)
• Data format additions (Parquet, streaming APIs)
• Performance optimizations (batching, Rust rewrites)
• Alternative bar types (tick-volume, range bars)

Cross-fork convergence is especially useful:

• barter-rs: 4 independent Bybit implementations signals a critical exchange gap
• dukascopy-node: Memory problem spawned streaming API fork
• flowsurface: 3 forks independently added technical indicators

Traps to avoid:

• Forks with committed API keys or credentials (security risk, not a feature)
• "Strategy" forks that just add a trading strategy notebook (personal, not reusable)
• Private forks are fundamentally invisible — accepted limitation

Infrastructure/DevTools

Repos studied: pueue (152 forks), firecrawl (6,077 forks)

Key pattern: Self-hosting and SaaS-removal is the dominant fork motivation for SaaS tools. CLI tools get "superset" forks that add new subcommands.

Signals to prioritize:

• Docker/deployment config changes (high value for operators)
• SaaS dependency removal (firecrawl: devflowinc/firecrawl-simple with 630 stars)
• New CLI subcommands (pueue/freesrz93: 7 new subcommands)
• Release presence (strongest signal — only freesrz93 had releases, and it was the most substantive pueue fork)

Fork types by frequency:

1. Self-hosting adaptations (most common for SaaS tools) 2. Feature supersets (new subcommands, options) 3. Integration adapters (NATS, message buses, cloud storage) 4. Deployment/packaging (systemd, Docker, Helm charts)

Traps to avoid:

• Install scripts that look like features but are just automation wrappers
• "Awesome" or "starter" forks that rename the project but add nothing

C++/Python Mixed Codebases

Repos studied: ArcticDB (165 forks)

Key pattern: Feature work almost exclusively lives on branches (not default branch). Enterprise internal forks expose company development roadmaps. Branch count is the strongest initial signal.

Signals to prioritize:

• Branch count > 10 (ArcticDB: Rohan-flutterint had 197 branches of Man Group internal work)
• CMakeLists.txt and build system changes (platform enablement)
• Protobuf schema changes (architectural features)
• Commit email domains (@man.com, @quantstack.net reveal institutional contributors)
• Custom release tags with company suffixes (+man0)

Enterprise fork indicators:

• Structured branch naming (enhancement/, bugfix/, feature/)
• Commit messages referencing internal ticket systems (e.g., "AN-912")
• Release candidate tags
• Multiple contributors with same email domain

Traps to avoid:

• "Mirror" forks with 100+ branches may be automated CI/CD artifacts, not manual work
• Maintainer dev forks (branch names map 1:1 to upstream PRs) — flag and exclude from independent work analysis
• Build-only forks that only change CI/CD without touching source code

Node.js Libraries

Repos studied: dukascopy-node (105 forks)

Key pattern: Fork ecosystem is extremely flat — no fork has more than 1 star. npm publication as a separate package is the strongest signal of independent project status.

Signals to prioritize:

• npm publication check (dukascopy-node: kyo06 published dukascopy-node-plus)
• package.json name/version changes
• New output format support (Parquet, streaming)
• Feature branch naming conventions matching upstream (feat/, fix/)

Traps to avoid:

• Scoped package republications (@user/package) that are just mirrors
• Forks with only package-lock.json changes (dependency bumps, not features)

Rust Projects

Repos studied: barter-rs (312 forks), pueue (152 forks), flowsurface (225 forks)

Key pattern: Cargo.toml diff is a reliable quick filter for genuine feature work. Feature branches are common. Compilation requirements mean forks that build successfully represent real effort.

Signals to prioritize:

• Cargo.toml dependency additions (new crate = new feature)
• New module files (.rs files in src/)
• Workspace member additions
• Feature flag additions in Cargo.toml

Traps to avoid:

• Cargo.lock changes alone (just dependency resolution updates)
• Clippy/formatting-only commits
• Legacy Python-era forks (some Rust rewrites of Python projects have incompatible old forks)

Empirical Data — Stars Anti-Correlation

Quantitative findings from fork analysis across 10 repositories, February 2026.

Aggregate Finding

Stars-only filtering misses 60-100% of substantive forks in every repository tested.

Per-Repository Data

Highest-Starred Fork vs Actual Value

Across all 10 repos, the highest-starred fork was often a pure mirror:

Most Valuable Forks (All 0 Stars)

Blind Spots Discovered

Key Insight: Non-Default Branches

The single biggest methodology improvement. Examples of work ONLY on feature branches:

• flowsurface/aviu16: 7,000-line GPU shader heatmap on shader-heatmap branch
• backtesting.py/blue-int: Critical CAGR math bug fix on fix/cagr-and-annualized-return
• ArcticDB/DerThorsten: 147 commits across conda_build, clang, apple_changes
• barter-rs: 6 of 12 top forks had work only on feature branches
• pueue/FrancescElies: Duration display feature on cesc/duration
• dukascopy-node: Top 3 most interesting forks had zero divergence on default branch

Evolution Log — fork-intelligence

2026-02-18: Initial Creation

• Created skill from empirical methodology developed across 10 repositories
• 7-step pipeline with signal priority order
• Domain-specific patterns for 6 codebase types
• Quantitative evidence: stars miss 60-100% of substantive forks
• Reference files: signal-priority.md, domain-patterns.md, empirical-data.md
• Original methodology developed in tensortrade fork analysis session, then validated across backtesting.py, kokoro, pymoo, firecrawl, barter-rs, pueue, dukascopy-node, ArcticDB, flowsurface

Signal Priority Reference

Empirical ranking of fork analysis signals, validated across 10 repositories.

Rank 1: Branch-Level Divergence

Why it's #1: Across all 10 repos, 50%+ of the most valuable fork work lived exclusively on feature branches, invisible to default-branch-only analysis.

Technique: List all branches on each fork, then compare each non-default branch against upstream.

gh api "repos/FORK_OWNER/REPO/branches" --jq '.[].name'
gh api "repos/$UPSTREAM/compare/$BRANCH...FORK_OWNER:FEATURE_BRANCH" --jq '{ahead_by, status}'

Evidence:

• flowsurface/aviu16: 7,000-line GPU shader heatmap only on shader-heatmap
• ArcticDB/DerThorsten: 147 commits across conda_build, clang, apple_changes
• pueue/FrancescElies: Duration display only on cesc/duration
• backtesting.py/blue-int: Critical CAGR math fix only on fix/cagr-and-annualized-return
• barter-rs: 6 of 12 top forks had work only on feature branches
• dukascopy-node: Top 3 forks had zero divergence on default branch

Rank 2: Upstream PR Cross-Reference

Why it's #2: The compare API breaks when branches are rebased or force-pushed. The only evidence of this work is in the upstream PR history.

Technique: List all PRs from fork authors against upstream.

gh api "repos/$UPSTREAM/pulls?state=all" --paginate \
  --jq '.[] | select(.head.repo.fork) | {number, title, state, user: .user.login}'

What it catches:

• Rebased work (pueue: ActuallyHappening's tracing-eyre refactor showed 0 ahead, but PR #604 had 421 additions)
• Merged contributions (forks show 0 ahead because work was accepted upstream)
• Declined PRs with valuable code the fork still maintains

Evidence:

• ArcticDB: mjpieters had 11 merged PRs but 0 ahead on all branches
• pueue: Mephistophiles had 3 PRs (dashboard, dark colors, clean-by-group)
• kokoro: 18 PRs from fork authors merged upstream

Rank 3: Tags/Releases on Fork

Why it's #3: The strongest signal of independent maintenance intent. Forks with their own release cycle are effectively independent projects.

gh api "repos/FORK_OWNER/REPO/tags" --jq '.[].name' | head -10
gh api "repos/FORK_OWNER/REPO/releases" --jq '.[] | {tag_name, published_at}' | head -5

Evidence:

• pueue/freesrz93: 6 releases spanning v5.x series, 7 new subcommands — the most substantive fork <!-- SSoT-OK: fork release tag names, not this repo's versions -->
• ArcticDB/ShabbirHasan1: RC tags revealing Man Group internal release cycle
• ArcticDB/qc00: Pre-release tags for Apple Silicon builds

Rank 4: Commit Email Domains

Why it's #4: Institutional contributors often work on forks without any social engagement (no stars, no issues). Email domains are the only signal.

gh api "repos/$UPSTREAM/compare/$BRANCH...FORK_OWNER:BRANCH" \
  --jq '.commits[].commit.author.email' | sort -u

Evidence:

• ArcticDB: @man.com (Man Group employees), @quantstack.net (QuantStack engineers)
• pymoo: University emails on algorithm implementation forks
• firecrawl: Company domains on self-hosting forks

Rank 5: Timestamp Clustering

Why it's #5: Bulk elimination of noise. Forks sharing exact pushed_at with upstream or with each other are mirrors created and abandoned.

gh api "repos/$UPSTREAM/forks" --paginate \
  --jq '.[] | {full_name, pushed_at}' | \
  jq -s 'group_by(.pushed_at) | map({pushed_at: .[0].pushed_at, count: length, forks: [.[].full_name]}) | sort_by(.count) | reverse'

Evidence: Eliminates 85%+ of all forks across every repository tested.

Rank 6: Cross-Fork Convergence

Why it's #6: When 3+ forks independently solve the same problem, it reveals unmet upstream demand — useful for roadmap decisions.

Technique: After analyzing individual forks, group by theme/feature area.

Evidence:

• firecrawl: 3 forks adopted Patchright for stealth browsing
• flowsurface: 3 forks added technical indicators independently
• barter-rs: 4 forks added Bybit exchange support
• kokoro: 2 independent batched inference implementations

Rank 7: Stars (Last Resort)

Why it's last: Empirically anti-correlated with actual fork value in every repository tested.

Evidence:

Meanwhile the most valuable forks consistently had 0 stars:

• pymoo/AnonymeMeow: 300 files changed, 2 new PSO algorithms
• pueue/freesrz93: 7 new subcommands, 6 releases
• ArcticDB/DerThorsten: 147 commits of platform enablement
• dukascopy-node/kyo06: Streaming API, npm-published

When stars ARE useful: As a tiebreaker between two forks with similar divergence, or to identify "community champion" forks that serve as social hubs (e.g., firecrawl/devflowinc-simple with 630 stars).