docs(oss): add contributor PR triage criteria and a skill that applies them - #29961

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- target file ---'
sed -n '70,110p' skills-contrib/triage-contributor-pr/SKILL.md
printf '%s\n' '--- triage documentation references ---'
rg -n -C 4 -i 'DCO|sign.?off|merge commit|mechanical|trailer|author' docs/oss/pr-triage.md skills-contrib/triage-contributor-pr/SKILL.md
printf '%s\n' '--- relevant file outline ---'
ast-grep outline skills-contrib/triage-contributor-pr/SKILL.md --match jq --view expanded

Repository: prisma/prisma

Length of output: 13583

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- target file ---'
sed -n '70,110p' skills-contrib/triage-contributor-pr/SKILL.md
printf '%s\n' '--- documentation ---'
rg -n -C 5 -i 'DCO|sign.?off|merge commit|mechanical|trailer|author' docs/oss/pr-triage.md
printf '%s\n' '--- skill references ---'
rg -n -C 3 -i 'DCO|sign.?off|merge commit|mechanical|trailer|author|commits' skills-contrib/triage-contributor-pr/SKILL.md

Repository: prisma/prisma

Length of output: 10484

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- DCO policy ---'
rg -n -C 8 -i 'Developer Certificate|DCO|Signed-off-by|author' CONTRIBUTING.md
printf '%s\n' '--- commit fixture/data files ---'
git ls-files | rg '(^|/)(pr-[^/]+\.json|.*triage.*\.json|.*fixture.*)$' | head -80
printf '%s\n' '--- jq behavior: presence versus identity ---'
python3 - <<'PY'
import json, subprocess, textwrap
samples = [
    ("matching", "Fix bug\n\nSigned-off-by: Alice Example <alice@example.com>", "Alice Example <alice@example.com>"),
    ("mismatching", "Fix bug\n\nSigned-off-by: Bob Example <bob@example.com>", "Alice Example <alice@example.com>"),
    ("absent", "Fix bug\n", "Alice Example <alice@example.com>"),
]
expr = r'''if (.messageBody // "") | test("Signed-off-by:") then "YES" else "NO" end'''
for name, body, author in samples:
    obj = {"messageBody": body, "author": {"name": author.split(" <", 1)[0], "email": author.split("<", 1)[1][:-1]}}
    out = subprocess.check_output(["jq", "-r", expr], input=json.dumps(obj).encode()).decode().strip()
    print(f"{name}: author={author!r}, expression={out}")
PY

Repository: prisma/prisma

Length of output: 13522

🏁 Script executed:

#!/bin/bash
set -eu

file='skills-contrib/triage-contributor-pr/SKILL.md'
printf '%s\n' '--- target file: relevant sections ---'
sed -n '1,125p' "$file"

printf '%s\n' '--- references to statusCheckRollup, check-runs, and fetch instructions ---'
rg -n -C 3 'statusCheckRollup|check-runs|fetch|once|wip/pr-triage' "$file" docs/oss/pr-triage.md 2>/dev/null || true

printf '%s\n' '--- saved snapshot examples and schema references ---'
rg -n -C 3 'pr-[0-9]+\.json|statusCheckRollup|checkRuns|check-runs' . --glob '!node_modules' --glob '!dist' --glob '!build' 2>/dev/null | head -300

Repository: prisma/prisma

Length of output: 15322

🏁 Script executed:

#!/bin/bash
set -eu

python3 - <<'PY'
from pathlib import Path
import re

text = Path("skills-contrib/triage-contributor-pr/SKILL.md").read_text()
fetch = re.search(r'--json\s+([^\\\n]+)', text)
assert fetch, "Step 2 JSON selection was not found"
fields = [f.strip() for f in fetch.group(1).split(",")]
assert "statusCheckRollup" in fields
assert "headRefOid" not in fields
assert "headRefName" not in fields
assert "gh api .*check-runs" in text
print("Step 2 fields:", fields)
print("statusCheckRollup is saved:", "statusCheckRollup" in fields)
print("Separate check-runs API command present:", bool(re.search(r'gh api .*check-runs', text)))
print("Head SHA is not saved by the listed gh pr view fields:", "headRefOid" not in fields)
PY

Repository: prisma/prisma

Length of output: 239

🌐 Web query:

GitHub CLI gh pr view --json statusCheckRollup field CheckRun StatusContext documentation

💡 Result:

The statusCheckRollup field in the GitHub CLI (gh pr view --json statusCheckRollup) returns a collection of status checks for a pull request [1][2]. This field provides a union of two distinct object types representing different check systems: CheckRun (GitHub Actions) and StatusContext (legacy commit status checks like those from third-party CI services) [3][4]. Because these two types originate from different systems, their data structures and fields for reporting status differ [4]. When working with the output of statusCheckRollup, you should use the appropriate field based on the object type [5]: 1. CheckRun: Represents automated check runs (e.g., GitHub Actions). These use the conclusion field to report their outcome (e.g., SUCCESS, FAILURE, CANCELLED) [6][3][4]. Their status field (e.g., IN_PROGRESS, COMPLETED) reflects the lifecycle state rather than the final verdict [4]. 2. StatusContext: Represents legacy commit status checks. These do not have a conclusion field; instead, they report their outcome using the state field (e.g., SUCCESS, PENDING, FAILURE, ERROR) [3][4]. To programmatically determine the status of a check, a common practice is to prioritize the conclusion field, falling back to the state field if conclusion is null or absent [4][5]. This pattern allows you to handle both modern and legacy check systems consistently [3][5]. For more information on available fields for the gh pr view command, you can run the command without arguments for the --json flag: gh pr view --json (which lists all queryable JSON fields) [7]. Documentation for the command is available via gh help pr view or in the official GitHub CLI manual [8].

