Upstream Recon

Investigate an open-source project before interacting with it — PRs, issues, or comments. Use BEFORE: filing an issue, submitting a PR, or commenting on an e...

Security Scan

The skill's purpose and instructions match (it analyzes GitHub repos), but it omits and assumes key runtime requirements (notably the gh CLI and associated GitHub auth), creating an incoherence you should understand before trusting it.

Purpose & Capability

The skill claims to analyze GitHub repos and its SKILL.md explicitly instructs the agent to use the `gh` CLI for all queries. However, the declared requirements list no required binaries or credentials — a mismatch. A reconnaissance skill reasonably needs `gh` (or equivalent) and access to the user's GitHub auth, so the manifest is incomplete.

Instruction Scope

Instructions stay on-purpose (repo metadata, issues, PRs, comments). They instruct reading issue/PR comments and contributor histories using `gh`. They do not tell the agent to read unrelated local files or exfiltrate data. However, they assume the agent may access repository data (public or private) via the user's GitHub credentials without explicitly stating that scope or permission model.

Install Mechanism

This is instruction-only with no install spec or code files, so nothing is written to disk by the skill itself. That minimizes install-time risk.

Credentials

The skill declares no required environment variables or primary credential, but runtime use of `gh` will use whatever GitHub auth is configured for the agent (gh auth token or cached session). The skill should have declared the dependency on `gh` and documented that it will use the agent's GitHub credentials; omission is an oversight that affects proportionality and user consent.

Persistence & Privilege

The skill is not always-enabled and does not request any persistent system presence or elevated privileges. It does not modify other skills or system settings per the provided files.

What to consider before installing

This skill appears to do what it claims (analyze a repo's issues/PRs/maintainer behavior), but it assumes the `gh` CLI is installed and will use the agent's GitHub authentication (which could include access to private repos). Before installing or invoking it: ensure you have `gh` installed and understand which GitHub account/token the agent will use; do not run it if you don't want the agent to query private repositories with your credentials. Ask the skill author to update the manifest to declare `gh` as a required binary and to document that it uses the agent's GitHub auth; if you need stricter isolation, run these `gh` queries yourself or in an environment with limited credentials.

Investigate a repo's culture and existing threads before interacting. Prevents duplicate issues, wasted PR effort, and uninformed comments.

Arguments: <owner/repo> [topic-keyword]

Procedure

Use gh CLI throughout. Run independent queries in parallel.

1. Repo metadata — stars, forks, license, last push date, archived status
2. Top 10 contributors — commit counts. Is it one person with 90%+ commits?
3. Existing issues search — search open AND closed issues for the topic keyword. Check for duplicates, prior art, and maintainer responses. Report what was found.
4. Recent 30 PRs (all states) — get the lay of the land
5. Merged PRs (last 20) — who merges them? How fast? What types get accepted?
6. Closed-without-merge PRs (last 50, filter mergedAt == null) — deep-dive 2-3 notable rejections: read comments for maintainer reasoning
7. Open PRs — how many sit with 0 reviews? For how long?
8. Topic deep-dive (if keyword given) — read comments on 2-3 most relevant existing issues/PRs to understand maintainer sentiment and community workarounds

Analysis Dimensions

• Governance: Solo maintainer / small team / community-driven
• External PR reception: Welcoming / selective (bugs yes, features no) / closed shop
• Issue responsiveness: How fast do maintainers respond to issues? Do they engage or auto-close?
• Merge velocity: Days from open to merge for external contributors
• Rejection patterns: Ghosted? "Building it myself"? "File issue first"? Bot auto-closed?
• Topic overlap: Has this been attempted or discussed before? Active workarounds?

Recommendation

End the report with one of:

• MERGE-LIKELY — project merges external feature PRs, no competing work, maintainer receptive
• MERGE-UNLIKELY — maintainer builds features themselves, similar PRs closed/ignored, feature contradicts direction
• FILE-ISSUE-FIRST — feature not yet discussed, maintainer is selective but responsive to issues, gauge interest before coding
• COMMENT-ON-EXISTING — existing issue/PR already covers this, add your workaround or +1 there instead
• DUPLICATE-EXISTS — exact issue already filed, do not create another

Include concrete next steps (e.g., "comment on #13738 with your workaround", "start with a bug fix PR to build credibility", "file an issue referencing #189", "fork and maintain independently").