# /famm (cursor skill)

> Source: <https://gist.github.com/tomdonarski/581b9b3a38011f6aa23f78850788d615>
> Published: 2026-06-27 14:14:19+00:00

| name | famm |
|---|---|
| description | Fetches GitHub pull request metadata and diff via gh CLI from a PR URL, builds context, and confirms readiness without starting other work. Use when the user invokes /famm, @famm, or asks to familiarize with a GitHub PR link before continuing. |
| disable-model-invocation | true |

Use this skill only when the user explicitly invokes `/famm`

or `@famm`

.

Replace manual copy-paste of PR context. Given a human-friendly GitHub PR URL, fetch LLM-friendly metadata and diff via `gh`

, internalize them, then stop and confirm readiness. Do **not** implement, review, or answer unrelated questions until the user gives the next task.

Companion to `/fam`

(local `@`

paths). Use `/famm`

for GitHub PR URLs.

Accept any of these from the message (after `/famm`

or `@famm`

):

`https://github.com/{owner}/{repo}/pull/{number}`

- Same URL with
`/files`

,`.diff`

, or`.patch`

suffix — pass as-is to`gh`

; it accepts them.

Multiple PR URLs in one message: fetch each independently.

If no URL is provided, ask for the PR link.

`gh`

installed and authenticated. Verify this through the first metadata command rather than a separate sandboxed auth preflight.- Network access for
`gh api`

/`gh pr`

commands.

Cursor shell usage: run `gh`

commands with local keyring access enabled from the first command (for example, `required_permissions: ["all"]`

on Shell calls). Do **not** start with a sandboxed `gh auth status`

or sandboxed `gh pr`

command and wait for it to fail; on macOS the GitHub CLI often stores tokens in Keychain, which the default sandbox may not see.

If `gh`

fails even with local keyring access enabled, or fails for another reason such as `gh`

not being installed, an inaccessible private repo, or a genuinely unauthenticated account, report the error and stop.

**Never run bare gh pr view** (without

`--json`

). It fails on many repos with:

```
GraphQL: Projects (classic) is being deprecated … (repository.pullRequest.projectCards)
```

Always pass an explicit `--json`

field list, or use the REST fallback below.

-
**Collect PR URL(s)** from the invocation. Parse`{owner}`

,`{repo}`

,`{number}`

from each URL for fallback commands. -
**Fetch metadata**(one command per PR). In Cursor, use local keyring access on the Shell call.** Always**use`--json`

with an explicit field list:

```
gh pr view "<PR_URL>" --json title,body,author,additions,deletions,changedFiles,baseRefName,headRefName,commits,labels,state,url,number
```

Run metadata fetches in parallel when there are multiple PRs, and apply the same keyring-capable permissions to each `gh`

command.

**If that still fails** (GraphQL or other), fall back to the REST API:

```
gh api "repos/{owner}/{repo}/pulls/{number}" --jq '{
  number, title, body, state, url: .html_url,
  additions, deletions, changedFiles: .changed_files,
  author: {login: .user.login},
  baseRefName: .base.ref, headRefName: .head.ref,
  labels: [.labels[].name]
}'
```

Optional commit subjects (when useful for scope):

```
gh api "repos/{owner}/{repo}/pulls/{number}/commits" --jq '.[0:20][] | .commit.message'
```

**Check diff size** before loading full diff, again using local keyring access on the Shell call:

```
gh pr diff "<PR_URL>" | wc -c
```

Thresholds:

| Size | Action |
|---|---|
| ≤ 150 KB | Fetch full diff: `gh pr diff "<PR_URL>"` |
| > 150 KB | Fetch file list only: `gh pr diff "<PR_URL>" --name-only` . Internalize metadata + file list. Note in the reply that the diff was too large to load whole; offer to load specific paths if the user's next task needs them. |

For large PRs, load targeted diffs only when the user's follow-up requires code detail:

```
gh pr diff "<PR_URL>" -- path/to/file.rb
```

Repeat `--exclude`

patterns if the user asks to skip noise (lockfiles, generated assets):

```
gh pr diff "<PR_URL>" --exclude '*.lock' --exclude 'vendor/*'
```

-
**Synthesize**— from metadata + diff (or file list): purpose (title/body), scope (files changed, +/- lines), branch names, author, linked issue references in the body. -
**Confirm only**— reply that you are ready; do not start review or implementation.

Keep the reply short:

```
Ready. I reviewed PR #{number}:

- **{title}** — {one line: purpose / what it changes}
- **Scope** — {changedFiles} files, +{additions}/−{deletions}, `{headRefName}` → `{baseRefName}`
- **Author** — @{author.login}

Tell me what you’d like to do next.
```

If the diff was truncated due to size, add one line:

```
- **Diff** — file list only ({N} files); say which paths to load for a deeper pass.
```

Adjust for multiple PRs (one bullet block per PR).

- Paste the full diff or JSON metadata back to the user unless they explicitly ask.
- Use the rendered HTML PR page as the primary source.
- Start coding, reviewing, or planning unless the user asks in the same message.
- Run bare
`gh pr view`

without`--json`

(see pitfall above). - Claim readiness without fetching metadata (and diff or file list per size rules).

**User:** `/famm https://github.com/otwcode/otwarchive/pull/5907`

**Agent:** runs `gh pr view … --json …`

+ size check + `gh pr diff`

, internalizes, replies with readiness summary.

**User:** `/famm https://github.com/org/repo/pull/42`

then "review for N+1 queries"

**Agent:** already has context from step 1; proceed with the review task.