Simon Willison collapses AI-generated PR descriptions: the changes in 1 paragraph

You open a pull request and find several screens of text: the problem statement, the solution's design, a list of files, checks, and a few more explanations. The agent has carefully documented everything. But before reading the report, you want to understand one thing: what changed, and why it deserves your attention.

Simon Willison has described a technique he uses for his PRs prepared by Claude Code and Codex. He keeps a short introduction at the top and takes responsibility for its content. He puts the agent's full description inside a collapsible section. GitHub lets you do this directly in Markdown using the HTML tags <details> and <summary>.

For a team that regularly receives changes from coding agents, this is a ready-to-use way to organize PR descriptions. It can be introduced through a PR template and instructions for the agent. A human still needs to read the short introduction, though.

What should stay visible

Willison uses a PR as a unit of work: he gathers commits in it, refines a feature, records decisions, and then merges the finished result. A detailed description is useful here. The problem arises when readers have to work through all the material to figure out the purpose of the change.

In his experience, agent-generated text can be accurate and informative, yet its sheer verbosity discourages reading. The first paragraph should therefore quickly establish the context: what problem the user or developer faced, and what now works differently.

In one of his examples, a page for an individual record displayed its data in a table with a single row. When there were many fields, the table stretched far to the right while the rest of the page remained empty. That explanation immediately gives reviewers the context they need to assess the new view. A screenshot helps them see the result before examining the code.

The introduction does not have to be written from scratch. Willison sometimes takes a suitable passage from the agent's text. What matters is that a human selected it and considers it worth the reader's attention.

How to set up the collapsible section

The <details> tag wraps the hidden part of the description. Inside it, <summary> defines the visible heading: clicking it reveals the remaining content. GitHub supports this structure in PR descriptions and issue comments.

Willison includes the model's name in the section heading, sometimes adding its effort level. This identifies the source of the detailed report. The report itself remains intact: readers can open it whenever they need implementation explanations or information about checks.

Consider a PR that defers loading an editing script. The introduction only needs to explain that the script previously loaded on every page, whereas it now loads when a user with the required permissions first interacts with the editing feature. This is a paraphrase of one of the author's examples.

The agent's report can go below: which handlers changed, how loading is triggered, and which checks were run. Reviewers already understand the purpose of the work and can decide which details they need. For a product manager, the introductory paragraph may be enough to assess the impact on users; a developer will continue examining the code and technical description.

The limits of formatting

A collapsible section does not establish that the changes are correct or make the listed checks trustworthy. If an agent claims the tests passed, that still needs to be checked against the actual run results. Willison is describing his working practice; the article provides no measurements of time saved or review quality.

There is also an editorial constraint: important conditions should not be hidden where readers might discover them only by chance. If a change requires a migration, affects compatibility, or alters an established workflow, it makes sense to flag that alongside the introduction. This is a practical application of the proposed approach to teamwork.

You can try the technique on your next PR: keep an explanation of the problem and the outcome at the top, add a useful screenshot, and then collapse the agent's technical report. Before handing it over for review, read the opening paragraph on its own. If it makes clear what needs to be assessed, the description has accomplished its first task.