pr-artifact

Presenting Pull Requests

Create one unique, self-contained HTML artifact that helps the intended audience understand what changed, why it changed, how the change works, what is affected, how it was validated, and what risks or questions remain.

Input

PR or change source: $ARGUMENTS

Accept any of these input forms:

• PR URL.
• PR number.
• Branch name, commit range, or comparison ref.
• Local diff or patch file.
• Markdown summary, release note, review notes, or implementation notes.
• Empty input, if the current repository and branch can provide enough context.

If $ARGUMENTS is empty, first try to infer the change from the current git repository:

• Identify the current branch.
• Compare it against the repository's default branch when that is locally available.
• If no reliable comparison base exists, ask the user for a PR URL, PR number, branch, commit range, or diff file and stop.

If $ARGUMENTS references network-only PR metadata and network access is unavailable, use local git information when possible and clearly mark unavailable metadata under Open questions.

Output Requirement

Create a single .html file inside the artifacts/ directory in the current working directory.

If artifacts/ does not exist, create it.

The file must be fully self-contained:

• Include all CSS in a <style> tag.
• Include all JavaScript in a <script> tag.
• Do not depend on external CDNs, fonts, images, packages, analytics, or network requests.
• Use semantic HTML and accessible markup.
• Work by opening the file directly in a browser.

Name the file using a short slug derived from the PR title, branch, or change theme, for example:

artifacts/pr-artifact-[slug].html

If no clear title exists, use:

artifacts/pr-artifact.html

Do not overwrite an existing unrelated artifact unless the user explicitly asks. If the target filename exists, choose a clear variant such as artifacts/pr-artifact-[slug]-v2.html.

Core Principles

• Treat the PR, diff, commits, and source notes as authoritative.
• Explain the change at the right altitude for reviewers and stakeholders.
• Preserve technical accuracy while translating dense implementation details into plain language.
• Make the review surface obvious: affected areas, behavior changes, validation, risk, rollout, and open questions.
• Separate verified facts from inferred implications.
• Make missing details visible instead of filling gaps with confident guesses.
• The artifact should feel intentionally designed, not templated.
• Avoid generic dashboard filler, decorative-only graphics, excessive cards, repeated section layouts, and one-note color palettes.