# Summary Skill

> Use when the task is to summarize a pull request's reviews and discussion into a prioritized, triage-style report — an overview plus per-item fix-size (LOC bucket) and fix-value (trigger probability × impact). The task prompt (from the pr-summary action) will tell you to follow this skill and end by calling submit_output.

- Skill: `rome-os/summary-skill` (Agent Skill)
- Install (CLI): `npx skillmds@latest add rome-os/summary-skill`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rome-os/summary-skill/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: rome-os (https://skillmd.com/u/rome-os)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/rome-os/summary-skill

---


# Summary Skill — recap reviews/discussion + triage the fixes

Your job: read everything said about a single pull request and produce a crisp,
prioritized summary that helps the author decide **what to fix and in what
order**. Your output contract is the `submit_output` tool (structured JSON) —
the `pr-summary` action turns it into a comment on the PR. Do not post to GitHub
yourself.

## Inputs (from the task prompt)

- `repo` and PR `number`, title, and description.
- The collected **reviews** (body + verdict + author), **inline review
  comments** (path/line + body + author), and **issue-thread discussion**
  (comments). Large threads may be truncated — fetch more yourself if needed.

## Steps

1. **Read the provided reviews and discussion carefully.** These are the source
   of truth. Every item you report must trace back to something actually raised.
2. **Gather more context as needed** with `gh` + Read/Grep/Glob:
   - `gh pr diff <number> --repo <repo>` (use the `get-pr-diff` skill's
     strategies for large diffs) to gauge how much code a fix really touches.
   - `gh api repos/<repo>/pulls/<number>/reviews` and
     `.../pulls/<number>/comments` and `.../issues/<number>/comments` if the
     prompt's copy was truncated.
   - Read the referenced files to ground your size/impact estimates in real code.
3. **Distill the DISTINCT open action items.** Merge duplicates across reviewers;
   drop points already resolved/addressed and pure praise. Prefer a handful of
   meaningful items over an exhaustive list of nits.
4. **Assess each item:**
   - `fix_size` — the code needed to FIX it (not the PR size):
     - `small` = 1-10 LOC
     - `medium` = 10-100 LOC
     - `large` = >100 LOC
   - `fix_size_loc` — a SINGLE concrete LOC number inside that bucket (e.g. 3,
     60, 220). The user sees this exact number rendered as "Medium (~60)", so
     give a real estimate grounded in the diff/code, not just the bucket.
   - `trigger_probability` (`low`/`medium`/`high`) — how likely the underlying
     problem is to actually be hit in practice.
   - `impact` (`low`/`medium`/`high`) — how bad the consequence is when it hits.
   - `fix_value` (`low`/`medium`/`high`) — combine probability × impact:
     - high × high → high; low × low → low; mixed → medium (use judgment).
   - `rationale` — 1-2 sentences justifying size + value, citing the review/
     discussion or the code.
5. **Write the wrapper prose:**
   - `overview` — 1-2 paragraphs: what the PR does + the themes raised.
   - `overall` — a short recommendation on what to prioritize (e.g. "land the two
     high-value small fixes first; the large refactor can be a follow-up").
6. **Finish by calling `submit_output`** with `{ overview, items, overall }`.
   If nothing actionable is open, return an empty `items` array and say so.

## Rules

- Never invent problems — only summarize what the reviews/discussion raised.
- Estimate `fix_size` against the real diff/code when you can, not by guessing.
- Be concrete: name files, reviewers, or specific concerns where it helps.
- Your ONLY final action is `submit_output`. Do not reply in plain text.