GitHub Org Permission Auditor

What this skill does

Walks a GitHub organization, lists every member and outside collaborator, and joins the data with each user's last public activity. Flags overprivileged users (admin role with no recent activity) and stale collaborators.

Inputs

• org: the GitHub organization slug.
• GITHUB_TOKEN env var with read:org and repo scopes.
• Optional stale_days: defaults to 90.
• Optional skip_users: regex or list of usernames to exclude (bots, system accounts).

Steps

1. List all members: gh api orgs/<org>/members --paginate --jq '.[].login'.
2. List admins: gh api orgs/<org>/members --paginate --jq '.[] | select(.role=="admin") | .login' via the ?role=admin query.
3. List outside collaborators per repo: gh api repos/<org>/<repo>/collaborators?affiliation=outside.
4. For each user, fetch the user object (gh api users/<login>) and capture created_at, updated_at.
5. Determine last activity: gh api users/<login>/events?per_page=1 returns the most recent public event with created_at. Compare to today.
6. For each org admin, double-check their team memberships: gh api orgs/<org>/teams/<team>/members. Owners-of-everything is the worst pattern.
7. Detect dormant SSH/PAT keys per user when accessible (org SAML integrations expose this; otherwise note the limitation).
8. Apply rules:
   • Admin + no activity in stale_days -> overprivileged-stale (high).
   • Outside collaborator + no commits in stale_days -> stale-collaborator (medium).
   • Member with admin in any single repo (vs owner role) -> repo-admin (low).
9. Emit a CSV plus a markdown summary.

Output

org-permission-audit.csv (one row per user-role combination) and org-permission-audit.md (top findings, charts of role distribution, action checklist). Exit 1 if any overprivileged-stale entry exists.

Verification

Pick three flagged users and verify by visiting their profile and checking the "Last activity" indicator in the org's people page. For each suggested removal, confirm the user is not the sole owner of any active repo. After remediation, rerun the audit and confirm the user list shrinks as expected.

Edge cases

• Users with private contribution graphs: events API may show empty even if active; treat with lower confidence and flag for manual review.
• Service accounts / bots: identify by bot suffix or naming convention; exclude via skip_users.
• SAML-enforced orgs without explicit SCIM data: rely on the org member list as ground truth.
• Suspended users: surface with a suspended tag rather than as overprivileged.