should-i-contribute

An agent skill that researches any open-source repository end to end and answers the one question that matters before you invest time: should you contribute to it?

Verdict: GO · GO-IF · NO-GO — backed by computed numbers, not vibes.

Inspired by Tanay Kumar's opencode contribution-health thread, which showed that PR acceptance is a much better signal of open-source health than PR volume — a project can look busy while quietly ignoring everyone outside the core team. This skill turns that analysis into a repeatable, evidence-backed pipeline.

A note on intent

This skill is for people who want to research a repository before contributing — understanding how a project actually treats contributors is how you decide where your time goes.

It is not a merge-odds maximizer. Contributing to open source should not be motivated by "will my PR get merged" — contribute because the project solved something you needed, or because you enjoy solving the problem. The verdict is context for that decision, not the reason to contribute.

Install

npx skills add definitelynotchirag/should-i-contribute

What it produces

One markdown report with nine sections:

  1. Executive summary — the GO / GO-IF / NO-GO verdict plus headline numbers
  2. Snapshot — identity, stats, license, stack
  3. Momentum — is it alive and shipping? commits/wk, releases, bus factor
  4. Contribution landscape — the core: open-PR census and age buckets, outside-author share, exact merge rates (sampled on closed-at), first-timer funnel outcomes
  5. Issue health — stale bugs, documented bugs with fix PRs sitting unmerged
  6. Governance & maintainability — who actually merges, single-gate risk, docs/templates
  7. Community sentiment — HN/Reddit/Discord signals, maintainer quotes
  8. Risks & opportunities for the requester
  9. Methodology & caveats — every number sourced, every sample labeled

The verdict

Verdict Meaning
GO Outside PRs merge at healthy rates; maintainers respond; a contribution has a realistic path. Contribute.
GO-IF Viable only under stated conditions ("small, well-scoped bug fixes merge; features don't"). Contribute IF the conditions hold.
NO-GO Outside PRs mostly ignored, single-gate merges, ghost town, or source-available-not-OSS ("open source in name only"). Don't invest.

Installation

This is a single-skill repo — the skill file is SKILL.md. Copy or symlink the directory into your agent's skill root:

git clone https://github.com/definitelynotchirag/should-i-contribute.git ~/.agents/skills/should-i-contribute
# or point any agent at it:
ln -s "$(pwd)/should-i-contribute" ~/.claude/skills/should-i-contribute   # Claude Code
ln -s "$(pwd)/should-i-contribute" ~/.codex/skills/should-i-contribute    # Codex

Usage

Ask your agent: "should I contribute to {owner}/{repo}?" or "is this project worth contributing to?" — the skill runs the whole pipeline and prints the report. It also works on any host with an API (GitLab, Gitea) and degrades to git log analysis for self-hosted repos with no API.

Requirements:

  • gh CLI authenticated (recommended, 5,000 req/hr) or a GITHUB_TOKEN
  • ~25–45 API requests for a 7–14-day window run; ~90+ for a full 90-day run (60 req/hr unauthenticated — shrink the window if rate-limited; never fabricate numbers)

Methodology highlights

The hard-won API gotchas, encoded so you don't have to rediscover them:

  • Merge rates are sampled on closed_at via half-open day slices — never pulls?state=closed pages (created-ordered, not closed-ordered) and never sort=updated/sort=created search sampling (empirically biased: measured 0/100 merged in a window whose true rate was 41%).
  • Merged status comes from .pull_request.merged_at — the top-level merged_at field is always null in search results.
  • closed:A..B with day-only bounds is inclusive of both full days (spans B−A+1). The skill uses explicit T00:00:00Z hour bounds so slices and the aggregate window cover exactly N full days, then enforces a fetched == total_count invariant before reporting any rate.
  • PR↔issue linkage comes from the issue timeline's cross-referenced events (PR-only), with the closing reference verified in the PR body — a bare search/issues?q=<number> hit is full-text and proves nothing.
  • Renamed repos: GitHub search doesn't index redirect targets — resolve the canonical name via repos/{owner}/{repo} first.

Sample metrics (anomalyco/opencode, researched 2026-08-10)

The numbers the pipeline produces for the repo that inspired the skill:

Metric Value
Open PRs 1,206 (page 1: 93% outside core)
Merge rate, 90-day closed window (n=6,262) 41.7%
Merge rate, July 2026 (n=1,819) 59%
Merge rate, exact week Aug 4–10 (n=262) 81.3% — but NONE-association authors 0/40 (0%)
First-timer outcomes (same week) CONTRIBUTOR 147/153 merged; NONE 0/40
Open issues 3,815 (metadata open_issues_count includes PRs)
Commits 52/52 weeks active; releases ~every 2 days

A reading of these numbers: busy project, healthy core throughput, near-zero acceptance for drive-by outsiders — the pattern this skill is built to detect. These signals would weigh toward NO-GO for a first-time outside contributor, subject to the remaining phases (issue health, governance, community sentiment).

License

MIT