Antiwork Gumroad Pr Description

PR Description Generator

Generate a concise, high-quality PR description from the current branch and its linked GitHub issue. Output to an unstaged .md file — never publish or update a PR.

Workflow

1. Gather Context

Run these in parallel:

# Current branch name
git branch --show-current

# Commits on this branch vs main
git log main..HEAD --oneline

# Full diff against main
git diff main...HEAD

# Check for linked issue number in branch name or commits
# Branch names often follow: username/issue-description or fix/NNNN-description

If the branch name or commits reference an issue number, fetch it:

gh issue view <number> --repo antiwork/gumroad --comments

If no issue number is found, ask the user.

2. Understand the Change

From the issue and diff, determine:

• What problem was being solved (or what feature was requested)
• What approach was taken (high-level concept, not file-by-file)
• Whether this is a UI change (look for view/component/CSS changes)

Read key changed files if the diff alone doesn't make the approach clear.

3. Write the Description

Follow the PR description structure in CONTRIBUTING.md. The template below implements it:

Adapt sections based on what's relevant — not every section is needed for every PR.

Style rules:

• Write in simple, direct language. Avoid jargon.
• Focus on what and why — not what files changed.
• No file change summaries or lists of modified files.
• No checklists.
• Succinct PR title: no "feat:" prefix, but "Fix:" is fine for bug fixes.
• Keep it concise. A few clear sentences beat a wall of text.

Template

Fixes #<issue-number>

## What

[What this PR does. Concrete changes — not a list of files.
For features: what was built. For fixes: what was wrong and what was changed.]

## Why

[Why this change exists and why this approach over alternatives.
Business or user rationale. Strategic context if relevant.]

<!-- BEFORE/AFTER — include for UI/CSS changes, delete this section otherwise
## Before/After

Before:
<!-- screenshot or video -->

After:

<!-- screenshot or video -->

Include: Desktop (light + dark) and Mobile (light + dark) if applicable.
-->

<!-- TEST RESULTS — include a screenshot of test suite passing locally
## Test Results

<!-- screenshot -->

-->

---

This PR was implemented with AI assistance using [specific model, e.g., Claude Opus 4.6].

Prompts used:

<!-- chronological, verbatim if under ~100 chars otherwise summarized, skip pure confirmations -->

- "[first prompt that shaped the code]"
- "[next prompt]"

See references/example.md for a well-received PR description example.

4. Output the File

Write the description to gh-pr-draft.md in the repo root. Do NOT stage or commit this file.

If gh-pr-draft.md already exists, overwrite it.

Tell the user the file was created and suggest they review it before posting.

Important

• Use gh read-only only. Never create, comment on, or update PRs.
• Always fetch the GitHub issue — it provides critical context for the Problem section.
• Omit the Before/After section entirely for non-UI changes (remove the HTML comment too).
• Omit the Test Results section if not applicable (remove the HTML comment too).
• The AI disclosure format follows CONTRIBUTING.md.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.