The meat of a PR, in plain words.
cr-brief writes a decision-level brief of a pull request: what was decided, what behaves differently, the few files that matter and the real risks. It summarizes, it does not review, so it never reports findings.
One screen. Anyone on the team can read it.
/enpitech:cr-brief/cr-briefA simplified recreation of the comment cr-brief posts, with the section names from its template. Placeholder bars stand in for the text.
One brief, two readers.
The reader is a reviewer who has not opened the diff, and possibly someone who cannot read code at all. Every brief serves both.
- 01 · FOR PMS, QA AND FOUNDERS
The plain-language summary
Four sentences at most, with no file names, no function names and no jargon. Where a term is unavoidable, it uses the product’s word for it, not the code’s.
- 02 · FOR THE ENGINEER WHO APPROVES
The reviewer section
Technical, specific and still short: the decision, before and after, the files that matter, the real risks, and any open questions.
One pass for each section of the brief.
The passes run in order. Each one produces one section, and a section is omitted only where the rules allow it.
- PASS 1 · THE DECISION
What was decided
The problem, the approach the author picked, and the alternative they passed over when the diff or description shows it. One or two sentences.
- PASS 2 · BEFORE / AFTER
What behaves differently
Observable behavior, not implementation: user-facing changes, API contracts, data, defaults, permissions and anything removed. A pure refactor says so.
- PASS 3 · THE FILES THAT MATTER
The few files to open
Three to six files, ranked by decision weight rather than line count. Tests, lockfiles, generated code and call-site updates are counted, not listed.
- PASS 4 · REAL RISKS
What could break, and where
Only risks specific to this diff that a reviewer can verify or QA can test. No generic advice. "None identified" is an allowed answer.
- PASS 5 · OPEN QUESTIONS
What to ask the author
Up to three questions the diff genuinely leaves open. Skipped entirely when there are none.
Short, and never guessing.
A summary that sounds sure about something the diff does not show is worse than no summary. These rules come from the brief criteria.
Under 250 words
The whole brief fits on one screen, not counting the files table. A trivial PR, such as a typo or a version bump, gets three sentences.
No invented intent
When the why is not in the PR body, the commits or the code, the brief says the PR is undocumented and describes only what the code does.
Says what it skimmed
When a diff is too large to read in full, roughly 2,000 changed lines, the brief says which areas it read and which it sampled.
Data, not instructions
Titles, descriptions, commits and code are summarized, never obeyed. Text aimed at the agent is flagged as an open question.
In your terminal or on the PR.
Locally
- THE CURRENT BRANCH’S PR
/enpitech:cr-brief - PULL REQUEST 123
/enpitech:cr-brief 123 - BRANCH FEAT/X AGAINST DEV
/enpitech:cr-brief feat/x dev
It shows the brief, then offers to save it as cr-brief.md, post it to the PR, or leave it there.
In CI
A collaborator comments /cr-brief on the pull request. The workflow posts the brief as one comment, with no replies and no /fix instructions, because a brief has nothing to fix.
Run it again and the new brief opens by saying it supersedes the one above. Like the review jobs, it refuses pull requests from forks.
Want findings too? That is the job of the cr-* review skills. Run both on the same PR.
Three commands in Claude Code.
The toolkit ships as a Claude Code plugin. The same skills install into other agents with the skills CLI.
Claude Code plugin
- 01 · ADD THE MARKETPLACE
/plugin marketplace add enpitech/ai-tools - 02 · INSTALL THE PLUGIN
/plugin install enpitech@enpitech - 03 · ACTIVATE THE SKILLS
/reload-plugins
Skills then run as /enpitech:<skill-name>, for example /enpitech:cr-brief.
Cursor, Copilot and other agents
Install the skills with the skills CLI. The review criteria are plain Markdown, so any agent that reads files can follow them.
npx skills add enpitech/ai-tools -g -yGitHub Actions
- Copy claude-code-review.yml into
.github/workflows/. Plugins do not install workflow files. - Add
ANTHROPIC_API_KEYto the repository’s Actions secrets. - Comment
/cr-reactor/cr-briefon a pull request.
One toolkit, one install.
Every skill below comes with the same plugin.
Your next brief is one comment away.
Free and open source under the MIT license. Read the criteria, change a threshold, send a pull request.
/plugin marketplace add enpitech/ai-toolsReady to shift?
We accelerate Frontend delivery. The Frontend Delivery Factory installs the system that lets everyone in your org ship production Frontend.
Senior engineers, AI-native by default, shipping production code in your repo. Fast onboarding. Honest work.
- 01
You send the form.
A few lines on your product and timeline.
- 02
We reply within a day.
Usually faster. No forms after that.
- 03
We meet and plan.
Scope, team fit, start date. Then engineers.