[{"data":1,"prerenderedAt":805},["ShallowReactive",2],{"folio-writing-cmd":3,"folio-clipboard-cmd":81,"cmd-works":86,"folio-page:\u002Fwriting\u002Fwhat-my-pull-requests-look-like-now":401},[4,14,23,31,40,49,58,67,74],{"path":5,"title":6,"description":7,"date":8,"tags":9,"readingMinutes":13},"\u002Fwriting\u002Fwhat-my-pull-requests-look-like-now","What My Pull Requests Look Like Now","As we read less of the code agents write, the pull request becomes what we judge a change by. Mine now say who did what and show that the change works. Here are real ones, what they don't fix, and a skill to do the same.","2026-10-27",[10,11,12],"agents","open-source","workflow",11,{"path":15,"title":16,"description":17,"date":18,"tags":19,"readingMinutes":22},"\u002Fwriting\u002Fhow-i-redrew-my-portfolio","How I Redrew My Portfolio","I've just redesigned my portfolio. It used to be blue, it's red now. Here is where everything on it comes from.","2026-10-18",[20,21],"design","personal",17,{"path":24,"title":25,"description":26,"date":27,"tags":28,"readingMinutes":30},"\u002Fwriting\u002Fhow-i-work-with-agents-right-now","How I Work With Agents Right Now","Which agents I use in October 2026 and for what, the skills they share, and the few rules that keep them from acting in my name.","2026-10-12",[10,29,12,11],"ai",9,{"path":32,"title":33,"description":34,"date":35,"tags":36,"readingMinutes":39},"\u002Fwriting\u002Fhow-a-tweet-changed-my-life","How a Tweet Changed My Life","From a layoff in Nice to Vercel in London, by way of Nuxt. The story of a tweet posted on a Tuesday morning in December, and of everything that made it work.","2026-09-02",[37,21,38,11],"career","nuxt",14,{"path":41,"title":42,"description":43,"date":44,"tags":45,"readingMinutes":48},"\u002Fwriting\u002Ffrom-local-to-production-containerizing-your-nuxt-app","From Local to Production: Deploy the Latest Nuxt Stack with Docker","Learn how to properly containerize and deploy a Nuxt application using the latest versions of Nuxt UI and Content. Set up Docker with best practices, automate builds with GitHub Actions, and deploy your application anywhere.","2025-01-15",[38,46,47],"docker","devops",3,{"path":50,"title":51,"description":52,"date":53,"tags":54,"readingMinutes":48},"\u002Fwriting\u002Fhow-to-securely-share-environment-variables-with-your-team","How To Securely Share Environment Variables With Your Team","Learn how to avoid critical security risks in environment variable management and discover how Shelve provides a modern, secure solution for development teams.","2024-10-24",[55,56,57],"security","devtools","shelve",{"path":59,"title":60,"description":61,"date":62,"tags":63,"readingMinutes":66},"\u002Fwriting\u002Fhow-raycast-became-my-ultimate-sidekick","How Raycast Became My Ultimate Sidekick","Let me take you on a journey through the magical land of Raycast – an app that has completely revolutionized my workflow and made me wonder how I ever survived without it.","2024-03-05",[64,65,56],"productivity","raycast",5,{"path":68,"title":69,"description":70,"date":71,"tags":72,"readingMinutes":73},"\u002Fwriting\u002F5-amazing-raycast-nuxt-snippets","5 Amazing Raycast Snippets for Enhancing Your Nuxt (Vue) Projects","Discover 5 powerful Raycast snippets that can transform your Nuxt and Vue development workflow, saving time and enhancing productivity.","2024-01-22",[38,65,64],4,{"path":75,"title":76,"description":77,"date":78,"tags":79,"readingMinutes":80},"\u002Fwriting\u002Fnot-an-impostor","You are not an impostor","Your story is worth telling, and you are not alone in this journey. Here's how to overcome the trap of perfection and embrace your authenticity.","2024-01-11",[37,21],2,[82],{"path":83,"title":84,"date":85},"\u002Fclipboard\u002F2026-04-07","Clipboard #1","2026-04-07",[87,104,117,129,142,156,168,182,193,204,217,228,239,251,263,275,287,297,308,319,331,342,355,366,378,390],{"id":88,"category":89,"date":90,"description":91,"extension":92,"github":93,"meta":94,"name":95,"release":96,"screenshotOptions":96,"screenshotUrl":97,"stem":98,"tags":99,"url":102,"__hash__":103},"works\u002F1.works\u002Fpersonal-agent-template.json","ecosystem","2026-06-11","Open-source template for a durable personal AI agent — web chat, Slack, Linear, and long-term memory","json","https:\u002F\u002Fgithub.com\u002Fvercel-labs\u002Fpersonal-agent-template",{},"Personal Agent Template",null,"\u002Fworks\u002Fpersonal-agent-template.png","1.works\u002Fpersonal-agent-template",[29,38,100,11,101],"vercel","eve","https:\u002F\u002Fpersonal-agent-template.vercel.app","3t1pnE1i1jK5p6Vt_9XeCCod6IHAMCdCfyJYX_M5ObY",{"id":105,"category":89,"date":106,"description":107,"extension":92,"github":108,"meta":109,"name":110,"release":96,"screenshotOptions":96,"screenshotUrl":111,"stem":112,"tags":113,"url":115,"__hash__":116},"works\u002F1.works\u002Fnuxt-connect-starter.json","2026-06-10","Nuxt starter for Vercel Connect","https:\u002F\u002Fgithub.com\u002Fvercel-labs\u002Fnuxt-connect-starter",{},"Nuxt Connect Starter","\u002Fworks\u002Fnuxt-connect-starter.png","1.works\u002Fnuxt-connect-starter",[38,100,11,114],"oauth","https:\u002F\u002Fnuxt-connect-starter.labs.vercel.dev","7SXArkIA4F2hLT8xBol42icO9_RazZO2ZqB4c8HoktU",{"id":118,"category":21,"date":119,"description":120,"extension":92,"github":121,"meta":122,"name":123,"release":96,"screenshotOptions":96,"screenshotUrl":124,"stem":125,"tags":126,"url":121,"__hash__":128},"works\u002F1.works\u002Fnitro-imessage-agent.json","2026-05-04","iMessage agent template","https:\u002F\u002Fgithub.com\u002Fvercel-labs\u002Fnitro-imessage-agent-template",{},"Nitro iMessage Agent","\u002Fworks\u002Fnitro-imessage-agent.png","1.works\u002Fnitro-imessage-agent",[127,29,100,11],"nitro","CQQAGUr0rtr5tS7hgD1AZHquQ6aiCZCrnZCvrRnGLUQ",{"id":130,"category":21,"date":131,"description":132,"extension":92,"github":133,"meta":134,"name":135,"release":96,"screenshotOptions":96,"screenshotUrl":96,"stem":136,"tags":137,"url":140,"__hash__":141},"works\u002F1.works\u002Ff1-league.json","2026-03-07","F1 prediction league with friends","https:\u002F\u002Fgithub.com\u002FHugoRCD\u002Ff1-league",{},"F1 League","1.works\u002Ff1-league",[38,138,139],"nuxthub","game","https:\u002F\u002Ff1.hrcd.fr","um8s0_VM7dz3yWHfTN3lgizBE7PC5yPnkdwDcT8Uc5Q",{"id":143,"category":144,"date":145,"description":146,"extension":92,"github":147,"meta":148,"name":149,"release":96,"screenshotOptions":96,"screenshotUrl":150,"stem":151,"tags":152,"url":154,"__hash__":155},"works\u002F1.works\u002Fgithub-tools.json","featured","2026-02-21","AI SDK tools for GitHub","https:\u002F\u002Fgithub.com\u002FHugoRCD\u002Fgithub-tools",{},"GitHub Tools","\u002Fworks\u002Fgithub-tools.png","1.works\u002Fgithub-tools",[153,29,11],"typescript","https:\u002F\u002Fgithub-tools.com","f-Hgnxt9cTlzbjLffkDOiKfkGD9iKSdaFifXryA7z6U",{"id":157,"category":144,"date":158,"description":159,"extension":92,"github":160,"meta":161,"name":162,"release":96,"screenshotOptions":96,"screenshotUrl":96,"stem":163,"tags":164,"url":166,"__hash__":167},"works\u002F1.works\u002Fevlog.json","2026-01-24","Wide events and structured errors for TypeScript","https:\u002F\u002Fgithub.com\u002FHugoRCD\u002Fevlog",{},"Evlog","1.works\u002Fevlog",[153,165,11],"logging","https:\u002F\u002Fevlog.dev","sWH496NG_E1XoPirIfX5JmQUVQ2w_ffspril7qAlkA4",{"id":169,"category":89,"date":170,"description":171,"extension":92,"github":172,"meta":173,"name":174,"release":96,"screenshotOptions":96,"screenshotUrl":96,"stem":175,"tags":176,"url":180,"__hash__":181},"works\u002F1.works\u002Fcomark.json","2026-01-22","Streaming markdown parser with component support","https:\u002F\u002Fgithub.com\u002Fnuxtlabs\u002Fcomark",{},"Comark","1.works\u002Fcomark",[177,178,179,11],"markdown","vue","react","https:\u002F\u002Fcomark.dev","GK5AFpf3lBPvehlXKn986tmBcg3_Xmb_tKCEnnxpWTE",{"id":183,"category":89,"date":184,"description":185,"extension":92,"github":186,"meta":187,"name":188,"release":96,"screenshotOptions":96,"screenshotUrl":96,"stem":189,"tags":190,"url":191,"__hash__":192},"works\u002F1.works\u002Fknowledge-agent.json","2026-01-20","File-system based AI agent template","https:\u002F\u002Fgithub.com\u002Fvercel-labs\u002Fknowledge-agent-template",{},"Knowledge Agent","1.works\u002Fknowledge-agent",[29,38,100,11],"https:\u002F\u002Fchatsdk-knowledge-agent.vercel.app","tNQhHyfLCP5LYK6MVHx4pL8yuahjerz5yaQkOgG_-ZQ",{"id":194,"category":89,"date":195,"description":196,"extension":92,"github":197,"meta":198,"name":199,"release":96,"screenshotOptions":96,"screenshotUrl":96,"stem":200,"tags":201,"url":202,"__hash__":203},"works\u002F1.works\u002Fnuxt-mcp-toolkit.json","2025-11-08","MCP server toolkit for Nuxt","https:\u002F\u002Fgithub.com\u002Fnuxt-modules\u002Fmcp-toolkit",{},"Nuxt MCP Toolkit","1.works\u002Fnuxt-mcp-toolkit",[38,29,11],"https:\u002F\u002Fmcp-toolkit.nuxt.dev","ULzM9IU6hg3LP3gBC5C-utumevGcfkrU6AtfAGm5ZRg",{"id":205,"category":21,"date":206,"description":207,"extension":92,"github":208,"meta":209,"name":210,"release":211,"screenshotOptions":96,"screenshotUrl":212,"stem":213,"tags":214,"url":215,"__hash__":216},"works\u002F1.works\u002Fnuxt-raycast-extension.json","2025-02-12","Raycast extension for Nuxt","https:\u002F\u002Fgithub.com\u002FHugoRCD\u002Fnuxt-raycast-extension",{},"Nuxt Raycast Extension","2025","\u002Fworks\u002Fnuxt-raycast-extension.png","1.works\u002Fnuxt-raycast-extension",[38,56],"https:\u002F\u002Fwww.raycast.com\u002Fhugorcd\u002Fnuxt-ui","FSAuRTBxt3S7pt8cDONLqjQ4L61bDxRtSlWvY8fHsBI",{"id":218,"category":21,"date":219,"description":220,"extension":92,"github":221,"meta":222,"name":223,"release":96,"screenshotOptions":96,"screenshotUrl":96,"stem":224,"tags":225,"url":226,"__hash__":227},"works\u002F1.works\u002Fnuppets.json","2025-02-07","Nuxt & Vue snippets hub","https:\u002F\u002Fgithub.com\u002FHugoRCD\u002Fnuppets",{},"Nuppets","1.works\u002Fnuppets",[38,178,56],"https:\u002F\u002Fnuppets.dev","CLpZXSqC0wjCZPwL4aRs7Kot7neszICOHQSvDJjCWR8",{"id":229,"category":21,"date":230,"description":231,"extension":92,"github":232,"meta":233,"name":234,"release":96,"screenshotOptions":96,"screenshotUrl":96,"stem":235,"tags":236,"url":232,"__hash__":238},"works\u002F1.works\u002Fnuxt-visitors.json","2025-01-28","Visitor tracking for Nuxt","https:\u002F\u002Fgithub.com\u002FHugoRCD\u002Fnuxt-visitors",{},"Nuxt Visitors","1.works\u002Fnuxt-visitors",[38,237,11],"analytics","O6qC1kdHa3mU4lEBLbhjguCzayCOjI8SVRcC0OIQ9pQ",{"id":240,"category":21,"date":241,"description":242,"extension":92,"github":243,"meta":244,"name":245,"release":211,"screenshotOptions":96,"screenshotUrl":96,"stem":246,"tags":247,"url":249,"__hash__":250},"works\u002F1.works\u002Fnuxt-better-auth.json","2024-10-23","Better Auth demo for Nuxt","https:\u002F\u002Fgithub.com\u002FHugoRCD\u002Fnuxt-better-auth",{},"Nuxt x Better Auth","1.works\u002Fnuxt-better-auth",[38,248],"auth","https:\u002F\u002Fbetter-auth.hrcd.fr\u002F","g_WffyMkhDPY6t-W4ZYxwG2U2JeCseaKHwsaDa8BqvE",{"id":252,"category":21,"date":253,"description":254,"extension":92,"github":255,"meta":256,"name":257,"release":96,"screenshotOptions":96,"screenshotUrl":96,"stem":258,"tags":259,"url":261,"__hash__":262},"works\u002F1.works\u002Finkly.json","2024-08-28","Email signature generator","https:\u002F\u002Fgithub.com\u002FHugoRCD\u002Finkly",{},"Inkly","1.works\u002Finkly",[38,20,260],"template","https:\u002F\u002Finkly.email","AnWWSjjF8RYB8nkIo4vHvzj4_axbq04yDHgkatlZ5H8",{"id":264,"category":21,"date":265,"description":266,"extension":92,"github":267,"meta":268,"name":269,"release":270,"screenshotOptions":96,"screenshotUrl":271,"stem":272,"tags":273,"url":267,"__hash__":274},"works\u002F1.works\u002Feslint-config.json","2024-03-27","ESLint config for TS, Vue & Nuxt","https:\u002F\u002Fgithub.com\u002FHugoRCD\u002Feslint-config",{},"@hrcd\u002Feslint-config","2024","\u002Fworks\u002Feslint-config.png","1.works\u002Feslint-config",[153,56,11],"1kYYxHVQb0eW0Gj1LTSZlzFSI_LhFLSYoZGAolcGhqE",{"id":276,"category":144,"date":277,"description":278,"extension":92,"github":279,"meta":280,"name":281,"release":270,"screenshotOptions":96,"screenshotUrl":282,"stem":283,"tags":284,"url":285,"__hash__":286},"works\u002F1.works\u002Fshelve.json","2024-02-27","Secrets management, simplified","https:\u002F\u002Fgithub.com\u002FHugoRCD\u002Fshelve",{},"Shelve","\u002Fworks\u002Fshelve.png","1.works\u002Fshelve",[153,56,11],"https:\u002F\u002Fshelve.cloud\u002F","DLdElq8I2BQJv_I3IBZCtRTJvB4XXhPafTcgVoK8fP0",{"id":288,"category":144,"date":71,"description":289,"extension":92,"github":290,"meta":291,"name":292,"release":270,"screenshotOptions":96,"screenshotUrl":96,"stem":293,"tags":294,"url":295,"__hash__":296},"works\u002F1.works\u002Fhr-folio.json","My portfolio website","https:\u002F\u002Fgithub.com\u002FHugoRCD\u002Fhr-folio",{},"HR Folio","1.works\u002Fhr-folio",[38,20,11],"\u002F","_5dNFqM90hBqX33lJmQbuLk5jhbua7IfFiipW4zPEa0",{"id":298,"category":21,"date":299,"description":300,"extension":92,"github":301,"meta":302,"name":303,"release":96,"screenshotOptions":96,"screenshotUrl":96,"stem":304,"tags":305,"url":306,"__hash__":307},"works\u002F1.works\u002Fnuxtlog.json","2024-01-18","Changelog & blog template for Nuxt","https:\u002F\u002Fgithub.com\u002FHugoRCD\u002Fnuxtlog",{},"Nuxtlog","1.works\u002Fnuxtlog",[38,260,11],"https:\u002F\u002Fnuxtlog.hrcd.fr","hRYTmi6-MNuc40ALzRCgV9fl_SOkfp1598AbF5kDg54",{"id":309,"category":21,"date":310,"description":311,"extension":92,"github":312,"meta":313,"name":314,"release":96,"screenshotOptions":96,"screenshotUrl":96,"stem":315,"tags":316,"url":317,"__hash__":318},"works\u002F1.works\u002Fcurrencia.json","2023-11-13","Crypto tracker template","https:\u002F\u002Fgithub.com\u002FHugoRCD\u002Fcurrencia",{},"Currencia","1.works\u002Fcurrencia",[38,260],"https:\u002F\u002Fcurrencia.hrcd.fr","ck83zD8-ETismCJrS1tmCyzVcfFKtOBNZ-gV2blgWmQ",{"id":320,"category":144,"date":321,"description":322,"extension":92,"github":323,"meta":324,"name":325,"release":270,"screenshotOptions":96,"screenshotUrl":326,"stem":327,"tags":328,"url":329,"__hash__":330},"works\u002F1.works\u002Fcanvas.json","2023-06-13","Minimal portfolio template","https:\u002F\u002Fgithub.com\u002FHugoRCD\u002Fcanvas",{},"Canvas","\u002Fworks\u002Fcanvas.png","1.works\u002Fcanvas",[38,260,20],"https:\u002F\u002Fcanvas.hrcd.fr\u002F","AJiYTGR0eM5SBzAAwOVHNg_r3Ck8L9by0lG3qixR3UY",{"id":332,"category":21,"date":333,"description":334,"extension":92,"github":335,"meta":336,"name":337,"release":96,"screenshotOptions":96,"screenshotUrl":96,"stem":338,"tags":339,"url":340,"__hash__":341},"works\u002F1.works\u002Fhelpr.json","2023-03-18","Automation tools for workflows","https:\u002F\u002Fgithub.com\u002FHugoRCD\u002Fhelpr",{},"Helpr","1.works\u002Fhelpr",[38,56],"https:\u002F\u002Fhelpr.hrcd.fr","ryMPdPVL2PEjtWIUtvLBMgpY4rCeEzuj3L33GekmrrU",{"id":343,"category":21,"date":344,"description":345,"extension":92,"github":346,"meta":347,"name":348,"release":349,"screenshotOptions":350,"screenshotUrl":96,"stem":351,"tags":352,"url":353,"__hash__":354},"works\u002F1.works\u002Fmaison-hochard.json","2022-09-11","Design & development agency","https:\u002F\u002Fgithub.com\u002FHugoRCD\u002Fmaison-hochard",{},"Maison Hochard","2022",{"delay":66},"1.works\u002Fmaison-hochard",[20,38],"https:\u002F\u002Fmh.hrcd.fr\u002F","91eDnpBDR9JCpGLIAxiHNXRxfqeTcBnA4FHNauKJ5LA",{"id":356,"category":89,"date":357,"description":358,"extension":92,"github":359,"meta":360,"name":361,"release":96,"screenshotOptions":96,"screenshotUrl":96,"stem":362,"tags":363,"url":364,"__hash__":365},"works\u002F1.works\u002Fnuxt.com.json","2022-01-31","The official Nuxt website","https:\u002F\u002Fgithub.com\u002Fnuxt\u002Fnuxt.com",{},"Nuxt.com","1.works\u002Fnuxt.com",[38,20,11],"https:\u002F\u002Fnuxt.com","2cJThN2gMyup6qwItkAYlwNcNmyzenp3cVw25Y5Rkyo",{"id":367,"category":89,"date":368,"description":369,"extension":92,"github":370,"meta":371,"name":372,"release":96,"screenshotOptions":96,"screenshotUrl":96,"stem":373,"tags":374,"url":376,"__hash__":377},"works\u002F1.works\u002Fnuxt-ui.json","2021-11-16","UI library for Nuxt & Vue","https:\u002F\u002Fgithub.com\u002Fnuxt\u002Fui",{},"Nuxt UI","1.works\u002Fnuxt-ui",[178,38,375],"design-system","https:\u002F\u002Fui.nuxt.com","iGGFPi5C55m35yp7u7ix-NOwvhH-zGIn66u5Wk_wlhA",{"id":379,"category":89,"date":380,"description":381,"extension":92,"github":382,"meta":383,"name":384,"release":96,"screenshotOptions":96,"screenshotUrl":96,"stem":385,"tags":386,"url":388,"__hash__":389},"works\u002F1.works\u002Fdocus.json","2020-11-12","Documentation framework for Nuxt","https:\u002F\u002Fgithub.com\u002Fnuxt\u002Fdocus",{},"Docus","1.works\u002Fdocus",[38,387,11],"docs","https:\u002F\u002Fdocus.dev","VUKAqIniX8Qm6-sax0aehqRcWgAx04YX9oPZHG6JZg8",{"id":391,"category":89,"date":392,"description":393,"extension":92,"github":394,"meta":395,"name":396,"release":96,"screenshotOptions":96,"screenshotUrl":397,"stem":398,"tags":399,"url":364,"__hash__":400},"works\u002F1.works\u002Fnuxt.json","2016-10-26","The full-stack Vue framework","https:\u002F\u002Fgithub.com\u002Fnuxt\u002Fnuxt",{},"Nuxt","\u002Fworks\u002Fnuxt.com.png","1.works\u002Fnuxt",[38,178,11],"2yMVvUTornf6xeC59K-PwgcdJvkTxTDb1ZF0eRbIEQ8",{"id":402,"title":6,"body":403,"date":8,"description":7,"extension":751,"image":96,"meta":798,"navigation":763,"path":5,"rawbody":800,"seo":801,"sheet":802,"stem":803,"__hash__":804},"content\u002F2.writing\u002Fwhat-my-pull-requests-look-like-now.md",{"type":404,"value":405,"toc":785},"minimark",[406,410,414,417,420,423,426,431,434,437,440,443,447,450,455,458,461,478,482,493,496,531,534,539,547,551,554,558,561,569,573,576,580,588,592,595,599,608,614,617,623,627,630,668,672,675,678,681,685,691,700,735,742,747,775,778,781],[407,408,6],"h1",{"id":409},"what-my-pull-requests-look-like-now",[411,412,413],"p",{},"You've probably received one by now. Forty files, a title like \"refactor auth\", and a description an agent wrote in about three seconds: \"This PR improves the authentication flow and fixes several issues.\" Call it a slop grenade. Someone pulled the pin, rolled it into your review queue and walked away. Defusing it is now your job.",[411,415,416],{},"The problem isn't that an agent wrote the code. It's that nothing in the PR helps you trust it.",[411,418,419],{},"And that part matters more every month. Agents write more of our code, and I think we'll read less and less of it, maybe one day almost none. When you stop reading every line, you judge a change by what's around it: what it was meant to do, who decided how, and proof that it does it. So that's the part of my agents' output I've been working on: the pull request itself.",[411,421,422],{},"Mine now do three things. The first line says who did what. The body shows the change with the evidence that fits it: before and after captures for a page, both outputs for a bug, measured numbers for a speed-up. The last lines explain it in plain words.",[411,424,425],{},"It doesn't solve everything, and I'll come back to what it doesn't. But it's the biggest gain in confidence I've found for the least effort. Below are three real PRs, what each part gives the reviewer, and a skill you can install so your agents write PRs the same way.",[427,428,430],"h2",{"id":429},"why-describing-isnt-enough","Why describing isn't enough",[411,432,433],{},"\"Fixed the layout on mobile\" tells the reviewer what the author believes happened. To check it, they have to rebuild what the author already saw: find the page, open both versions, resize the window to the same width. Most of my review time goes into exactly that.",[411,435,436],{},"The paragraph is usually honest, but it isn't evidence. The same page at the same phone width, before and after, would be.",[411,438,439],{},"We skipped that part for years because it took time: matching the viewport, cropping the same element twice, recording a hover, running a benchmark more than once. An agent does all of that in a few minutes, and it doesn't get bored on the fourth screenshot, so there's no reason to skip it anymore.",[411,441,442],{},"It also matters more now. If you're not going to read every line of a change, the description is most of what you have to judge it by.",[427,444,446],{"id":445},"the-first-line","The first line",[411,448,449],{},"Every PR I open starts with one line. It answers the question everyone has about code an agent wrote: is this a prompt turned into code, or did someone think it through? And it tells the reviewer what to look at.",[451,452],"screenshot",{"alt":453,"src":454},"The first line of four real pull requests, annotated in red. Each starts with 'Written by an AI agent on behalf of @HugoRCD'. The middle says what Hugo did: nothing added when he gave the task, 'following his spec', or 'who shaped the solution'. The end says '@HugoRCD has reviewed it', except the last, which says 'has not reviewed it yet'.","\u002Fimages\u002Fwriting\u002Fprs\u002Fwho-did-what.webp",[411,456,457],{},"The middle changes with what I actually did. Nothing is added when I gave the task and approved the approach. \"Following his spec\" means I wrote the plan first, as an issue or a doc, so the spec deserves a review too. \"Who shaped the solution\" means we worked out the architecture and the trade-offs together, so the decisions are mine to defend.",[411,459,460],{},"The end says whether I've read it: \"has not reviewed it yet\" when it goes up, \"has reviewed it\" once I have. If it says I haven't, you're the first person to look at it, and you should review it that way.",[411,462,463,464,471,472,477],{},"It started with ",[465,466,470],"a",{"href":467,"rel":468},"https:\u002F\u002Froe.dev",[469],"nofollow","Daniel Roe","'s ",[465,473,476],{"href":474,"rel":475},"https:\u002F\u002Froe.dev\u002Fblog\u002Fusing-ai-in-open-source",[469],"Using AI in open source",": never let an LLM speak for you. The line is how I keep to that when it writes the PR.",[427,479,481],{"id":480},"evidence-that-fits-the-change","Evidence that fits the change",[411,483,484,485,489,490,492],{},"I keep my rules for agents in an ",[486,487,488],"code",{},"AGENTS.md"," file. It's plain Markdown that most coding agents read before they start, either in a project or, for rules that apply everywhere, in your home folder. I covered how mine is organised in ",[465,491,25],{"href":24},". The part about PRs starts with one sentence: a PR shows that the change works, it doesn't only say so.",[411,494,495],{},"What counts as showing depends on the change. A screenshot proves a layout and nothing about speed. A benchmark proves speed and nothing about a layout. So the rule is a table, not a template:",[497,498,499,507,513,519,525],"ul",{},[500,501,502,506],"li",{},[503,504,505],"strong",{},"Something you can see:"," the same page before and after, at the same size and the same crop. A short video when it moves.",[500,508,509,512],{},[503,510,511],{},"A bug:"," the same input on both sides, and what came out each time.",[500,514,515,518],{},[503,516,517],{},"Faster or cheaper:"," the same workload measured on both sides, more than once.",[500,520,521,524],{},[503,522,523],{},"A command or a build:"," its real output before and after, not retyped.",[500,526,527,530],{},[503,528,529],{},"A new API:"," the code someone would write to use it.",[411,532,533],{},"Here's what that gives on three PRs from October.",[535,536,538],"h3",{"id":537},"a-page","A page",[411,540,541,546],{},[465,542,545],{"href":543,"rel":544},"https:\u002F\u002Fgithub.com\u002Fnuxt\u002Fnuxt.com\u002Fpull\u002F2502",[469],"nuxt.com #2502"," turned the Nuxt showcase from a wall of website screenshots into a wall of logos, so you can tell at a glance which brands use Nuxt. The PR has eleven screenshots and two videos.",[451,548],{"alt":549,"src":550,"href":543},"The description of nuxt.com pull request 2502, annotated in red: the first line, a one-paragraph problem statement, the showcase page before and after at the same crop, the homepage logo row, and the page at phone width.","\u002Fimages\u002Fwriting\u002Fprs\u002Fui.webp",[411,552,553],{},"What makes it useful is that both sides of every pair are framed the same way: same section of the page, same size, same crop. When nothing else differs, the only change you see is the PR's. Then the homepage gets its own pair because the change reaches it, a phone width because that's where layouts break, and a video because a screenshot can't show a hover. Someone reviewing it can judge the design without checking out the branch.",[535,555,557],{"id":556},"a-bug","A bug",[411,559,560],{},"Nuxi, the assistant on nuxt.com, couldn't read what people pasted into it. Long pastes became attachments, the model only received a file path, and the tools that could open that path were turned off. So the most common debugging question, \"here's my stack trace, what's wrong?\", got an apology.",[411,562,563,568],{},[465,564,567],{"href":565,"rel":566},"https:\u002F\u002Fgithub.com\u002Fnuxt\u002Fnuxt.com\u002Fpull\u002F2501",[469],"nuxt.com #2501"," fixes that. To show it, the PR asks both versions the same question about the same paste, and puts the two answers next to each other, copied word for word.",[451,570],{"alt":571,"src":572,"href":565},"The description of nuxt.com pull request 2501, annotated in red: the cause traced to the disabled tools, the same paste and question on both sides, the two real answers as a diff, a second bug visible in the same output, screenshots of both chats, and a testing note saying the tests were not run against the old code first.","\u002Fimages\u002Fwriting\u002Fprs\u002Fbug.webp",[411,574,575],{},"Showing the real output pays off twice. You can check the fix yourself instead of trusting a summary. And the same output shows a second bug: production also labelled the stack trace as a YAML file. A paragraph saying \"Nuxi can read pastes now\" would have hidden both.",[535,577,579],{"id":578},"faster-and-cheaper","Faster and cheaper",[411,581,582,587],{},[465,583,586],{"href":584,"rel":585},"https:\u002F\u002Fgithub.com\u002Fnuxt\u002Fnuxt.com\u002Fpull\u002F2521",[469],"nuxt.com #2521"," moved Nuxi from Claude Sonnet 4.6 to Claude Haiku 5.5. Changing the model behind an assistant is the kind of change that's easy to make and hard to judge, so the PR measures it: the real agent, with its real tools, answering six typical questions, each answer graded against a rubric.",[451,589],{"alt":590,"src":591,"href":584},"The description of nuxt.com pull request 2521, annotated in red: a setting the gateway dropped silently, each fallback model tested on its own with one failing, the benchmark method, two runs of the new model, the result of 2.6 times faster and 12 times cheaper at the same quality, a second comparison of thinking effort, the limits of the test, and the ELI5.","\u002Fimages\u002Fwriting\u002Fprs\u002Ffaster.webp",[411,593,594],{},"The result is in one sentence: about 2.6× faster and 12× cheaper per answer, at the same quality. What makes it believable is around it. The new model runs twice, because one run can be luck. Each fallback model was also called on its own, and the old first fallback turned out to reject the new settings, so it would have failed the day it was needed. And a \"Limits\" section says what wasn't tested and what to watch after the deploy. Six questions is a small sample, and the PR says so before anyone has to ask.",[427,596,598],{"id":597},"the-eli5","The ELI5",[411,600,601,602,607],{},"Every PR ends with an ELI5, short for \"explain like I'm five\": two or three sentences someone outside the project would follow. This is the one from ",[465,603,606],{"href":604,"rel":605},"https:\u002F\u002Fgithub.com\u002Fevloghq\u002Fevlog\u002Fpull\u002F937",[469],"evlog #937",", which removed duplicate fields from evlog's error responses:",[609,610,611],"blockquote",{},[411,612,613],{},"When a request fails, evlog sends a small JSON note back. It used to write the status number twice and the message three times under different names. Now it writes each one once.",[411,615,616],{},"The technical body is for the reviewer. The ELI5 is for everyone else: the person skimming the changelog, the maintainer of another project, me in six months. It's also a decent check. If the ELI5 doesn't make sense, the change usually doesn't either.",[618,619],"link-card",{"description":620,"title":621,"url":622},"24 September 2026","Ending every PR with an ELI5","https:\u002F\u002Fx.com\u002Fhugorcd\u002Fstatus\u002F2103190158053151108",[427,624,626],{"id":625},"keeping-it-honest","Keeping it honest",[411,628,629],{},"Evidence is only worth something if you can trust it, and an agent will happily produce something that looks like evidence. So a few rules sit next to the ones above:",[497,631,632,638,644,650,662],{},[500,633,634,637],{},[503,635,636],{},"\"Before\" is what's live."," Production, the base branch or the last deploy. Never a reverted or stashed copy made to look like it.",[500,639,640,643],{},[503,641,642],{},"Look at every capture."," An agent can screenshot the wrong page with total confidence. It checks each image shows the change before using it.",[500,645,646,649],{},[503,647,648],{},"No real data."," Demo or sanitised content only: no users, tokens or private messages in a screenshot.",[500,651,652,655,656,661],{},[503,653,654],{},"Say what didn't happen."," #2501 says its tests were written with the fix and not run against the old code first. ",[465,657,660],{"href":658,"rel":659},"https:\u002F\u002Fgithub.com\u002Fnuxt\u002Fnuxt.com\u002Fpull\u002F2523",[469],"#2523"," says of its own result: \"it hasn't been checked in a browser yet.\" It's one sentence, and it tells the reviewer exactly what to check themselves.",[500,663,664,667],{},[503,665,666],{},"Security fixes are the exception."," A public PR is the wrong place for a working exploit. For those, the description stays short and the details wait until the fix is released.",[427,669,671],{"id":670},"what-it-doesnt-fix","What it doesn't fix",[411,673,674],{},"A good description can sit on top of bad code. Evidence shows the cases someone thought to capture, not the ones nobody thought of. It doesn't replace tests, types, or someone who knows the codebase reading the parts that matter. And an agent that's confidently wrong in the code can be confidently wrong in the description too, which is why the honesty rules above exist.",[411,676,677],{},"What it does is move the PR from \"trust me\" to \"check this\". You know what was intended, who decided it, and what was actually seen working. That's enough to decide where to spend your attention, which is most of what reviewing becomes when you can't read everything.",[411,679,680],{},"It has a cost. The descriptions are longer, and most people won't read all of one, so the order matters: who did what, the problem in one paragraph, the evidence, then the details. Stop wherever you like, and you'll still know more than a title would tell you. The agent spends a few more minutes per PR, and I spend less of my review rebuilding what it already saw.",[427,682,684],{"id":683},"do-the-same","Do the same",[411,686,687,688,690],{},"I didn't want to hand out my ",[486,689,488],{},". It's full of things that only make sense for me. So I turned the parts that work for anyone into a skill: a short file that tells an agent how to do one job, here writing a PR description. It covers the first line, the order of the description, the evidence for each kind of change, the honesty rules, and it shows you the description before anything is posted.",[411,692,693,694,699],{},"Install it with the ",[465,695,698],{"href":696,"rel":697},"https:\u002F\u002Fskills.sh",[469],"skills CLI",":",[701,702,707],"pre",{"className":703,"code":704,"language":705,"meta":706,"style":706},"language-bash shiki shiki-themes github-light github-dark github-dark","npx skills add https:\u002F\u002Fhugorcd.com --skill pr-writing\n","bash","",[486,708,709],{"__ignoreMap":706},[710,711,714,718,722,725,728,732],"span",{"class":712,"line":713},"line",1,[710,715,717],{"class":716},"shcOC","npx",[710,719,721],{"class":720},"sfrk1"," skills",[710,723,724],{"class":720}," add",[710,726,727],{"class":720}," https:\u002F\u002Fhugorcd.com",[710,729,731],{"class":730},"suiK_"," --skill",[710,733,734],{"class":720}," pr-writing\n",[411,736,737,738,741],{},"Add ",[486,739,740],{},"-g"," to install it for every project instead of only the current one.",[411,743,744,745,699],{},"An agent loads a skill when it decides the skill is relevant, which isn't always. To make sure it's used every time, add this to your ",[486,746,488],{},[701,748,752],{"className":749,"code":750,"language":751,"meta":706,"style":706},"language-md shiki shiki-themes github-light github-dark github-dark","## Pull requests\n\nBefore you open a pull request or write its description,\nload the `pr-writing` skill and follow it.\n","md",[486,753,754,759,765,770],{"__ignoreMap":706},[710,755,756],{"class":712,"line":713},[710,757,758],{},"## Pull requests\n",[710,760,761],{"class":712,"line":80},[710,762,764],{"emptyLinePlaceholder":763},true,"\n",[710,766,767],{"class":712,"line":48},[710,768,769],{},"Before you open a pull request or write its description,\n",[710,771,772],{"class":712,"line":73},[710,773,774],{},"load the `pr-writing` skill and follow it.\n",[411,776,777],{},"Then read the skill and change what doesn't fit. It's a starting point, not a standard. If your team reviews differently, or your project has a PR template, adjust it until it describes how you want to work.",[411,779,780],{},"And if you don't use agents at all, the same checklist works by hand. It just takes longer.",[782,783,784],"style",{},"html pre.shiki code .shcOC, html code.shiki .shcOC{--shiki-light:#6F42C1;--shiki-default:#B392F0;--shiki-dark:#B392F0}html pre.shiki code .sfrk1, html code.shiki .sfrk1{--shiki-light:#032F62;--shiki-default:#9ECBFF;--shiki-dark:#9ECBFF}html pre.shiki code .suiK_, html code.shiki .suiK_{--shiki-light:#005CC5;--shiki-default:#79B8FF;--shiki-dark:#79B8FF}html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":706,"searchDepth":80,"depth":80,"links":786},[787,788,789,794,795,796,797],{"id":429,"depth":80,"text":430},{"id":445,"depth":80,"text":446},{"id":480,"depth":80,"text":481,"children":790},[791,792,793],{"id":537,"depth":48,"text":538},{"id":556,"depth":48,"text":557},{"id":578,"depth":48,"text":579},{"id":597,"depth":80,"text":598},{"id":625,"depth":80,"text":626},{"id":670,"depth":80,"text":671},{"id":683,"depth":80,"text":684},{"tags":799},[10,11,12],"---\ntitle: What My Pull Requests Look Like Now\ndate: 2026-10-27\ndescription: As we read less of the code agents write, the pull request becomes what we judge a change by. Mine now say who did what and show that the change works. Here are real ones, what they don't fix, and a skill to do the same.\ntags:\n  - agents\n  - open-source\n  - workflow\n---\n\n# What My Pull Requests Look Like Now\n\nYou've probably received one by now. Forty files, a title like \"refactor auth\", and a description an agent wrote in about three seconds: \"This PR improves the authentication flow and fixes several issues.\" Call it a slop grenade. Someone pulled the pin, rolled it into your review queue and walked away. Defusing it is now your job.\n\nThe problem isn't that an agent wrote the code. It's that nothing in the PR helps you trust it.\n\nAnd that part matters more every month. Agents write more of our code, and I think we'll read less and less of it, maybe one day almost none. When you stop reading every line, you judge a change by what's around it: what it was meant to do, who decided how, and proof that it does it. So that's the part of my agents' output I've been working on: the pull request itself.\n\nMine now do three things. The first line says who did what. The body shows the change with the evidence that fits it: before and after captures for a page, both outputs for a bug, measured numbers for a speed-up. The last lines explain it in plain words.\n\nIt doesn't solve everything, and I'll come back to what it doesn't. But it's the biggest gain in confidence I've found for the least effort. Below are three real PRs, what each part gives the reviewer, and a skill you can install so your agents write PRs the same way.\n\n## Why describing isn't enough\n\n\"Fixed the layout on mobile\" tells the reviewer what the author believes happened. To check it, they have to rebuild what the author already saw: find the page, open both versions, resize the window to the same width. Most of my review time goes into exactly that.\n\nThe paragraph is usually honest, but it isn't evidence. The same page at the same phone width, before and after, would be.\n\nWe skipped that part for years because it took time: matching the viewport, cropping the same element twice, recording a hover, running a benchmark more than once. An agent does all of that in a few minutes, and it doesn't get bored on the fourth screenshot, so there's no reason to skip it anymore.\n\nIt also matters more now. If you're not going to read every line of a change, the description is most of what you have to judge it by.\n\n## The first line\n\nEvery PR I open starts with one line. It answers the question everyone has about code an agent wrote: is this a prompt turned into code, or did someone think it through? And it tells the reviewer what to look at.\n\n::screenshot\n---\nsrc: \u002Fimages\u002Fwriting\u002Fprs\u002Fwho-did-what.webp\nalt: \"The first line of four real pull requests, annotated in red. Each starts with 'Written by an AI agent on behalf of @HugoRCD'. The middle says what Hugo did: nothing added when he gave the task, 'following his spec', or 'who shaped the solution'. The end says '@HugoRCD has reviewed it', except the last, which says 'has not reviewed it yet'.\"\n---\n::\n\nThe middle changes with what I actually did. Nothing is added when I gave the task and approved the approach. \"Following his spec\" means I wrote the plan first, as an issue or a doc, so the spec deserves a review too. \"Who shaped the solution\" means we worked out the architecture and the trade-offs together, so the decisions are mine to defend.\n\nThe end says whether I've read it: \"has not reviewed it yet\" when it goes up, \"has reviewed it\" once I have. If it says I haven't, you're the first person to look at it, and you should review it that way.\n\nIt started with [Daniel Roe](https:\u002F\u002Froe.dev)'s [Using AI in open source](https:\u002F\u002Froe.dev\u002Fblog\u002Fusing-ai-in-open-source): never let an LLM speak for you. The line is how I keep to that when it writes the PR.\n\n## Evidence that fits the change\n\nI keep my rules for agents in an `AGENTS.md` file. It's plain Markdown that most coding agents read before they start, either in a project or, for rules that apply everywhere, in your home folder. I covered how mine is organised in [How I Work With Agents Right Now](\u002Fwriting\u002Fhow-i-work-with-agents-right-now). The part about PRs starts with one sentence: a PR shows that the change works, it doesn't only say so.\n\nWhat counts as showing depends on the change. A screenshot proves a layout and nothing about speed. A benchmark proves speed and nothing about a layout. So the rule is a table, not a template:\n\n- **Something you can see:** the same page before and after, at the same size and the same crop. A short video when it moves.\n- **A bug:** the same input on both sides, and what came out each time.\n- **Faster or cheaper:** the same workload measured on both sides, more than once.\n- **A command or a build:** its real output before and after, not retyped.\n- **A new API:** the code someone would write to use it.\n\nHere's what that gives on three PRs from October.\n\n### A page\n\n[nuxt.com #2502](https:\u002F\u002Fgithub.com\u002Fnuxt\u002Fnuxt.com\u002Fpull\u002F2502) turned the Nuxt showcase from a wall of website screenshots into a wall of logos, so you can tell at a glance which brands use Nuxt. The PR has eleven screenshots and two videos.\n\n::screenshot\n---\nsrc: \u002Fimages\u002Fwriting\u002Fprs\u002Fui.webp\nalt: \"The description of nuxt.com pull request 2502, annotated in red: the first line, a one-paragraph problem statement, the showcase page before and after at the same crop, the homepage logo row, and the page at phone width.\"\nhref: https:\u002F\u002Fgithub.com\u002Fnuxt\u002Fnuxt.com\u002Fpull\u002F2502\n---\n::\n\nWhat makes it useful is that both sides of every pair are framed the same way: same section of the page, same size, same crop. When nothing else differs, the only change you see is the PR's. Then the homepage gets its own pair because the change reaches it, a phone width because that's where layouts break, and a video because a screenshot can't show a hover. Someone reviewing it can judge the design without checking out the branch.\n\n### A bug\n\nNuxi, the assistant on nuxt.com, couldn't read what people pasted into it. Long pastes became attachments, the model only received a file path, and the tools that could open that path were turned off. So the most common debugging question, \"here's my stack trace, what's wrong?\", got an apology.\n\n[nuxt.com #2501](https:\u002F\u002Fgithub.com\u002Fnuxt\u002Fnuxt.com\u002Fpull\u002F2501) fixes that. To show it, the PR asks both versions the same question about the same paste, and puts the two answers next to each other, copied word for word.\n\n::screenshot\n---\nsrc: \u002Fimages\u002Fwriting\u002Fprs\u002Fbug.webp\nalt: \"The description of nuxt.com pull request 2501, annotated in red: the cause traced to the disabled tools, the same paste and question on both sides, the two real answers as a diff, a second bug visible in the same output, screenshots of both chats, and a testing note saying the tests were not run against the old code first.\"\nhref: https:\u002F\u002Fgithub.com\u002Fnuxt\u002Fnuxt.com\u002Fpull\u002F2501\n---\n::\n\nShowing the real output pays off twice. You can check the fix yourself instead of trusting a summary. And the same output shows a second bug: production also labelled the stack trace as a YAML file. A paragraph saying \"Nuxi can read pastes now\" would have hidden both.\n\n### Faster and cheaper\n\n[nuxt.com #2521](https:\u002F\u002Fgithub.com\u002Fnuxt\u002Fnuxt.com\u002Fpull\u002F2521) moved Nuxi from Claude Sonnet 4.6 to Claude Haiku 5.5. Changing the model behind an assistant is the kind of change that's easy to make and hard to judge, so the PR measures it: the real agent, with its real tools, answering six typical questions, each answer graded against a rubric.\n\n::screenshot\n---\nsrc: \u002Fimages\u002Fwriting\u002Fprs\u002Ffaster.webp\nalt: \"The description of nuxt.com pull request 2521, annotated in red: a setting the gateway dropped silently, each fallback model tested on its own with one failing, the benchmark method, two runs of the new model, the result of 2.6 times faster and 12 times cheaper at the same quality, a second comparison of thinking effort, the limits of the test, and the ELI5.\"\nhref: https:\u002F\u002Fgithub.com\u002Fnuxt\u002Fnuxt.com\u002Fpull\u002F2521\n---\n::\n\nThe result is in one sentence: about 2.6× faster and 12× cheaper per answer, at the same quality. What makes it believable is around it. The new model runs twice, because one run can be luck. Each fallback model was also called on its own, and the old first fallback turned out to reject the new settings, so it would have failed the day it was needed. And a \"Limits\" section says what wasn't tested and what to watch after the deploy. Six questions is a small sample, and the PR says so before anyone has to ask.\n\n## The ELI5\n\nEvery PR ends with an ELI5, short for \"explain like I'm five\": two or three sentences someone outside the project would follow. This is the one from [evlog #937](https:\u002F\u002Fgithub.com\u002Fevloghq\u002Fevlog\u002Fpull\u002F937), which removed duplicate fields from evlog's error responses:\n\n> When a request fails, evlog sends a small JSON note back. It used to write the status number twice and the message three times under different names. Now it writes each one once.\n\nThe technical body is for the reviewer. The ELI5 is for everyone else: the person skimming the changelog, the maintainer of another project, me in six months. It's also a decent check. If the ELI5 doesn't make sense, the change usually doesn't either.\n\n:link-card{description=\"24 September 2026\" title=\"Ending every PR with an ELI5\" url=\"https:\u002F\u002Fx.com\u002Fhugorcd\u002Fstatus\u002F2103190158053151108\"}\n\n## Keeping it honest\n\nEvidence is only worth something if you can trust it, and an agent will happily produce something that looks like evidence. So a few rules sit next to the ones above:\n\n- **\"Before\" is what's live.** Production, the base branch or the last deploy. Never a reverted or stashed copy made to look like it.\n- **Look at every capture.** An agent can screenshot the wrong page with total confidence. It checks each image shows the change before using it.\n- **No real data.** Demo or sanitised content only: no users, tokens or private messages in a screenshot.\n- **Say what didn't happen.** #2501 says its tests were written with the fix and not run against the old code first. [#2523](https:\u002F\u002Fgithub.com\u002Fnuxt\u002Fnuxt.com\u002Fpull\u002F2523) says of its own result: \"it hasn't been checked in a browser yet.\" It's one sentence, and it tells the reviewer exactly what to check themselves.\n- **Security fixes are the exception.** A public PR is the wrong place for a working exploit. For those, the description stays short and the details wait until the fix is released.\n\n## What it doesn't fix\n\nA good description can sit on top of bad code. Evidence shows the cases someone thought to capture, not the ones nobody thought of. It doesn't replace tests, types, or someone who knows the codebase reading the parts that matter. And an agent that's confidently wrong in the code can be confidently wrong in the description too, which is why the honesty rules above exist.\n\nWhat it does is move the PR from \"trust me\" to \"check this\". You know what was intended, who decided it, and what was actually seen working. That's enough to decide where to spend your attention, which is most of what reviewing becomes when you can't read everything.\n\nIt has a cost. The descriptions are longer, and most people won't read all of one, so the order matters: who did what, the problem in one paragraph, the evidence, then the details. Stop wherever you like, and you'll still know more than a title would tell you. The agent spends a few more minutes per PR, and I spend less of my review rebuilding what it already saw.\n\n## Do the same\n\nI didn't want to hand out my `AGENTS.md`. It's full of things that only make sense for me. So I turned the parts that work for anyone into a skill: a short file that tells an agent how to do one job, here writing a PR description. It covers the first line, the order of the description, the evidence for each kind of change, the honesty rules, and it shows you the description before anything is posted.\n\nInstall it with the [skills CLI](https:\u002F\u002Fskills.sh):\n\n```bash\nnpx skills add https:\u002F\u002Fhugorcd.com --skill pr-writing\n```\n\nAdd `-g` to install it for every project instead of only the current one.\n\nAn agent loads a skill when it decides the skill is relevant, which isn't always. To make sure it's used every time, add this to your `AGENTS.md`:\n\n```md\n## Pull requests\n\nBefore you open a pull request or write its description,\nload the `pr-writing` skill and follow it.\n```\n\nThen read the skill and change what doesn't fit. It's a starting point, not a standard. If your team reviews differently, or your project has a PR template, adjust it until it describes how you want to work.\n\nAnd if you don't use agents at all, the same checklist works by hand. It just takes longer.\n",{"title":6,"description":7},false,"2.writing\u002Fwhat-my-pull-requests-look-like-now","mOlz52HWqZ26O1EjkwVNcuctVIPDEsDMMUJkKSy-LAw",1793708555404]