Claude Code plugin · GitHub Action · Go CLI

PR descriptions a reviewer can read

Large pull requests are hard to review because nobody knows where to start. pr-brief writes the description: a short brief, a diagram of how the changed code relates, and a ranked list of the files to read first. A gate keeps every PR that way.

InstallView on GitHubWhy so few settings?
Before: a one-line PR description over 34 changed files. After: a brief, an Input to Functions to Output diagram, and a ranked read-these-first table.

What you get

1Brief

One paragraph, in plain words. What the system does differently now, and the effect. No file names.

2Change map

One Input → Functions → Output diagram for each flow, drawn by the tool in a theme. Added, modified, removed and risky code are easy to tell apart.

3Review guide

What changed, a ranked table of the files that carry logic and risk, and where to start reading.

The PR title is never touched. Only the description changes. See the four themes or read why the rules are fixed.

3
settings
4
built-in themes
9
nodes at most per diagram
0
third-party Go modules

Install

Requirements

pr-brief calls two other pieces of software. Claude Code does not install them for you. If one is missing, the skill stops and prints the command. It never switches style on its own.

NeedsInstallRequired by style
asd-ste100 (a skill)git clone https://github.com/danyuchn/asd-ste100-skill ~/.claude/skills/asd-ste100ste, ste+iceberg (the default)
iceberg (a plugin)/plugin marketplace add gagoar/gago-plugins, then /plugin install iceberg@gago-pluginsiceberg, ste+iceberg (the default)

To need only one, change the style: /pr-brief config style iceberg needs only iceberg. The CI check and the CLI need neither.

The plugin

# from the gago-plugins marketplace
/plugin marketplace add gagoar/gago-plugins
/plugin install pr-brief@gago-plugins

# or straight from the repo
/plugin marketplace add gagoar/pr-brief
/plugin install pr-brief@pr-brief

# then, on any branch
/pr-brief

Run /pr-brief improve 123 to rewrite an existing PR. It saves the old description first and asks before it writes.

Check descriptions in CI

The same checks run as a GitHub Action. It reads the PR description from the event payload and needs no secret and no personal access token. Run /pr-brief ci to set it up for GitHub or Azure DevOps: it asks where you work and where the settings live, then writes the file. From a shell: pr-brief init --workflow (add --host azure-devops, or --config inline to keep the style and theme in the workflow). The gate is fixed code with no AI. On GitHub, --rewrite --auth <mode> adds an optional job that lets the Claude Code GitHub Action write the description, with the sign-in method your team picks. How the gate works.

name: pr-brief
on:
  pull_request:
    types: [opened, edited, synchronize, reopened, ready_for_review]
permissions: { contents: read }
jobs:
  description:
    if: github.event.pull_request.draft == false
    runs-on: ubuntu-latest
    steps:
      # the BASE commit: a PR cannot edit the rules that check it
      - uses: actions/checkout@v7
        with: { ref: ${{ github.event.pull_request.base.sha }} }
      - uses: gagoar/pr-brief@v0

Drafts are skipped. Bot-authored PRs are skipped. Details: the gate.

Why you can trust it

  • It runs on your machine. The hook reads each Bash and PR-tool call locally, never runs the text it reads, and makes no network calls.
  • One Go program, no third-party code. It ships as prebuilt binaries, so you install no runtime. CI rebuilds them and fails if they differ from the committed bytes.
  • Releases carry checksums and a provenance record.
  • It says what it cannot do. See the limits.