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.
하는 일
리뷰 코멘트에 대한 대응 패턴입니다. 피드백 전체를 읽고, 각 요구를 다시 말해 보고, 실제 코드베이스와 대조하고, 이 프로젝트에 맞는지 판단하고, 기술적 인정이나 이유 있는 반박으로 답한 뒤, 한 번에 하나씩 구현하며 매번 테스트합니다. 이해되지 않는 항목이 하나라도 있으면 항목들이 서로 관련될 수 있으므로 아무것도 구현하지 않고 멈춰서 먼저 묻습니다. 사용자 본인의 의견은 신뢰하되 범위가 불분명하면 되묻고, 외부 리뷰어에게는 건전한 회의를 유지합니다. 제안이 이 코드베이스에 맞는지, 기존 동작을 깨지 않는지, 현재 설계에 이유가 있는지, 지원하는 모든 플랫폼에서 동작하는지 확인합니다. 또한 YAGNI 점검('제대로 구현'하기 전에 실제 사용을 검색), 작업 순서(막는 문제, 간단한 수정, 복잡한 수정), 반박해야 할 때, 반박이 틀렸을 때 바로잡는 법도 다룹니다. "정말 맞는 말씀입니다!" 같은 겉치레 동조와 감사 표현은 금지합니다.
이런 때 좋습니다
풀 리퀘스트 피드백을 모든 제안을 맹목적으로 따르지 않고 하나씩 처리하고 싶을 때.
중간 위험：의견에 따라 처리해 달라고 하면 코드를 수정합니다. 지침에는 `gh api` 명령으로 GitHub 리뷰 스레드에 답글을 다는 방법이 포함되어 있고 이는 사용자의 계정으로 게시되므로, 보내기 전에 답글을 꼭 확인하고 요청했을 때만 게시하게 하세요. 어조에 주관이 있어 감사 표현과 긴 사과를 금지하는데, 이를 원하지 않는 팀도 있습니다. 코드와 대조할 수 없는 판단은 계속 사용자에게 달려 있습니다. 가상의 리뷰 코멘트로 한 번 시험 실행했는데, 모호한 항목의 확인을 먼저 요청하고 두 제안에 반박했습니다.