write-a-pr-description

Structure the PR body as a file-tree diff marking each changed file with (A/M/D/R) plus a note, then add prose explaining runtime data flow only when the tree alone is insufficient. Explicitly list what is not tested so reviewers can assess risk without reading the full diff.

Include a file-tree diff showing what changed, star markers on critical paths like new entry points or removed ones, a prose walkthrough of control flow when behavior changes, and an explicit section on untested or uncovered boundaries.

Broken code fences usually come from backslash-escaped backticks introduced by an unquoted HEREDOC in gh pr create. Use cat <<'EOF' with a quoted delimiter so backticks pass through raw, then verify with gh api and grep that no escaped backticks remain.

Skip the prose section when the file tree alone answers what runtime behavior changed, such as a typo fix or small rename. Add it whenever the change crosses a runtime boundary like a new container, CI step, or lambda, or alters critical control flow.

Common anti-patterns include flat bullet lists of changed files with no hierarchy, artificially compressed notes that hide context, treating a happy-path test as full coverage, and abstract verbs like integrated or optimized that conceal internal control flow.