Exploring Aggregated Stats Across Multiple RepositoriesPublic

Agent

Claude Code

Model

Claude Opus 3

Shared

Feb 6, 5:11 PM

Messages71

Summary

I'd like to investigate using the new forges module as a way to drive git-pkgs to aggregate stats from across multiple repos, to give similar insights but at an "org" level

Let me start by understanding what's in this repo and what git-pkgs/forges looks like.

Listed/Users/andrew/code/git-pkgs/*

Ran sub-agentExplore git-pkgs codebase

Good overview. Let me look at the forges API more closely and the stats command to understand the building blocks.

Readforges.go

Readtypes.go

Listed/Users/andrew/code/git-pkgs/forges/*.go

Readstats.go

Let me check if forges already has org-level listing, and look at the GitHub backend and the roadmap.

Readgithub.go

Readroadmap.md

Readstats.go

GreppedListRepo|FetchOrg|ListOrg|org|organization

Listed/Users/andrew/code/git-pkgs/git-pkgs/internal/database/*.go

Let me check the Stats types and the database query structure.

Greppedtype Stats struct|type AuthorStats|type StatsOptions|type NameCount

Greppedfunc.*GetStats|func.*GetAuthorStats

Readgo.mod

Now I have a clear picture. Here's what I found and where I see this going.

Current state of forges: The module fetches metadata for individual repos (FetchRepository, FetchTags) across GitHub, GitLab, Gitea/Forgejo, and Bitbucket. It has no org-level listing -- it doesn't know how to enumerate repos for an owner/org. But the underlying SDKs (go-github, gitea/sdk, gitlab client-go) all support listing org repos.

The gap: There's no way to go from "give me an org name" to "here are all the repos and their aggregated dependency data." The orgs/ directory is empty, and git-pkgs is entirely per-repo today -- one SQLite database per repository.

What forges would need to add: A ListRepositories(ctx, owner) method on the Forge interface (or a separate OrgForge interface to avoid breaking existing implementations). Each backend would page through the forge API and return []Repository.

What the orgs module could then do:

Call forges.ListRepositories to get all repos for an org
Clone (shallow) or open each repo locally
Run git-pkgs indexing per repo (or read existing databases if already indexed)
Aggregate into org-level views

The interesting org-level insights, pulling from the roadmap and the existing stats structure:

Shared dependencies -- which packages appear across multiple repos, and at what versions
"Which repos use package X" -- the inverse query, already called out in the roadmap
Vulnerability exposure -- how many repos are affected by a given CVE
License compliance -- org-wide license inventory, flag repos with problematic licenses
Ecosystem breakdown -- how many npm vs gem vs pypi dependencies org-wide
Staleness -- which repos have the most outdated deps
Dependency churn -- which repos have the most dependency activity

A few design questions before going further:

Used AskUserQuestion

Good, that's clear. Two workstreams: extend forges with org listing, then build the orgs CLI here that drives git-pkgs across repos.

Let me plan the implementation.

Used EnterPlanMode

Ran sub-agentExplore forges module patterns

Ran sub-agentExplore git-pkgs CLI structure

Now let me design the implementation.

Ran sub-agentDesign orgs implementation plan

Let me verify a few details about the pkgs database schema and the dependency query before finalizing the plan.

Readqueries.go80 lines

Readschema.go

Good. I have everything I need. Let me also check one thing -- the SchemaVersion constant.

GreppedSchemaVersion\s*=

Now let me write the plan.

Used ExitPlanMode