pr-creation

Writes pull request titles and bodies that transmit the author's model of a change.

Updated Feb 17, 2026
One-click install
npx skills add https://github.com/semantic-praxis/barwise --skill pr-creation-semantic-praxis
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: pr-creation
Source: https://github.com/semantic-praxis/barwise/tree/main/.claude/skills/pr-creation
Command: npx skills add https://github.com/semantic-praxis/barwise --skill pr-creation-semantic-praxis

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Reviewers waste effort reconstructing why a change was made, which files matter, and what was verified. This Skill produces PR titles and bodies that carry the author's intent, reading order, measured evidence, and known risks up front, so reviewers judge instead of reconstruct. ## Core Features & Use Cases - Readiness gate: Verifies the spec exists and is updated, the tracking issue exists without premature closure, the branch sits on current main, and local CI is green before opening a PR. - Diff cutting guidance: Splits mechanical from semantic changes, orders additive before destructive commits, and decides when a change should become multiple PRs. - Structured PR body: Generates a body with a reading guide (spine vs fallout files), measured evidence with the command behind each number, decisions and rejected alternatives, least-certain areas, behavior changes, and a session review section. - Use Case: You have a branch ready on the barwise repo with a spec and tracking issue. The Skill derives the PR title and full body from the git log, diff, spec, and issue, writes it to a file, and opens the PR against main. ## Quick Start Write the PR title and body for my current branch against main, using the spec and tracking issue, and save it to a file I can pass to gh.

Frequently Asked Questions about pr-creation

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

FAQPage Schema
How do I write a good pull request description?▼

State what changed and why in one paragraph, then provide a reading guide ordering the spine files with a reason per file, measured evidence with the command behind each number, decisions taken, and where you are least sure. Derive everything from the branch, spec, and issue rather than filling a form.

How do I decide whether to split a branch into multiple PRs?▼

Split when a spine exceeds five files, fallout needs more than one pattern to describe, or the reading guide takes over ten minutes. Separate mechanical changes from semantic ones first, and put additive commits before destructive ones.

What should be checked before opening a pull request?▼

Confirm the spec exists and names what the PR ships, the tracking issue exists without being closed by the PR, the branch sits on current main, local CI is green, and you have run the review checklist against your own diff.

Should a pull request close its tracking issue automatically?▼

No. In this workflow closure is a tracker-only follow-up performed after merge by the steward process. The PR body names the issue and states that closure follows after merge.

What are the limitations of AI-generated PR descriptions?▼

Generated descriptions risk inventing rationale for changes no one reasoned about. The rule is to state plainly when a change was generated without a formed reason, since an invented intent misleads reviewers more than silence.