pr-github-ops

$npx mdskill add superagent-ai/skills/pr-github-ops

Posts Superagent PR scan findings as inline GitHub review comments.

  • Posts security findings as inline PR review comments instead of thread comments.
  • Depends on authenticated gh CLI and pr-scan-context.json for repo metadata.
  • Reads pr-scan-context.json to determine owner, repo, PR number, and findings.
  • Uses gh API to create review comments anchored to specific diff lines.

SKILL.md

.github/skills/pr-github-opsView on GitHub ↗
---
name: pr-github-ops
description: Post Superagent PR security scan findings as inline GitHub pull request review comments using the authenticated gh CLI. Use whenever you need to comment on a PR scan finding, manage Superagent PR labels, complete a GitHub check run, or avoid posting findings as general PR thread comments. Trigger for any Superagent sandbox PR scan handoff that owns GitHub side effects via gh.
---

# PR GitHub operations

Superagent PR scans run in a sandbox with an authenticated `gh` CLI. You own GitHub side effects after handoff: inline finding comments, managed labels, and check-run completion.

Read `pr-scan-context.json` first. It contains `owner`, `repo`, `prNumber`, `headSha`, `checkRunId`, `reviewedFindingPaths`, and `dismissedFingerprints`.

## Critical rule: inline comments, not thread comments

`gh pr comment` creates **issue comments** on the PR conversation thread. That is wrong for actionable findings.

For each finding with a changed file and diff line, post a **pull request review comment** anchored to that line in the Files changed view.

| Goal | Wrong | Right |
|------|-------|-------|
| Comment on a finding at a diff line | `gh pr comment` | `gh api` review comment or review with `comments[]` |
| Summary-only note with no line anchor | `gh pr comment` is acceptable | optional |

If you already posted findings with `gh pr comment`, delete those issue comments and repost inline before finishing the scan.

## Inspect before posting

```bash
owner=OWNER
repo=REPO
pr=PR_NUMBER

# Existing inline review comments
gh api "repos/${owner}/${repo}/pulls/${pr}/comments" --paginate

# Existing general PR thread comments (avoid duplicating here)
gh api "repos/${owner}/${repo}/issues/${pr}/comments" --paginate

# PR diff files and patches (confirm path + line are in the diff)
gh api "repos/${owner}/${repo}/pulls/${pr}/files" --paginate
```

Skip findings when:
- `file` is in `reviewedFindingPaths`
- fingerprint already exists in an inline comment
- you already posted an inline finding on that `file` this run (one inline finding per file)

## Finding comment body format

Every finding comment must include the Superagent marker and fingerprint.

```markdown
<!-- brin-pr-finding -->
**P0:** Workflow uses pull_request_target trigger for untrusted fork PRs

Short evidence sentence here.

Short recommendation sentence here.

<!-- superagent-finding-fingerprint:HEX_SHA256 -->
```

Severity to priority: `critical` → P0, `high` → P1, `medium` → P2, `low` → P3.

Fingerprint: SHA-256 of the normalized comment body **before** appending the fingerprint line. Lowercase, collapse whitespace, remove the marker and any existing fingerprint comment.

```bash
body='<!-- brin-pr-finding -->
**P1:** Overly broad permissions: write-all in privileged workflow

Grants broad write access to GITHUB_TOKEN.

Replace with least-privilege job permissions.'

printf '%s' "$body" \
  | sed 's/<!-- brin-pr-finding -->//g' \
  | tr '[:upper:]' '[:lower:]' \
  | tr -s '[:space:]' ' ' \
  | sed 's/^ //;s/ $//' \
  | sha256sum \
  | awk '{print $1}'
```

Append the fingerprint as the last line of the comment body.

Use `short_evidence` and `short_recommendation` in inline comments. Keep them terse.

## Post inline review comments with gh api

`line` must be a line number on the **RIGHT** (added) side of the PR diff for `path`. Confirm with the PR files API or diff before posting.

### Single inline comment

