I'd hold off on implementing anything until item 4 is clarified, because the items may be related. Here is how I'd respond and in what order I'd work.
Response to the reviewer
tmp→pendingOrders: Agreed. I'll make this change.- Metrics system for
/stats: "Nothing in the codebase calls/stats, so I don't see a need for a database, date filters or CSV export. Should we remove the endpoint (YAGNI) instead? Is there a caller outside this repo that I'm missing?" - Pagination off-by-one: Agreed. I'll fix it and add a boundary test.
- "Make the error handling better": "Which paths do you mean? What's the failure you want handled (swallowed exceptions, missing status codes, retries, error messages)? I'd rather not guess."
- Remove the v1 date parser: "I can't remove this yet. Our mobile app on older OS versions still uses it, so removing it would break those clients. Can we drop it once that OS version is out of our support window, or add a deprecation note and a usage metric now?"
Order of work
- Clarify first. Ask about items 2, 4 and 5 and wait for answers. Item 4 is blocking because it's vague. Items 2 and 5 are pushback and need a decision.
- Verify. Before sending the pushback, I'd grep for
/statscallers and for v1 parser usage, so I'm not relying only on what I remember. I'd also check how the mobile clients reach the parser. - Implement the agreed items one at a time, testing each:
- Item 3, the pagination fix. It's a logic bug, so it comes first, with a test.
- Item 1, the rename. It's a simple, low-risk change. I'd run the tests afterward to confirm nothing else referenced
tmp. - Item 4, once clarified.
- Items 2 and 5 only after the reviewer or you decide. For item 2 that means removing the endpoint if you agree. For item 5 it means leaving the parser in place.
- Check for regressions with the full test run, then reply on each review thread with what changed (or the reasoning for not changing it).
Real run in an isolated folder with only this skill installed. Only the Skill and Read tools were enabled, so no command was run and no file was written. The example is fictional. The pull request feedback is invented.
Qué hace
Un patrón de respuesta para comentarios de revisión: leer todos los comentarios, reformular cada requisito, verificarlo contra la base de código real, decidir si es adecuado para este proyecto, responder con una confirmación técnica o con una objeción razonada, y después implementar un punto a la vez y probar cada uno. Si algún punto no está claro, se detiene y pregunta antes de implementar nada, porque los puntos pueden estar relacionados. Considera fiables los comentarios que proceden de ti, pero aun así pregunta cuando el alcance no está claro, y trata a los revisores externos con un escepticismo saludable: comprueba que la sugerencia sea correcta para esta base de código, no rompa el comportamiento existente, tenga una razón para el diseño actual y funcione en todas las plataformas compatibles. Añade una comprobación YAGNI (buscar uso real antes de «implementarlo correctamente»), un orden de trabajo (problemas bloqueantes, correcciones simples, correcciones complejas), cuándo oponerte con argumentos y cómo corregirte si te opusiste con argumentos por error. También prohíbe el asentimiento performativo («¡Tienes toda la razón!») y los agradecimientos.
Para qué sirve
Trabajar los comentarios de una pull request sin aplicar a ciegas todas las sugerencias.
Riesgo medio: cuando le pides que actúe sobre los comentarios, edita tu código, y su guía incluye responder en los hilos de revisión de GitHub con el comando `gh api`, que publica con tu cuenta, así que revisa cualquier respuesta antes de enviarla y deja que publique solo cuando se lo pidas. Su tono es marcado: prohíbe expresar agradecimientos y las disculpas largas, algo que puede que algunos equipos no quieran. Depende de ti para cualquier juicio que no pueda comprobar contra el código. Probada una vez con comentarios de revisión inventados, donde pidió aclarar primero el punto vago y se opuso con argumentos a dos sugerencias.