github-repo-discovery is a read-only research skill. It does not modify your filesystem outside of writing transient logs in the working directory. It does not modify your Claude Code installation. It does not call any service other than api.github.com and api.securityscorecards.dev.

The risk surface is therefore narrower than a typical skill, but not zero. The notable risks:

• GitHub rate-limit exhaustion. A pathological run could burn through your authenticated 30 req/min search budget. The skill respects Retry-After and explicit-sorts to minimise re-queries, but a malicious prompt could in principle make it loop.
• OpenSSF Scorecard outage. The skill defaults to a neutral 0.5 score if Scorecard is unreachable. This is by design (graceful degradation), but it means a poisoned DNS resolver could silently neutralise the Scorecard signal.
• Sub-agent prompt injection via README content. When the scorer fetches a candidate README to compute slop penalty, README content is treated as data and never executed. If you find a code path where README content escapes data context into instruction context, that's a security issue.
• Path traversal in score_repo.py. The script accepts an owner/repo arg and constructs URLs from it. If you find an input that escapes into shell or filesystem context, that's a security issue.

Security bugs are highest priority — report them privately, not via public issues.

Use GitHub's private vulnerability reporting:

1. Go to https://github.com/MJWNA/github-repo-discovery/security/advisories
2. Click Report a vulnerability
3. Describe the issue with reproduction steps

If you can't use private reporting for any reason, contact the maintainer directly via the email address listed on the @MJWNA GitHub profile.

The bar is "did the skill do something it wasn't supposed to do, where the consequence is loss of user data, escalated capability, or unauthorised disclosure?"

Specifically — these are security bugs:

• A way for the skill to make outbound network calls to anywhere other than api.github.com and api.securityscorecards.dev
• A way to write to the filesystem outside the current working directory
• A way for sub-agent output to escape data context (e.g. an injected gh command runs unintended actions)
• Path traversal in score_repo.py or verify_urls.sh
• Code execution from candidate README content during slop scoring
• A way to leak the GITHUB_PERSONAL_ACCESS_TOKEN value to a third party (e.g. by including it in a URL fetched from the network)

These are NOT security bugs (file as regular bugs):

• The score gives a wrong answer for some repo
• The slop detector misses obvious slop
• The category router picks the wrong strategy
• Performance issues
• Documentation errors

The maintainer aims to acknowledge security reports within 7 days and ship a fix or mitigation within 30 days for confirmed issues. Best-effort — this is an open-source project, not a commercial product.

The skill operates strictly within the current working directory and never touches anything outside that scope. If you find a way to make it operate outside that scope, that's a security issue.

After a fix ships, the security advisory will be published with credit to the reporter (unless they prefer to remain anonymous).