agentleFS
oocxoocx/tfplan2md/.agents/skills/view-pr-github/SKILL.md

view-pr-github

Skill174 starsChanged 2 months agoMITView on GitHub

View GitHub PR status/details using GitHub MCP tools (preferred) or gh CLI (fallback).

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 5 are distinctive, and 9 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 9

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read pull request status/details from GitHub.

    line 11
  2. Distinctive:

    FIRST: Use GitHub MCP tools - stable, structured, no pager/editor issues

    line 15
  3. Very specific:

    SECOND: Use scripts/pr-github.sh wrapper (for create/merge only)

    line 16
  4. Very specific:

    LAST: Use gh CLI as final fallback

    line 17
  5. Very specific:

    Use this skill for read-only PR inspection (status, checks, reviewers, files, body).

    line 19
  6. Distinctive:

    Use these GitHub MCP tools for PR operations:

    line 23
  7. Distinctive:

    Prefer GitHub MCP tools when they can answer the question

    line 132
  8. Very specific:

    If using gh, use a non-interactive pager for every gh call:

    line 133
  9. Very specific:

    Use GH_PAGER=cat (gh-specific, overrides gh's internal pager logic)

    line 134
  10. Very specific:

    Prefer structured output (--json) and keep output small with --jq when practical

    line 136
  11. Very specific:

    Never run plain gh ... without GH_PAGER=cat (it may open less and block)

    line 137
  12. Very specific:

    Never change global GitHub CLI config (no gh config set ...)

    line 138
  13. Distinctive:

    Use this prefix for every command:

    line 142
  14. Very specific:

    Rule of thumb: Always start with GitHub MCP tools.

    line 190

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

View PR (GitHub)

Purpose

Read pull request status/details from GitHub.

Priority order:

  1. FIRST: Use GitHub MCP tools - stable, structured, no pager/editor issues
  2. SECOND: Use scripts/pr-github.sh wrapper (for create/merge only)
  3. LAST: Use gh CLI as final fallback

Use this skill for read-only PR inspection (status, checks, reviewers, files, body). For creating/merging PRs, use the create-pr-github skill.

GitHub MCP Tools (Preferred)

Use these GitHub MCP tools for PR operations:

PR Details and Metadata

github-mcp-server-pull_request_read
  method: "get"
  owner: "oocx"
  repo: "tfplan2md"
  pullNumber: 123

Returns: PR number, title, state, body, author, timestamps, merge status, etc.

PR Diff

github-mcp-server-pull_request_read
  method: "get_diff"
  owner: "oocx"
  repo: "tfplan2md"
  pullNumber: 123

Returns: Full diff of the PR changes

PR Status Checks

github-mcp-server-pull_request_read
  method: "get_status"
  owner: "oocx"
  repo: "tfplan2md"
  pullNumber: 123

Returns: Status of CI/CD checks, required checks, conclusion

PR Changed Files

github-mcp-server-pull_request_read
  method: "get_files"
  owner: "oocx"
  repo: "tfplan2md"
  pullNumber: 123
  perPage: 100

Returns: List of files changed with stats (additions, deletions, changes)

PR Review Comments (inline on code)

github-mcp-server-pull_request_read
  method: "get_review_comments"
  owner: "oocx"
  repo: "tfplan2md"
  pullNumber: 123
  perPage: 100

Returns: Code review comments with file paths, line numbers, and comment bodies

PR Reviews

github-mcp-server-pull_request_read
  method: "get_reviews"
  owner: "oocx"
  repo: "tfplan2md"
  pullNumber: 123
  perPage: 100

Returns: Review submissions with state (APPROVED, CHANGES_REQUESTED, etc.)

PR Conversation Comments

github-mcp-server-pull_request_read
  method: "get_comments"
  owner: "oocx"
  repo: "tfplan2md"
  pullNumber: 123
  perPage: 100

Returns: General conversation comments on the PR

List PRs

github-mcp-server-list_pull_requests
  owner: "oocx"
  repo: "tfplan2md"
  state: "open"  # or "closed", "all"
  perPage: 30
  page: 1

Returns: List of PRs with basic metadata

GitHub CLI Fallback (Last Resort)

⚠️ Only use when GitHub MCP tools are unavailable

Hard Rules

  • Prefer GitHub MCP tools when they can answer the question
  • If using gh, use a non-interactive pager for every gh call:
    • Use GH_PAGER=cat (gh-specific, overrides gh's internal pager logic)
    • Also set GH_FORCE_TTY=false to reduce TTY-driven behavior
    • Prefer structured output (--json) and keep output small with --jq when practical
  • Never run plain gh ... without GH_PAGER=cat (it may open less and block)
  • Never change global GitHub CLI config (no gh config set ...)

Fallback gh Patterns

Use this prefix for every command:

GH_PAGER=cat GH_FORCE_TTY=false gh ...

View PR Summary

GH_PAGER=cat GH_FORCE_TTY=false gh pr view <pr-number> \
  --json number,title,state,isDraft,url,mergeStateStatus,reviewDecision

View Status Checks

GH_PAGER=cat GH_FORCE_TTY=false gh pr view <pr-number> \
  --json statusCheckRollup \
  --jq '.statusCheckRollup[] | {name, status, conclusion}'

View Reviews

GH_PAGER=cat GH_FORCE_TTY=false gh pr view <pr-number> \
  --json latestReviews,reviewRequests \
  --jq '{latestReviews: [.latestReviews[] | {author: .author.login, state, submittedAt}], reviewRequests: [.reviewRequests[].login]}'

When To Use Different Approaches

Prefer GitHub MCP Tools when

  • You need structured PR metadata (details, changed files, status checks, comments, reviews)
  • You want to avoid terminal-side pitfalls (auth prompts, pager behavior, large output)
  • You want operations that can be permanently allowed in VS Code
  • You are in any interactive agent session

Prefer Wrapper Scripts when

  • You're creating or merging a PR: use scripts/pr-github.sh create / scripts/pr-github.sh create-and-merge

Prefer gh CLI when (rare)

  • You need an API surface the MCP tools don't expose (use gh api for custom calls)
  • You need commands for Maintainers to reproduce locally
  • A maintainer explicitly requests CLI examples

Rule of thumb: Always start with GitHub MCP tools; only fall back to wrapper scripts for create/merge, and only use gh CLI as final resort.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.