pr-first-reader-check

Review pull requests for jargon, missing context, and unreadable sentences.

1|Updated Jan 31, 2026
One-click install
npx skills add https://github.com/tktcorporation/cli-sim-game-escape --skill pr-first-reader-check-tktcorporation
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: pr-first-reader-check
Source: https://github.com/tktcorporation/cli-sim-game-escape/tree/main/.claude/skills/pr-first-reader-check
Command: npx skills add https://github.com/tktcorporation/cli-sim-game-escape --skill pr-first-reader-check-tktcorporation

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Pull requests often contain internal jargon, references to external documents, and convoluted sentences that only make sense to the author. This blocks first-time reviewers (new hires, other teams) from understanding the PR, causing review delays and endless question round-trips. ## Core Features & Use Cases - Context Check: Detects issue/PR-only labels (e.g., "Phase-2"), references to files or tickets the reviewer cannot open, undefined abbreviations, and implicit assumptions, then suggests replacing, self-containing, or deleting them. - Readability Check: Flags sentences that require a second read—multiple claims per sentence, distant subject-verb pairs, nominalization, roundabout predicates, buried conclusions—and rewrites them without changing meaning. - Use Case: Before submitting a PR, run the check across the title, body, commit messages, and code comments to produce a findings table with before/after fixes so any reviewer can understand it on first read. ## Quick Start Check my current pull request for jargon and readability issues that a first-time reviewer would stumble on, and fix them.

Frequently Asked Questions about pr-first-reader-check

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check if my pull request is understandable to new reviewers?

Run the check against the PR title, body, commit messages, and diff comments using gh pr view and gh pr diff. It flags context-dependent terms and hard-to-read sentences, then provides before/after fixes for each finding.

What kinds of jargon should be removed from a pull request?

Remove names that exist only in issues or planning docs, like phase labels or initiative codes, plus references to files or tickets reviewers cannot open. Keep terms grounded in code or the product UI, since reviewers can grep for their definitions.

Does this check internal company terminology in PRs?

Established internal terms with a code or product presence are kept, because reviewers can trace them via grep. Only terms with no entity in code or product, such as planning classification labels, are flagged for replacement or removal.

When should I not run a PR readability check?

Skip it for pure renames or changes with zero prose. If the PR contains even one line of comment or description, running the check is worthwhile since context-dependent wording almost always slips in.

Why does the check flag sentences even when all words are understandable?

Readability is a separate axis from vocabulary. Sentences with multiple claims, distant subject-verb pairs, nominalization, or conclusions placed last force reviewers to re-read, so they are rewritten while preserving the original meaning.