```bash
head_sha=HEAD_SHA_FROM_CONTEXT

gh api \
  "repos/${owner}/${repo}/pulls/${pr}/comments" \
  -X POST \
  -f commit_id="$head_sha" \
  -f path=".github/workflows/example.yml" \
  -f side=RIGHT \
  -F line=12 \
  -f body="$comment_body"
```

Use `-F line=12` for numeric fields. Use `-f` for strings.

### Batch inline comments (preferred for multiple findings)

Write `review.json`:

```json
{
  "commit_id": "HEAD_SHA",
  "event": "COMMENT",
  "body": "<!-- brin-pr-finding -->\nSuperagent found 2 security concern(s).",
  "comments": [
    {
      "path": ".github/workflows/example.yml",
      "line": 4,
      "side": "RIGHT",
      "body": "<!-- brin-pr-finding -->\n**P0:** ...\n\n...\n\n<!-- superagent-finding-fingerprint:abc123... -->"
    },
    {
      "path": ".github/workflows/example.yml",
      "line": 8,
      "side": "RIGHT",
      "body": "<!-- brin-pr-finding -->\n**P1:** ...\n\n...\n\n<!-- superagent-finding-fingerprint:def456... -->"
    }
  ]
}
```

Post it:

```bash
gh api \
  "repos/${owner}/${repo}/pulls/${pr}/reviews" \
  -X POST \
  --input review.json
```

Post at most 50 inline comments per review. If you have more findings, split across multiple reviews.

### Fallback when no diff line exists

Only when a finding has no valid `file` + `line` in the PR diff, post a single consolidated issue comment:

```bash
gh api \
  "repos/${owner}/${repo}/issues/${pr}/comments" \
  -X POST \
  -f body="$fallback_body"
```

Never post the same finding both inline and on the thread.

## Delete stale or misplaced comments

```bash
# Delete inline review comment
gh api "repos/${owner}/${repo}/pulls/comments/COMMENT_ID" -X DELETE

# Delete general PR thread comment
gh api "repos/${owner}/${repo}/issues/comments/COMMENT_ID" -X DELETE
```

Delete stale Superagent finding comments whose fingerprints are no longer in the current findings set. Delete thread comments you replaced with inline comments.

## Managed labels

Only touch Superagent managed labels. Preserve all unrelated labels.

```bash
gh pr edit "$pr" --repo "${owner}/${repo}" --add-label "pr:flagged"
gh pr edit "$pr" --repo "${owner}/${repo}" --remove-label "pr:verified"
```

Clean scan:

```bash
gh pr edit "$pr" --repo "${owner}/${repo}" --remove-label "pr:flagged" --add-label "pr:verified"
```

## Complete the check run

Use `checkRunId` from context. Always set `status=completed`.

```bash
check_run_id=CHECK_RUN_ID_FROM_CONTEXT

gh api \
  "repos/${owner}/${repo}/check-runs/${check_run_id}" \
  -X PATCH \
  -f status=completed \
  -f conclusion=action_required \
  -f 'output[title]=PR requires security review' \
  -f 'output[summary]=2 security concern(s) detected.' \
  -f 'output[text]=Optional longer details.'
```

Conclusions:
- `success` — clean scan
- `action_required` — findings need review
- `neutral` — inconclusive scan

## End-to-end workflow

1. Read `pr-scan-context.json` and PR input JSON.
2. Run security analysis (other skills) and produce findings with `file`, `line`, `severity`, `title`, `short_evidence`, `short_recommendation`.
3. List existing inline and thread comments; compute fingerprints; skip dismissed/reviewed/duplicate findings.
4. Post findings as inline review comments with `gh api` (single comment or batch review). Do not use `gh pr comment` for findings.
5. Delete stale or misplaced Superagent finding comments.
6. Set managed PR labels.
7. Complete the check run.
8. Write the agent receipt JSON with `github_operations_completed: true` and `posted_comment_ids` when available.

More from superagent-ai/skills

