Lovstudio Gh Access

lovstudio:gh-access

Grant, revoke, and audit collaborator access on private GitHub repos — by username or email, with read-only as the safe default.

Prerequisites

• gh CLI authenticated (gh auth status) with a token that has:
• repo scope (always)
• admin:org scope (if the target repo is org-owned; caller must be org owner or repo admin)
• The target repo exists and is accessible to the caller.

Subcommands

This skill has three modes. Pick based on the user's intent:

If intent is unclear, use AskUserQuestion to disambiguate.

Workflow

Step 0: Collect inputs via AskUserQuestion

ALWAYS collect the following BEFORE touching the API:

1. Target repo — <owner>/<repo> (e.g. lovstudio/private-demo). If the user is inside a git repo, pre-fill from gh repo view --json nameWithOwner -q .nameWithOwner. 2. Subcommand — grant / revoke / list. 3. (grant/revoke only) Identifiers — a whitespace- or comma-separated list of GitHub usernames and/or email addresses. Mixed is fine. 4. (grant only) Permission level — default pull (read-only). Offer:

• pull — read + issues + PRs (recommended default)
• triage — read + can label/close issues & PRs, no code write
• push — write access (⚠ confirm explicitly)
• maintain / admin — block unless user explicitly insists

Never silently escalate. If the user just says "给他权限" without specifying level, default to pull and state that clearly.

Step 1: Resolve identifiers → GitHub usernames

For each identifier in the list, follow this resolution chain and record the outcome per identifier (for the final summary report):

identifier → classify → resolve

Classification rule: an identifier containing @ is treated as an email, otherwise as a GitHub username.

Case A — looks like a username

1. Verify the account exists:

   gh api "users/<login>" --jq '.login' 2>/dev/null

