Audit Repo Issues

Audit repository issues and PRs

Analyze a GitHub repository's open and closed issues and PRs to identify opportunities for the current project (the one in the working directory). The target repo is provided as $ARGUMENTS (e.g., python-distro/distro).

Goal

Produce a structured report covering:

1. Popular unaddressed feature requests — open issues with high engagement (reactions, comments) that have stalled or been explicitly deferred.
2. Dismissed feature requests — closed issues where maintainers rejected a popular idea, especially if it aligns with the current project's scope.
3. Abandoned or rejected PRs — unmerged PRs that proposed valuable features, scope expansions, or new platform/detection support.
4. Merged PRs worth noting — features that were added and could inform what the current project should also support.
5. Maintenance and trust signals — evidence of maintenance gaps (stale PRs, slow releases, unanswered issues) that position the current project as a healthier alternative.
6. Detection techniques or data sources — novel approaches proposed in issues/PRs that the current project could adopt.
7. Commercial posture — whether the target is fully open-source, open-core-light, open-core-heavy, or fully proprietary, and which essential features (if any) live behind a paid tier.
8. Retirement and acquisition signals — explicit notices that the project has been formally retired, superseded, or acquired with the roadmap shifted to a successor commercial product.

Workflow

Phase 1: Understand the current project

1. Read the current project's CLAUDE.md, readme.md, or pyproject.toml to understand its scope, architecture, and what it already supports.
2. This context determines what counts as "relevant" when scanning the target repo.

Phase 2: Gather data from the target repo

Use gh CLI exclusively. Run these searches in parallel where possible:

# Open issues sorted by reactions (most popular first).
gh issue list -R $ARGUMENTS --state open --limit 100 --json number,title,labels,reactionGroups,comments,createdAt

# Closed issues (look for rejected feature requests).
gh issue list -R $ARGUMENTS --state closed --limit 200 --json number,title,labels,reactionGroups,comments,createdAt,closedAt

# Open PRs (potentially stalled).
gh pr list -R $ARGUMENTS --state open --limit 50 --json number,title,createdAt,comments

# Closed PRs (look for unmerged/rejected).
gh pr list -R $ARGUMENTS --state closed --limit 100 --json number,title,mergedAt,closedAt,comments,createdAt

Phase 3: Triage and deep-dive

1. Rank issues by engagement: sort by total reactions + comment count.
2. Identify feature requests: filter out pure bug reports — focus on enhancement requests, scope expansions, and architectural proposals.
3. Deep-dive into top candidates: for the ~20 most promising issues/PRs, fetch full details:

   gh issue view -R $ARGUMENTS {number} --json title,body,comments,reactionGroups,labels,state,closedAt
   gh pr view -R $ARGUMENTS {number} --json title,body,comments,state,mergedAt,closedAt

4. Check for current-project mentions: search for the current project's name in the target repo's issues to see if users have already referenced it as an alternative.

Phase 3b: Commercial posture and retirement check

For repos that ship a product (tools, datasets, projects — not articles or curation lists), evaluate the commercial posture and retirement signals. These rarely surface in issues/PRs, so check the repo metadata, README, and external pages directly.

# Repo metadata: license, archive flag, latest push, latest release, homepage URL.
gh repo view $ARGUMENTS --json name,description,homepageUrl,licenseInfo,isArchived,pushedAt,latestRelease

# README contents (look for "premium features", "Enterprise", "Cloud", retirement notices).
gh api repos/$ARGUMENTS/readme --jq '.content' | base64 -d

# Top-level directory listing (look for ee/, enterprise/, pro/ folders that may carry a non-OSS license).
gh api repos/$ARGUMENTS/contents

Then assess each axis below. The first three define the commercial posture; the last two cover retirement.

Classify the project as one of: fully OSS, open-core-light (some advanced compliance/integrations gated, core works in OSS), open-core-heavy (essential features gated), fully proprietary (no usable OSS), retired, or acquisition-drifted. Spell out which essential features (per the current project's domain) are gated, if any.