Drafting a PR Description Without Leaving the Terminal

One retry fix, two pull request descriptions

The code is finished, the targeted tests pass, and the cursor is blinking in an empty pull request description. This is where I tend to write something useless like “fix retries” and assume the diff explains itself. It rarely does.

A coding assistant can fill that space, but filling space is not the job. The description needs to tell a reviewer what changed, why it changed, and which claims have evidence. Here is a side-by-side walkthrough using a hypothetical retry fix, not a benchmark dressed up as a devlog.

The shared diff: stop retrying canceled requests

Our example changes a request wrapper so an aborted request exits immediately instead of entering exponential backoff. It adds a regression test for cancellation and leaves the existing retry behavior for transient failures intact. The targeted retry tests pass locally; the full suite has not run.

Both approaches get the same material: git diff origin/main...HEAD, the relevant test output, and a short explanation of the reported bug. Neither gets permission to invent production impact, performance numbers, or checks that nobody ran.

Side by side: the human draft and assistant draft

• The human summary reads: “Stop retrying requests after their abort signal fires, so canceled operations do not continue through the backoff loop.”
• The assistant summary reads: “Exit the retry loop when cancellation is detected, while preserving retries for transient failures.”
• The human motivation reads: “Cancellation currently reaches the generic retry handler, which treats the aborted request as another retryable failure.”
• The assistant motivation reads: “The retry wrapper currently classifies cancellation as retryable, causing unnecessary attempts after the caller has canceled.”
• The human testing note reads: “Targeted retry tests passed locally, including the new cancellation regression; the full suite was not run.”
• The assistant testing note reads: “Targeted retry tests passed, including cancellation coverage; full-suite validation remains outstanding.”

Neither version wins on prose alone. The human draft connects cancellation to the backoff loop more directly. The assistant draft is tidy and easy to scan. Both become misleading if the implementation checks cancellation only before sleeping, but not before the next attempt. The diff, not the wording, settles that question.

The terminal prompt that keeps the draft honest

I would give the assistant this instruction: “Draft a pull request description from the supplied diff and test output. Include summary, motivation, testing, and reviewer attention points. Separate observed facts from assumptions. Report only tests shown as executed. Flag missing context instead of guessing. Do not modify files or create the pull request.”

Inspect git status first, then collect the branch diff and relevant output. Exclude secrets, unrelated logs, and generated noise before sharing context. Include uncommitted changes only when they belong in the proposed pull request. A beautifully written description of the wrong diff is still wrong.

In Claude Code, Codex, or Gemini CLI, this can stay inside the existing terminal workflow. Fluxo provides one key and one base URL, https://api.fluxorelay.com, across its model catalog, and also works with any OpenAI SDK. For example, I could request the draft with Claude Sonnet 5.5 or GPT-6.1 Sol without changing the evidence-gathering steps.

Reviewing the assistant’s claims before posting

The useful review pass is sentence by sentence. Does “preserving retries” match the branches in the implementation? Does “cancellation coverage” mean one regression case or several? Is “passed” backed by actual command output? Replace broad claims with narrow ones whenever the evidence is narrow.

Keep the first experiment small. Fluxo bills per real token, including cache reads and writes, with no monthly fee, so repeated revisions still deserve attention. Its referral share applies when invited users pay; that is separate from whether a draft is useful. If you want to try this workflow, you can create a Fluxo account.

The verdict: delegate the draft, keep the sign-off

Use the assistant for the first draft, not the final authority. It is good at turning scattered evidence into a reviewable structure; you remain responsible for intent, scope, and verification. For a tiny change, typing three honest sentences may be simpler. For a branching fix with several tests, an assistant draft is worth reviewing. Either way, publish only claims you can defend from the diff and recorded results.