2. If it returns the login → resolved as login, status user_ok. 3. If the call 404s → status user_not_found. Do NOT fall back to email invite (we don't have an email). Report and skip.

Case B — looks like an email

1. Search by email:

   gh api "search/users?q=<email>+in:email" --jq '.total_count, .items[0].login'

2. If total_count >= 1 and a login is returned → resolved as login, status email_to_user. 3. If total_count == 0 → fall back to email invite path:

• For org repos: gh api -X POST "orgs/<org>/invitations" -f email=<email> -f role=direct_member then add the pending member as an outside collaborator on the repo once they accept. Note: inviting directly-to-repo by email is not supported by the REST API for non-org personal repos — if the target is a personal repo, report email_no_account and ask the user to obtain the recipient's GitHub username.
• Status: email_invited (org) or email_no_account (personal repo).

Show the resolution table to the user before performing writes:

Ask the user to confirm before proceeding with writes. Skip user_not_found and email_no_account entries by default.

Step 2: Execute

grant

For each resolved username, issue a repo invitation:

gh api -X PUT "repos/<owner>/<repo>/collaborators/<login>" \
       -f permission=<pull|triage|push|maintain|admin>

• Response 201 = invitation sent (pending until recipient accepts).
• Response 204 = already a collaborator; permission was updated.
• Response 422 = user not found or already pending; inspect and report.

For org-repo email invites that resolved to email_invited above, no additional call is needed — the org invitation covers repo access once the user accepts. Tell the user to remind the recipient to check their email.

revoke

gh api -X DELETE "repos/<owner>/<repo>/collaborators/<login>"

• Response 204 = removed (or was never a collaborator — idempotent).
• For email-only identifiers with no resolved login: use

gh api -X DELETE "orgs/<org>/memberships/<login>" only if the user explicitly wants to remove from the whole org; otherwise skip and report.

Before executing revokes, show the list of logins that will be removed and ask for a final confirmation (revokes are visible to the recipient and can be socially awkward to reverse).

list

gh api "repos/<owner>/<repo>/collaborators?affiliation=all" \
       --jq '.[] | {login, permissions}' \
       --paginate

Also list pending invitations:

gh api "repos/<owner>/<repo>/invitations" --paginate \
       --jq '.[] | {invitee: .invitee.login, email, permissions, created_at}'

Present as two tables: Active collaborators and Pending invitations.

Step 3: Report

Show a final summary table for grant/revoke operations:

gh-access report — <owner>/<repo>
=================================
Granted (pull): alice, bobhub
Invited via email: carol@startup.io (pending org invite)
Skipped: typo-user (user_not_found)

Include the invitation URL the user can share manually if helpful: https://github.com/<owner>/<repo>/invitations

Rules

• Default to `pull` (read-only) unless the user explicitly names a higher

permission. State the chosen level clearly before executing.

• Never escalate to `admin`/`maintain` without an explicit, unambiguous

request — ask a confirming AskUserQuestion even if the user seemed to ask.

• Show the resolution table before writes. Clients mistyping a username is

common; showing the resolved login prevents inviting the wrong person.

• Idempotent revokes. A 204 on a non-collaborator is fine — don't panic.
• Batch-friendly. A single invocation can process a long mixed list;

execute resolution in parallel where possible, but keep writes sequential so partial failures are easy to report.

• Email invites only work cleanly for org repos. For personal repos

without a resolved username, stop and ask the user to obtain a GitHub username from the recipient.

• Private repos only are the typical case, but this skill works on public

repos too — no need to refuse.

Common gh CLI quick reference

# Who am I? What scopes do I have?
gh auth status

# Is this a repo I can admin?
gh api "repos/<owner>/<repo>" --jq '.permissions'

# Cancel a pending invitation
gh api -X DELETE "repos/<owner>/<repo>/invitations/<invitation_id>"

# Show org membership of a user
gh api "orgs/<org>/memberships/<login>" --jq '.role, .state'

Changelog

All notable changes to this skill are documented here. Format: Keep a Changelog · Versioning: SemVer

[0.1.2] - 2026-05-07

Fixed

• make direct clone install path configurable
• replace fixed runtime install directory with LOVSTUDIO_SKILLS_INSTALL_DIR

[0.1.1] - 2026-05-07

Fixed

• add release metadata
• add README version badge and changelog entry

lovstudio:gh-access

Grant, revoke, and audit collaborator access on private GitHub repos — by GitHub username or email address — with read-only as the safe default.

Use when you want to share a private repo with a client or contractor without making the repo public.

Install

npx skills add lovstudio/gh-access-skill

Or clone directly:

git clone https://github.com/lovstudio/gh-access-skill \
          "${LOVSTUDIO_SKILLS_INSTALL_DIR:?Set LOVSTUDIO_SKILLS_INSTALL_DIR}/lovstudio-gh-access"

Prerequisites

• `gh` CLI authenticated (gh auth status)
• Token scopes: repo (always), admin:org (for org-owned repos)
• You must be a repo admin (personal repo) or org owner / repo admin (org repo)

What it does

                 ┌──────────────────────────────────────────────┐
  Client input:  │  alice                                       │
  "give these    │  bob@example.com                             │
  folks access"  │  carol@startup.io                            │
                 │  typo-user                                   │
                 └──────────────────┬───────────────────────────┘
                                    ▼
                    ┌───────────────────────────────┐
                    │  Resolve each identifier      │
                    │  • username → verify exists   │
                    │  • email → search by email    │
                    │           → org invite fallback│
                    └───────────────┬───────────────┘
                                    ▼
                ┌───────────────────────────────────────────┐
                │  Show resolution table, confirm           │
                └───────────────────┬───────────────────────┘
                                    ▼
                ┌───────────────────────────────────────────┐
                │  PUT /repos/{owner}/{repo}/collaborators  │
                │  (permission=pull by default)             │
                └───────────────────┬───────────────────────┘
                                    ▼
                          Invitation emails sent

Subcommands

Permission levels

The skill defaults to `pull` and requires an explicit request to escalate.

Usage examples

Invite one client by email (org repo)

User: 把 acme/internal-dashboard 开给 client@acme.com，只读
→ Skill resolves client@acme.com:
    - If they have a GitHub account with that email → invite by username
    - If not → send org invite by email (pending until they create / link account)
→ Permission: pull

Batch invite mixed list

User: 给这几个人开 lovstudio/handoff-bundle 的权限:
      alice
      bob@startup.io
      carol-github

→ Skill resolves all three, shows a table, asks to confirm,
  then issues 3 PUT calls with permission=pull.

List who has access

User: 谁现在能访问 lovstudio/handoff-bundle?
→ Skill shows:
    Active:    alice (pull), carol-github (push)
    Pending:   bob@startup.io (pull, invited 2d ago)

Revoke

User: 把 alice 从 lovstudio/handoff-bundle 踢出去
→ Skill confirms, then DELETEs the collaborator.

Resolution statuses

When processing a mixed list, each identifier ends up in one of these buckets:

Safety defaults

• Read-only (pull) unless explicitly overridden
• Always show a resolution table before writing
• Ask to confirm before batch revokes
• Escalation to admin / maintain requires explicit secondary confirmation
• Writes are sequential so partial failures are legible in the report

License

MIT