SkillDescription
authz-securityReview application source code for broken authorization — IDOR / Broken Object Level Authorization (OWASP API1), Broken Function Level Authorization (API5), mass assignment (API3), multi-tenant isolation gaps, and privilege escalation. Reads routes, controllers, resolvers, and data models offline and reports the missing ownership/role check at file:line with a framework-correct fix. No running app, no credentials, no tools. Trigger when reviewing endpoints/handlers, auditing a PR diff that adds or changes routes, hardening a multi-tenant SaaS, or when the user asks "is this endpoint authorized?", "can a user access another user's data?", "IDOR", "BOLA", or "broken access control".
ci-cd-securityScan GitHub Actions workflow files for security vulnerabilities by reading the YAML and reporting findings directly — no external tools, no installation, no shell execution. Use this skill whenever the user shares a `.github/workflows/` file, pastes workflow YAML, asks for a CI/CD security review, mentions `pull_request_target`, `workflow_run`, action pinning, `GITHUB_TOKEN` permissions, pwn requests, template injection, cache poisoning, secret exfiltration, supply chain risk, or any GitHub Actions hardening topic. Also trigger when the user is hardening an OSS repo, doing a CI/CD red team assessment, evaluating a target for supply-chain scanning, or writing publicly about CI/CD security. Bias toward triggering this skill rather than answering from memory — CI/CD security defaults are wrong almost everywhere and the rules are unintuitive.
crypto-secrets>-
hacker>-
infra-securityAudit Infrastructure-as-Code for security misconfigurations before it ships — Terraform (.tf/.tfvars/.hcl), CloudFormation/SAM (YAML/JSON), Kubernetes & Helm manifests, and Docker / Docker Compose. Reads the IaC offline and reports each misconfiguration at file:line with a severity (P0–P3) and a corrected snippet. A dependency-free scanner does the high-recall first pass; the model adds blast-radius and cross-resource judgment. No cloud credentials, no terraform apply, no pip install. Trigger when reviewing a Terraform plan before apply, auditing K8s/Helm manifests or a Dockerfile before deploy, checking CloudFormation for public S3 buckets or open security groups, doing a pre-deployment or compliance (SOC-2 / PCI-DSS / ISO-27001) security review, or when the user asks "audit this Terraform", "is this S3 bucket public?", "is this security group open to the internet?", "is this container running as root?", "what's the blast radius if this infra is wrong?", or "run an IaC security scan".
recon-securityGuide authorized external penetration testing from recon through validation and scoped exploitation using free and open-source tools. Use for domain/IP attack surface mapping, subdomain discovery, nmap/httpx/nuclei/ffuf workflows, web app testing, SIP/NAS checks, Burp/ZAP validation, PoC documentation, and pentest reporting without commercial APIs.
redteam-autoresearch>-
repo-security-postureAudit a GitHub repository's security posture and hardening gaps across branch protection, CODEOWNERS, GitHub Actions, publish/release integrity, collaborator access, security features, and dependency review. Use when reviewing or hardening a repo, assessing GitHub configuration, checking CI/CD or Actions security, evaluating supply-chain posture, preparing maintainer-facing security todos, or when the user says "repo security posture", "audit my repo", "harden this GitHub repo", "actions security", "protect against a compromised maintainer", or points at a GitHub URL and asks what to fix.
security-disclosure-triageVerify whether an incoming security advisory is a real, disclosable vulnerability in a target repository checkout, and assign an honest severity. Use when triaging an advisory, GHSA, scanner finding, or draft report from the researcher/reporter side to decide if it is worth disclosing. Optimizes against false confirmations and inflated severity.
skill-securityAudit an AI agent skill for security risks before installing or trusting it. Runs a deterministic scanner (regex patterns, Python AST analysis, source-to-sink taint tracking, and YARA signatures) and then reasons about intent — catching prompt injection, credential exfiltration, persistence, memory poisoning, malicious code, supply-chain risks, and description-vs-behavior mismatch. Make sure to use this skill whenever the user wants to scan, audit, vet, review, or check the safety of a skill, plugin, SKILL.md, or agent tool — whether it is a local folder, a zip/.skill file, or a cloned repo — and whenever someone asks "is this skill safe to install?".