Citations:

• 1: https://man.archlinux.org/man/gh-pr-view.1.en
• 2: https://man.freebsd.org/cgi/man.cgi?manpath=FreeBSD+Ports+15.0.quarterly&query=gh-pr-view&sektion=1
• 3: kunchenguid/gh-axi@291fc1a
• 4: fix(pr): classify legacy commit statuses and red check runs correctly kunchenguid/gh-axi#71
• 5: https://github.com/zookanalytics/claude-devcontainer/blob/main/packages/git-workflow/commands/orchestrate.md
• 6: https://github.com/cli/cli/blob/trunk/api/queries_pr.go
• 7: https://cli.github.com/manual/gh_help_formatting
• 8: https://cli.github.com/manual/gh_pr_view

🏁 Script executed:

#!/bin/bash
set -eu

python3 - <<'PY'
from pathlib import Path

lines = Path("skills-contrib/triage-contributor-pr/SKILL.md").read_text().splitlines()
json_line = next(line for line in lines if "--json number,title" in line)
api_line = next(line for line in lines if "check-runs" in line)

fields = json_line.split("--json ", 1)[1].rstrip(" \\").split(",")
print("statusCheckRollup saved:", "statusCheckRollup" in fields)
print("saved field count:", len(fields))
print("separate check-runs request:", api_line.strip())
print("snapshot-only instruction:", any("Do not re-run `gh`" in line for line in lines))
PY

Repository: prisma/prisma

Length of output: 397

🌐 Web query:

site:cli.github.com/manual/gh_pr_view statusCheckRollup CheckRun StatusContext

💡 Result:

In the GitHub GraphQL API, StatusCheckRollup, CheckRun, and StatusContext are distinct components used to track and report the status of commits and pull requests [1][2]. StatusCheckRollup is an object that provides a consolidated view of the various status checks for a specific commit [2]. It acts as a wrapper or summary that includes both individual commit statuses and GitHub Actions/Check runs [2]. StatusContext represents an individual legacy commit status, often created by external integrations or tools that use the commit status API [3]. It contains details such as the state (e.g., success, failure, pending), context name, and target URL [3]. CheckRun refers to an individual execution of a check suite, which is part of the newer GitHub Checks API [1]. Unlike StatusContext, which is a simpler status report, a CheckRun typically provides more granular data, including output, annotations, and structured reports associated with a specific workflow or check [1]. These components are frequently used together when querying the state of a pull request or commit to determine if all required CI/CD processes have passed [4][2]. For example, the statusCheckRollup field on a commit allows you to fetch a summary of all these check and status types in one request [2].

Citations:

• 1: https://docs.github.com/en/enterprise-server@3.21/graphql/reference/meta
• 2: https://docs.github.com/en/enterprise-server@2.21/graphql/reference/objects
• 3: https://docs.github.com/enterprise/2.10/developer/v4/object/statuscontext
• 4: https://cli.github.com/manual/gh_pr_view

🏁 Script executed:

#!/bin/bash
set -eu

python3 - <<'PY'
from pathlib import Path

lines = Path("skills-contrib/triage-contributor-pr/SKILL.md").read_text().splitlines()
for i, line in enumerate(lines, 1):
    if "--json" in line or "statusCheckRollup" in line or "check-runs" in line:
        print(f"{i}: {line!r}")

start = next(i for i, line in enumerate(lines) if "--json" in line)
command = "\n".join(lines[start:start+3])
print("Step 2 command fragment:", repr(command))
print("statusCheckRollup occurs in Step 2 fragment:", "statusCheckRollup" in command)
print("statusCheckRollup occurrences in file:", sum("statusCheckRollup" in line for line in lines))
PY

printf '%s\n' '--- exact numbered source lines ---'
sed -n '48,56p;91,100p' skills-contrib/triage-contributor-pr/SKILL.md | cat -vet

Repository: prisma/prisma

Length of output: 2249

🌐 Web query:

GitHub CLI gh pr view --json statusCheckRollup official manual

💡 Result:

The statusCheckRollup field is an available field for the GitHub CLI command gh pr view when using the --json flag [1][2]. This field provides a summary of the CI/CD status checks associated with a pull request [3]. When running the command, you can specify this field as part of a comma-separated list of fields: gh pr view --json title,number,statusCheckRollup Note that statusCheckRollup is part of the standard list of supported JSON fields for the command [1][2]. However, it is important to be aware of the following technical considerations: 1. Permission Requirements: The field requires specific API permissions [4]. Users employing fine-grained personal access tokens (PATs) on organization-owned private repositories have reported issues where the command fails if the token lacks the necessary scopes to access status check information, as the command attempts to eagerly fetch this data [4]. 2. Data Specifics: Users have noted that the output of statusCheckRollup via gh pr view may differ in structure or content compared to data returned by the gh pr checks command [5]. 3. Troubleshooting: If you encounter errors (such as 403 Forbidden or "Resource not accessible") when using this field, you can work around the issue by explicitly requesting a subset of other fields in the --json flag that do not require those specific permissions [4].

Citations:

• 1: https://cli.github.com/manual/gh_pr_view
• 2: https://man.archlinux.org/man/gh-pr-view.1.en
• 3: https://cli.github.com/manual/gh_pr_status
• 4: gh pr view fails with fine-grained PAT on organization private repository due to statusCheckRollup access cli/cli#12597
• 5: Align JSON data between gh pr checks and gh pr view --json statusCheckRollup cli/cli#9091