← ClaudeAtlas

rjv-pr-descriptionslisted

Use when writing, generating, updating, or fixing a GitHub PR description. Structures the body as journeys — one QA pass each, with grounded test steps, a screenshot, and ticks for what was actually run. Enforces hard caps; on update preserves checked checkboxes + author content; posts the result.
rjvim/ai-skills · ★ 0 · AI & Automation · score 61
Install: claude install-skill rjvim/ai-skills
# PR Descriptions Two people read this: a reviewer deciding if the change is right, and a QA person deciding what to click. Write for the second one and the first is served too. Length is a defect, not thoroughness. An invented test step is worse than no test step — it sends a human to check something that does not exist. ## Shape The body is a list of journeys. A journey is one QA pass: one actor, one path through the product, from where they start to something they can see. Group by what a person would sit down and test as one sitting. Never by file, never by commit, never by layer. A fix with no journey to walk is still one section. Its first line says what happens today, its second what happens after. ## The rule up top When a single requirement, regulation, or constraint generates every journey in the PR, state it before the first journey. Under five lines. It stops the reader asking why there are five sections. No rule to state, start at J1. Never write Overview, Summary, or Background. ## Budget Hard caps. If the draft exceeds one, cut. Do not negotiate with yourself. - 3 sentences of prose per journey. - 4 checkboxes per journey. - 1 screenshot per journey. - 5 journeys maximum, and past 3 you need the rule up top to justify them. - Whole body under 120 lines, images counted. Anything that does not change what a user or a caller observes — refactors, renames, dependency bumps, test-only files, config, formatting — gets **zero** journeys. Collect them in o