PR and Issue Discipline

Show the change, do not describe it: a fenced block is the text form of a picture, so the reader skims it and gets the change, flow first, then output, each where it moved. The fewest words after, under a hard size budget, in the shape that fits the change. Anything written for a tool or another agent sits in one collapsed section at the bottom.

These rules apply to any session that opens or updates a PR or writes an issue. "The author" below is whoever prepared the change, human or agent, alone or in a multi-agent session. What happens after the PR exists (draft flips, review rounds, the merge) is the /pr-landing-discipline skill's moment; someone else's thread (an issue reply, a review of their PR) is the /reply-and-review-discipline skill's.

When to Apply

• Opening a pull request, or writing or changing its body or title
• Writing a bug report or issue
• Re-reading the body before the PR is offered to its reader

Open every PR as a DRAFT; from there the /pr-landing-discipline skill owns it: the draft flips, the babysit loop, who merges, and the gates before landing.

PR Bodies: Show the Change, Shaped to It

Show the change rather than describe it. A PR body is text, so its picture is a fenced block: the flow and the real captured output, each where the change moved it, and a diagram, table, or the contract's own shape where nothing runs. The reader skims the blocks and gets the change without reading a paragraph. Shape the body to the change; never force every PR through one template.

Two parts. Part one is for a human skimming: the change shown (the opening block, in one of the shapes below), then the fewest words. Part two, at the BOTTOM, is a single collapsible section, collapsed by default, for anything written for another agent or tool rather than the human reader: