The author notes that most changes these days arrive as pull requests (PRs) opened by agents such as Claude Code or Codex. A PR is the unit of work: commits are bundled, iterated on, decisions are documented, and the finished result is merged. Modern coding agents are excellent at writing PR descriptions, but that is also the issue: they tend to be overly detailed and long, which makes quick review harder.
Agent‑written descriptions are accurate and comprehensive — they explain the problem, the detailed solution, and the verification steps. Yet readers often find them burdensome: a long, machine‑generated block of text can deter reviewers who prefer a short, human‑curated introduction that explains at a high level what the PR does and whether it deserves attention.
The practical fix: hide the bulk in <details><summary>
The author proposes a low‑effort pattern: hide the long, agent‑generated sections inside HTML <details><summary> tags. The <details><summary> elements render as a collapsed heading (the summary) that can be expanded to reveal the fuller text. Crucially, GitHub Markdown supports these tags, so they work directly inside PR descriptions and issue comments.
How the author uses it:
- The PR opening paragraph is a short, carefully chosen, human‑edited summary that gives a high‑level explanation of what the PR does and why it matters. Screenshots are often included because images can quickly illustrate a new feature.
- The longer, agent‑written essay follows inside a <details><summary> block. The summary line often contains the model name and sometimes an indication of effort level (for example, "Claude Opus 5.5 Medium") to make clear what produced the text and how much automated work it represents.
The effect: PRs stop feeling sloppy or overwhelming. All the information remains available, but a reader can first glance at a short, human‑approved opener without immediately wading through multiple paragraphs of model output.
Real examples from recent PRs
The author lists several recent pull requests where this pattern was used, together with the openers:
-
datasette PR #3052: Redesign row page as a vertical list of fields
- "The row page showed its single row as a one-row table. For wide tables, like a 46-column GitHub repos table, that scrolled far off to the right and left most of the page blank." (then a screenshot)
-
datasette PR #3043: Pagination bar showing which rows are on the current page
- "Table pages that span more than one page now make it obvious where you are, and offer navigation at the top of the page as well as the bottom." (plus screenshot)
-
datasette PR #3042: Load edit-tools.js on demand via a small loader
- "edit-tools.js (~220KB) was loaded on every table, row and database page, even for users who couldn't edit anything. Now only load it for users who can edit when they first interact with an edit feature (including mouse over an edit link)."
-
datasette-agent PR #51: register_agent_reference_types plugin hook
- "Lets plugins add their own kinds of item to the # tagging in the chat composer using a new register_agent_reference_types(datasette) plugin hook." (pictured in the article)
-
llm PR #1838: Add llm openai endpoint add/list/remove/path commands
- "Adds commands for managing the records in extra-openai-models.yaml, so OpenAI-compatible endpoints can be saved from the command line instead of by hand-editing YAML." (then a copy of the --help output)
In each case the short human opener gives a quick, useful summary while the complete, model‑generated detail remains available inside the expanded <details>.
Tricks to remember tag order
The author shares two memory aids for the tag order (<details><summary> vs <summary><details>):
- The <summary> is the clickable summary text that expands the content, so logically it should be the inner tag and the <details> wrapper must contain it.
- Use the phrase "details‑summary" as a mnemonic: two syllables followed by three syllables, which is easier to say and remember than "summary‑details".
The author notes they would like a GitHub editor button for inserting this pair of tags to make the workflow easier on mobile and to help more users adopt the pattern.
Conclusion
Using <details><summary> in GitHub PR descriptions is a simple, effective way to hide verbose, model‑generated content while surfacing a concise, human‑curated introduction. Reviewers can quickly grasp the essential points, and the full automated description remains available for anyone who wants to dive deeper.
