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.
What it does
A response pattern for review comments: read the whole feedback, restate each requirement, verify it against the real codebase, decide whether it is sound for this project, answer with either a technical acknowledgement or reasoned pushback, then implement one item at a time and test each. If any item is unclear it stops and asks before implementing anything, because items can be related. It treats feedback from you as trusted but still asks when scope is unclear, and treats outside reviewers with healthy scepticism: check that the suggestion is correct for this codebase, does not break existing behaviour, has a reason for the current design and works on all supported platforms. It adds a YAGNI check (search for real usage before "implementing properly"), an order of work (blocking issues, simple fixes, complex fixes), when to push back, and how to correct yourself if you pushed back wrongly. It also bans performative agreement ("You're absolutely right!") and thanks.
Good for
Working through pull request feedback without blindly applying every suggestion.
Medium risk: when you ask it to act on feedback it edits your code, and its guidance includes replying in GitHub review threads with the `gh api` command, which posts under your account, so review any reply before it is sent and only let it post when you ask. Its tone is opinionated: it forbids expressions of thanks and long apologies, which some teams may not want. It relies on you for any judgement it cannot check against the code. Trialled once on invented review comments, where it asked to clarify the vague item first and pushed back on two suggestions.