/famm (cursor skill)

A developer created a Cursor skill called /famm that fetches GitHub pull request metadata and diffs via the gh CLI from a PR URL, builds context, and confirms readiness without starting other work. The skill replaces manual copy-paste of PR context by fetching LLM-friendly metadata and diff, then stops and waits for the user's next task.

| 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.