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.
Was es macht
Ein Antwortmuster für Review-Kommentare: das gesamte Feedback lesen, jede Anforderung in eigenen Worten wiedergeben, sie am echten Code prüfen, entscheiden, ob sie für dieses Projekt stimmig ist, mit technischer Bestätigung oder begründetem Widerspruch antworten und dann einen Punkt nach dem anderen umsetzen und jeweils testen. Ist ein Punkt unklar, hält es an und fragt, bevor es irgendetwas umsetzt, weil Punkte zusammenhängen können. Feedback von Ihnen gilt als vertrauenswürdig, bei unklarem Umfang fragt es trotzdem nach, und externen Reviewern begegnet es mit gesunder Skepsis: Es prüft, ob der Vorschlag für diese Codebasis stimmt, bestehendes Verhalten nicht bricht, einen Grund für das aktuelle Design hat und auf allen unterstützten Plattformen funktioniert. Dazu kommen ein YAGNI-Check (vor dem „ordentlichen Umsetzen“ nach echter Nutzung suchen), eine Arbeitsreihenfolge (blockierende Probleme, einfache Fixes, komplexe Fixes), wann man widerspricht und wie man sich korrigiert, wenn der Widerspruch falsch war. Es verbietet auch gespielte Zustimmung („Da haben Sie völlig recht!“) und Dankesformeln.
Geeignet für
Pull-Request-Feedback abarbeiten, ohne jeden Vorschlag blind zu übernehmen.
Mittleres Risiko: Wenn Sie es bitten, Feedback umzusetzen, bearbeitet es Ihren Code; seine Hinweise enthalten auch das Antworten in GitHub-Review-Threads mit dem Befehl `gh api`, was unter Ihrem Konto veröffentlicht, prüfen Sie jede Antwort vor dem Senden und lassen Sie es nur auf Ihre Bitte hin posten. Sein Ton ist eigenwillig: Es verbietet Dankesbekundungen und lange Entschuldigungen, was manche Teams nicht wollen. Bei Urteilen, die sich nicht am Code prüfen lassen, bleibt es auf Sie angewiesen. Einmal mit erfundenen Review-Kommentaren getestet: Es bat zuerst um Klärung des vagen Punkts und widersprach zwei Vorschlägen.