最近のSimon Willison氏のプロジェクトでは、変更のほとんどがClaude CodeやCodexといったコーディングエージェントによって開かれたプルリクエスト（PR）の形で届く。同氏はPRを仕事の単位としており、複数のコミットをまとめ、機能が完成するまで反復し、意思決定を記録したうえで最終結果をマージしている。同氏によれば、現在のコーディングエージェントはPRの説明文を書くのが非常に得意だという。問題は、あまりに得意すぎることにある。
エージェントが書くPR説明は正確で網羅的だ。問題の背景、詳細な解決策、検証のために取った手順まで記述する。しかし、それは読む側にとって吸収すべき情報量が非常に多い。同氏は、それが必ずしも低品質な「スロップ」だとは限らないが、読んだ印象はスロップのように感じられると述べる。AIが書いたPRはすぐに見分けがつき、他のAI文章と同様、同氏の第一反応は「こんなに全部読んでいられない」というものになる。情報がどれほど正確で有用であっても、書いた時間より読む時間のほうが長くかかりそうだと感じた瞬間に引いてしまう。たとえその書き手が自分自身であっても同じだ。
同氏が求めているのは人間による編集上の判断だ。PRについて少しだけ考えた人が、このPRが何のためのものかを高レベルで理解し、より注意を払う価値があるかどうかを判断する助けとなる、人間が承認した導入文を用意してほしいという。そこで同氏は、手間が少なくしっくりくる方法を見つけた。
その方法はHTMLの<details><summary>要素を利用する。レンダリングすると、折りたたまれた見出し（summary）として表示され、クリックすると長い本文を展開できる。重要なのは、この2つのタグがGitHub Markdownでサポートされている点だ。issueコメントやPR説明に直接記述すれば、GitHubはdetailsの中身を隠し、summaryと展開用の矢印だけを表示する。
同氏はこのパターンをAI生成のPRに使い始めた。PRの冒頭段落は、全体像を伝える高レベルの説明として慎重に選ばれたもの、つまり読者が状況を素早く把握するための最短のテキストになる。新機能を手早く示すには画像が最適なことも多いため、スクリーンショットを添えることもある。続いて、エージェントが書いた長文の説明全体を<details><summary>の中に入れる。summary部分にはモデル名、多くの場合は推論の強度も添え、「Claude Opus 5.5 Medium」のようにして、何が書かれているのかを明確にする。
この結果、PRは以前ほど雑に見えなくなったという。情報はすべて残したままだが、読者は一目で人間が取捨選択した上位の情報を得られ、何段落も続くエージェント製の詳細に目を疲れさせずに済む。導入文は必ずしも同氏自身が書くわけではない。エージェントが大量の文章の中に必要な内容をすでに用意してくれている場合もある。それでも、短い冒頭文は何が間違いなく読む価値があるかについての人間の判断を表す、というのが読者への約束だ。
記事ではこのパターンを使った最近の例と、その冒頭文が紹介されている。datasette PR #3052は行ページをフィールドの縦リストとして再設計したもので、冒頭では、行ページが単一の行を1行の表として表示していたため、GitHubのrepos表のような46列の幅広い表では右へ大きくスクロールし、ページの大部分が空白になっていたと説明している。PR #3043は現在のページにどの行が含まれるかを示すページネーションバーを追加し、複数ページにまたがる表で現在位置が分かりやすくなり、ページ上部と下部の両方にナビゲーションを設けたと述べている。PR #3042はedit-tools.jsをオンデマンドで読み込むようにしたもので、約220KBのこのファイルが編集権限のないユーザーを含むすべての表・行・データベースのページで読み込まれていたが、今後は編集権限のあるユーザーが編集機能を初めて使ったとき（編集リンクへのマウスオーバーを含む）にのみ読み込むと説明している。datasette-agent PR #51はregister_agent_reference_typesプラグインフックを追加し、プラグインがチャット入力欄の#タグ付けに独自の項目種別を追加できるようにする。llm PR #1838はextra-openai-models.yamlのレコードを管理するadd、list、remove、pathコマンドを追加し、OpenAI互換のエンドポイントをYAMLの手編集ではなくコマンドラインから保存できるようにした。
最後に同氏はタグの順序を覚えるコツを共有している。以前は<details><summary>なのか<summary><details>なのか分からなくなっていた。まず明らかなのは、<summary>がdetailsの内容を要約する部分、つまりクリックで展開できる1行のテキストであり、<details>要素がそれ以外のすべてを包むという点だ。さらに良いのは、この2つのタグを常に「details-summary」と呼ぶことだ。「details-summary」は2音節と3音節の組み合わせで、「summary-details」の3音節と2音節の組み合わせより口に出しやすい。数回声に出して言えば、タグの順序を忘れることはなくなる。同氏はまた、GitHubのMarkdownエディタに挿入ボタンを追加してほしいと願っている。スマートフォンのキーボードで苦労して入力する手間を省けるうえ、この機能の存在をより多くのGitHubユーザーに広められるからだ。