Add Post-merge section and tighten Why rules in file-pr skill

[justwiebe]

Why

Work that has to happen after a merge — a backfill, a re-import, a config change — had no heading of its own, so it landed in a Why paragraph and read as background. A Post-merge section makes it a list the merger works through, with every box unchecked. It is the one optional heading.

The Why rules covered what to include but not register, so descriptions picked up clauses that carry no fact. Two new rules cut narrative phrasing, rhythm clauses and callbacks, overstated claims, and anything implying fault for the state of the code.

The rest is compression. The command walkthrough spelled out the git steps in full, none of which changes what an agent does; the Assignment section restated a flag already shown in the example; and What Changed had grown two pairs of bullets that said the same thing twice. The skill is 37 lines shorter with no rule dropped.

RoleModel/fmi-atlas#491 shows the description rules in action, including a Post-merge item for the DealCloud re-import.

What Changed

• Add an optional ## Post-merge heading between What Changed and Screenshots
• Ship Post-merge items as unchecked boxes
• Add two register rules to the Why section
• Cut the command walkthrough and the Assignment section to what changes an agent's output
• Merge duplicate What Changed bullets

Screenshots

N/A — no UI changes

[Copilot]

Pull request overview

This PR updates the file-pr skill to improve PR description structure and reduce narrative/duplicative guidance, especially by introducing an optional Post-merge section for work that must happen after a PR is merged.

Changes:

• Adds an optional ## Post-merge section (unchecked boxes) between What Changed and Screenshots
• Tightens Why writing rules to reduce narrative phrasing and overstated/low-signal clauses
• Compresses the command/assignment guidance and merges duplicated What Changed rules

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (3)

skills/file-pr/SKILL.md:33

• This sentence is slightly inaccurate: git log --oneline origin/HEAD..HEAD being empty only tells you the current HEAD has no commits not already on origin/HEAD—it could mean you’re on the default branch, you haven’t committed yet, or your branch is behind. Tweaking the wording avoids implying a single cause.

Empty `git log` output means no commits ahead of the default branch — the work may be uncommitted, or you may still be on the default branch. When `git status` shows changes, describe the PR from the working-tree diff instead.

skills/file-pr/SKILL.md:29

• The note about two dots vs three dots is ambiguous because the command list includes both origin/HEAD..HEAD (for git log) and origin/HEAD...HEAD (for git diff). As written, it can read like “two dots” is always wrong, even though it’s correct for the git log command above. Clarify that this guidance applies to the git diff commands.

Run these as one batch. Note `origin/HEAD...HEAD` — three dots. Two dots compares against the current tip of the default branch and misdescribes the PR.

skills/file-pr/SKILL.md:65

• Now that ## Post-merge is optional, “the file must carry every heading” can be read as requiring all possible headings (including Post-merge) even when there are no post-merge steps. Rephrase to “all required headings (and Post-merge when applicable)” to match the rules below.

`--body-file` replaces the whole body, so the file must carry every heading, not just the changed part. Preserve whatever the user wrote under **Screenshots** — that content is theirs, and a careless edit drops it.

[stephenfinch]

love this