write-pr

Read the full diff first, then write three artifacts before the change list: a Mermaid diagram of the flow the change lives in, a table of observable before/after outcomes, and a map from reviewer questions to the files that answer them. This Skill automates that structure and posts it with gh.

Patch the body through the GitHub API instead of gh pr edit, which can fail silently. Write the description to a file, wrap it in JSON with python3, then call gh api -X PATCH on the pulls endpoint and read the body back to verify.

Yes, GitHub renders a fenced mermaid code block directly in the description. The diagram source must parse correctly, so render it locally with mmdc first; a diagram that fails to parse appears as a plain code block.

Common causes include using the reserved word 'call' as a label, appending a :::class suffix that drops the rest of the line, or unquoted labels containing commas or slashes. Quote every label with special characters and validate with mmdc before posting.

Skip the diagram only when the change has no flow to draw, such as a rename across one package, using the --no-diagram flag. For pure refactors with no observable outcome, state that explicitly instead of inventing a before/after row.