Skip to content
Back to skills

Review Brief

ASecurity

Writes the review brief a human reads at the final review gate before merge: what changed, what CI said, what the local review flagged, what was left out, what is uncertain. Use for the task that produces the review brief, which Kraft runs once the merge request is open and before that gate.

  • 7 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 21, 2026
ai-agentsgo

Security analysis

A100/100

Scanned October 21, 2026

npx -y skills add itsOmidKarami/kraft --skill review-brief --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Review Brief?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Review Brief
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/itsomidkarami-review-brief/badge)](https://www.skillsdirectory.com/skills/itsomidkarami-review-brief)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: review-brief
description: "Writes the review brief a human reads at the final review gate before merge: what changed, what CI said, what the local review flagged, what was left out, what is uncertain. Use for the task that produces the review brief, which Kraft runs once the merge request is open and before that gate."
---

# The human review brief

This is the last gate before merge. A human reads what you write and decides
whether the change goes in. They have not watched the chain run, they have not
read the pipeline, and they will not go looking — whatever is not in this brief
is not in their decision.

## Before you write

Read, in this order:

- The chain's events for this work item: `kraft view events` (the worktree you
  are in names the work item). `mr_opened` records the merge request that was
  opened; the events after it say what the pipeline said about it. If CI was
  not configured or never ran, the brief says that instead. If `kraft` refuses
  the verb or cannot be run (a sandboxed worker with no network cannot reach
  Kraft at all), work from what your instructions carry and say in the brief
  which events you could not read.
- The local review findings, including the ones ruled minor.
- The diff itself. A brief written from the spec rather than from the diff
  describes the change that was planned, not the one that was made.

## What the brief contains

- **What changed**, in the terms of this repo: files, functions, behaviour. Not
  a restatement of the work item's title or description.
- **What CI said**, plainly, including the job names. If the pipeline is red,
  say so in the first line — a brief that buries a failed pipeline is worse
  than no brief, because it converts a human check into a rubber stamp.
- **What the local review flagged**, including findings that did not burn a fix
  cycle. A minor finding nobody is shown is a silent discard.
- **What was deliberately left out**, and why. Scope the reviewer did not
  expect is most of what gets rejected at this gate.
- **What you are unsure about.** Doubts are information for the human, not an
  admission. Name them.

## What not to do

Do not argue for approval. You are not selling the change; you are giving the
person who owns the decision what they need to make it. A brief that reads as
advocacy makes the reviewer's job harder, because they have to discount it
before they can use it.

Do not pad a small change into a long page. Three lines is a fine brief for a
three-line diff.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.