[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M72TMASMM7TDW44MYWDMSXQB":3,"skill-same:01M72TMASMM7TDW44MYWDMSXQB":87},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":23,"commitSha":24,"skillDirectory":25,"forksCount":26,"repositoryHtmlUrl":27,"repositoryHomepageUrl":6,"ownerHtmlUrl":28,"ownerBlogUrl":29,"ownerDescription":6,"updatedAt":30,"install":31,"resources":44},"01M72TMASMM7TDW44MYWDMSXQB","ywc-receive-review",null,"(ywc) Use when receiving code-review feedback and about to reply or implement changes; verify comments before agreeing or coding, avoid performative acknowledgments, and clarify unclear items first. Triggers: \"리뷰 받았어\", \"리뷰 코멘트\", \"리뷰 대응\", \"review feedback\", \"received review\", \"respond to review\", \"レビュー受信\", \"レビュー対応\", \"ywc-receive-review\". Do not use for performing a code review (use ywc-impl-review), creating a PR (use ywc-create-pr), or PR-comment automation (use ywc-handle-pr-reviews).","yongwoon\u002Fywc-agent-toolkit","yongwoon","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F9317029?v=4","01M72SZSF6VKANKG5QTMV4V95S","01M72SZSG8HHC3W2CV5P7EJ5AH",8,"MIT","https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fywc-agent-toolkit\u002Fskills\u002Fywc-receive-review\u002FSKILL.md",[],[],"2026-11-10 22:39:42",false,"---\nname: ywc-receive-review\ndescription: >-\n  (ywc) Use when receiving code-review feedback and about to reply or implement\n  changes; verify comments before agreeing or coding, avoid performative\n  acknowledgments, and clarify unclear items first. Triggers: \"리뷰 받았어\",\n  \"리뷰 코멘트\", \"리뷰 대응\", \"review feedback\", \"received review\", \"respond to\n  review\", \"レビュー受信\", \"レビュー対応\", \"ywc-receive-review\". Do not use\n  for performing a code review (use ywc-impl-review), creating a PR (use\n  ywc-create-pr), or PR-comment automation (use ywc-handle-pr-reviews).\n---\n\n# ywc-receive-review\n\n**Announce at start:** \"I'm using the ywc-receive-review skill to verify review feedback before responding — no performative agreement, no blind implementation.\"\n\nThis skill is the attitude layer for receiving code-review feedback. It exists because the default LLM behavior — agreeing eagerly to whatever the reviewer says and starting to implement — produces three failure modes the ywc workflow must avoid: (1) implementing a \"fix\" that breaks a deliberately-shaped behavior the reviewer did not know about; (2) blindly removing code the reviewer thought was unused but is actually called from a path they did not see; (3) burning trust by saying \"You're absolutely right!\" to a wrong suggestion and then quietly reverting. Adapted from `superpowers:receiving-code-review`, tightened to integrate as the attitude layer of `ywc-handle-pr-reviews` (which owns the *automation*; this skill owns the *judgment*).\n\n## The Iron Law\n\n```text\nVERIFY BEFORE IMPLEMENTING. NO PERFORMATIVE AGREEMENT, EVER.\n```\n\nReceiving review feedback is **technical evaluation**, not emotional performance. Every item is a *suggestion to evaluate*, not an order to follow. The act of agreeing must be backed by a technical check; the act of disagreeing must be backed by technical reasoning.\n\n## Rationalization Defense\n\nWhen tempted to skip verification or to soften the response, check this table first:\n\n| Excuse | Reality |\n|---|---|\n| \"Saying 'You're right!' is polite — it doesn't change the technical outcome\" | It changes two things: (1) it commits you to an implementation before you have verified the suggestion holds, which makes the post-verification correction expensive; (2) it teaches the reviewer (and any teammate reading the thread) that your agreements are not load-bearing. State the fix instead of the gratitude — actions speak. |\n| \"The reviewer is more senior, I should defer\" | Authority is not a check against a codebase. A senior reviewer who has not opened the file in 6 months may suggest a change that broke something last week. Verify against current code; then defer with evidence, or push back with evidence. |\n| \"Pushing back feels confrontational — implementing is friendlier\" | Friendlier today, hostile tomorrow when the implementation breaks production and someone has to figure out why a clearly-wrong suggestion was accepted without comment. Technical pushback **is** the courteous response — it preserves the reviewer's intent, your trust, and the codebase. |\n| \"I'll batch-acknowledge all 12 items and then implement them\" | Items are often related. Partial understanding of one becomes partial implementation of another. Read all items, clarify unclear ones, **then** implement. Acknowledging without understanding is a worse failure than asking. |\n| \"The bot review is automated, no harm in agreeing reflexively\" | The bot has no context for `\u002F\u002F eslint-disable-next-line` next to a known-safe pattern, for the `as any` that documents a deliberate type erasure, for the `console.log` that was the user's manual debug tool. Bot suggestions need the same verification a human's would. |\n| \"If I push back and I'm wrong, I look incompetent\" | If you defer and you are wrong, the codebase has a documented bug *and* the reviewer trusts that subsequent acceptances mean you checked. Both costs compound. Push back with technical reasoning; if you are wrong, the correction is one sentence: \"Verified, you are right because \u003CX>. Implementing.\" |\n| \"Saying 'Thanks for catching that!' shows I'm a team player\" | The codebase does not record team-player points. It records the fix. Surface the fix; the team-player signal is implicit in the speed and accuracy of the action. |\n| \"The user is my human partner — I should not push back on them\" | The human partner asks for pushback when the partner is wrong. Implementing a wrong instruction without surfacing the concern is the failure mode. Use technical reasoning, not defiance: \"Before implementing, I want to flag that \u003CX> appears to conflict with \u003CY>. Should I proceed, or revise?\" |\n| \"Multiple reviewers gave contradicting suggestions — I'll pick whichever feels right\" | Surface the contradiction and ask the human partner. Reviewers who disagree have not seen each other's comments; you have. The job is to surface, not to arbitrate. |\n| \"Asking for clarification slows the review down\" | Implementing the wrong interpretation and then re-implementing it correctly is slower than asking once. Estimate: 1 question (~1 minute round-trip) beats a misimplementation (~30 minutes plus second review). |\n\n**Violating the letter of this discipline is violating the spirit.** The codebase records what was implemented, not what was said. Every \"You're absolutely right!\" without a corresponding verified fix is a small lie that compounds.\n\n## The Response Pattern\n\nFor every reviewer comment, execute these six steps in order. Skipping any step is the failure mode.\n\n```text\nREAD → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT\n```\n\n| # | Step | What it produces |\n|---|---|---|\n| 1 | READ | The full feedback, read without reacting. No agreement, no disagreement, no implementation tool calls yet. |\n| 2 | UNDERSTAND | Restate the technical requirement in your own words, or — if any part is unclear — ask before advancing. |\n| 3 | VERIFY | Check the claim against the current codebase: open the file, run the failing test, grep for the alleged dead reference, read the cited line. |\n| 4 | EVALUATE | Decide: does the suggestion hold for **this** codebase in **this** state? Consider compatibility, deliberate prior decisions, YAGNI, platform constraints. |\n| 5 | RESPOND | Acknowledge with a fix sentence, or push back with technical reasoning. Forbidden: \"You're absolutely right!\", \"Great point!\", \"Thanks!\" |\n| 6 | IMPLEMENT | One item at a time, test each, surface the verification block per `ywc-verify-done`. |\n\n## Forbidden Acknowledgments\n\nThe following phrases are **never** acceptable in response to review feedback. They commit you to an implementation before verification (Step 3) and they teach the reviewer that your agreements are noise.\n\n| Forbidden | Replace with |\n|---|---|\n| \"You're absolutely right!\" | State the fix: \"Fixed — `\u003Cfile:line>` now \u003Cbehavior>.\" |\n| \"Great point!\" | State the fix or the question: \"Will fix; verifying \u003CX> first.\" |\n| \"Excellent feedback!\" | Drop entirely. State the action. |\n| \"Thanks for catching that!\" | Drop entirely. The fix is the thanks. |\n| \"Thanks for the review!\" (preamble) | Drop entirely. Get to the technical content. |\n| \"Let me implement that right now\" (before Step 3) | \"Verifying before implementing: \u003Ccheck>.\" |\n| \"Good catch!\" | Drop entirely. State the action. |\n| Any unsolicited gratitude expression | Drop entirely. Actions speak. |\n\nA complete list of forbidden phrases (including paraphrases and tells) is in [`references\u002Fforbidden-acknowledgments.md`](references\u002Fforbidden-acknowledgments.md).\n\n**If you catch yourself about to write \"Thanks\":** delete it. State the fix or the question instead.\n\n## When to Push Back\n\nPush back, with technical reasoning, when the suggestion meets any of these:\n\n| Condition | Example |\n|---|---|\n| Breaks existing functionality | \"Removing the legacy branch breaks pre-10.15 clients — verified in `userAgent.test.ts:24`. Drop pre-10.15 support, or keep the branch?\" |\n| Reviewer lacks full context | \"The `console.log` is gated behind `DEBUG=auth`; removing it disables a documented debugging surface. Wrap in `if (process.env.DEBUG === 'auth')` removal, or keep?\" |\n| YAGNI violation | \"Grepped the codebase — `metricsEndpoint` is not called. Remove rather than 'implement properly'?\" |\n| Technically incorrect for this stack | \"Suggested API is Node 20+; project targets Node 18. Use the polyfill or upgrade target?\" |\n| Conflicts with prior decision | \"ADR-0007 chose Pattern X over the suggested Pattern Y on 2026-03-12 because \u003Creason>. Revisit ADR, or implement another way?\" |\n\nHow to push back well:\n\n- **Technical reasoning first.** Cite the file, line, test, or commit.\n- **End with a question, not an assertion.** Lets the reviewer accept your verification or correct it.\n- **No defensiveness.** \"I disagree\" alone is not pushback — it is friction. \"I disagree because \u003CX>; what is the path you want?\" is pushback.\n\n## Handling Unclear Feedback\n\nIf any item is unclear, **stop**. Do not implement the clear items first.\n\n```text\nIF any item is unclear:\n  STOP — do not implement anything yet\n  ASK for clarification on the unclear items, naming them by number \u002F quote\nWHY: Items are often related. Partial implementation of item 3 because items\n     4 and 5 are unclear produces work that has to be re-done once items 4\n     and 5 land.\n```\n\nExample:\n\n> Reviewer: \"Fix items 1-6\"\n> You understand 1, 2, 3, 6. Unclear on 4, 5.\n>\n> ❌ Wrong: implement 1, 2, 3, 6 now; ask about 4 and 5 later.\n> ✅ Right: \"I understand items 1, 2, 3, 6. Need clarification on 4 and 5 before implementing — specifically, what behavior do you want for \u003CX> in item 4, and is item 5 asking for \u003CY> or \u003CZ>?\"\n\n## Source-Specific Handling\n\nThe level of skepticism scales with the source.\n\n### From the user (human partner)\n\n- **Trusted by default.** Implement after understanding (Step 2) and verification (Step 3).\n- **Still ask** if scope is unclear.\n- **Still push back** when the user is technically wrong — courteously, with reasoning.\n- **No performative agreement.** Skip to the action or the technical acknowledgment.\n\n### From an external human reviewer\n\n- **Skeptical, with care.** External reviewers often see the diff without the surrounding context.\n- Before implementing, run the verification checklist:\n\n  1. Technically correct for **this** codebase?\n  2. Does it break any existing tests?\n  3. Is there a documented reason for the current implementation?\n  4. Does it work on all supported platforms \u002F versions?\n  5. Does the reviewer have the full context, or is there context they lack?\n\n- If you cannot easily verify a claim, say so: \"I cannot verify \u003CX> without \u003CY>. Should I (a) investigate, (b) ask \u003Cperson>, or (c) proceed assuming the claim?\"\n\n### From a bot reviewer (CodeRabbit, Codex Review, Claude Review)\n\n- **Skeptical, more so.** Bots lack project-specific context — the `as any` is deliberate, the `eslint-disable-next-line` is documented, the dead branch is a feature flag.\n- Apply the YAGNI check: does the suggested \"professional implementation\" cover something that is actually used?\n- If the bot suggests >5 items, batch by category (lint \u002F type \u002F behavior \u002F docs) and address the categories — not the individual items — to avoid acknowledgment-thrash.\n\n### Conflicts with prior architectural decisions\n\nWhen a suggestion contradicts a documented ADR, prior PR, or the user's stated direction: **stop**. Surface the conflict to the user before implementing or pushing back. The reviewer may not have seen the prior decision; the user is the one who decides whether to revisit it.\n\n## Acknowledging Correct Feedback\n\nWhen feedback **is** correct and you have verified it, acknowledge by stating the fix. No gratitude.\n\n| Good | Bad |\n|---|---|\n| \"Fixed. `auth.ts:42` now rejects expired tokens with 401.\" | \"You're absolutely right! Let me fix that!\" |\n| \"Fixed. `pagination.ts:18` had the off-by-one.\" | \"Thanks for catching that, fixing now.\" |\n| (Just commit the fix and reply with the commit hash) | \"Great point! Implementing now.\" |\n\nWhen acknowledging via the GitHub thread (per `ywc-handle-pr-reviews`), reply in the comment thread (`gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{pr}\u002Fcomments\u002F{id}\u002Freplies`), not as a top-level PR comment.\n\n## Gracefully Correcting Your Pushback\n\nIf you pushed back and were wrong:\n\n| Good | Bad |\n|---|---|\n| \"You were right — verified \u003CX>, the suggestion does hold because \u003CY>. Implementing now.\" | Long apology + defense of why you pushed back |\n| \"Verified, my initial read missed \u003CZ>. Fixing.\" | Over-explanation, undermining future pushbacks |\n\nState the correction factually and move on. The codebase records the fix, not the apology.\n\n## Implementation Order\n\nAfter all items are clarified and verified, implement in this order:\n\n```text\n1. Blocking issues (security, data loss, broken builds)\n2. Simple fixes (typos, imports, lint)\n3. Complex fixes (refactoring, logic, architecture)\n```\n\nTest each fix individually. Verify each via `ywc-verify-done` before claiming \"fix applied\".\n\n## Output Format\n\n```text\nStatus: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT\nItems handled: \u003Cn>\nImplemented fixes: \u003Cfile:line + verification command>\nPushbacks\u002Fquestions: \u003Ctechnical reason + question>\nRemaining blockers: \u003Cnone or explicit blocker>\n```\n\n## Integration\n\n- **Upstream callers**: user invocation; `ywc-handle-pr-reviews` (per inline-comment iteration — this skill is its attitude layer); `ywc-finish-branch` (post-CI bot reviews surfaced by `scripts\u002Fpoll-pr-reviews.sh`).\n- **Downstream**: `ywc-verify-done` (per-fix verification block); `ywc-debug-rootcause` (when a \"fix\" attempt fails ≥ 2 times on the same comment — escalate); `ywc-impl-review` (when the reviewer's suggestion turns out to expose a class of defects beyond the current PR — open a finding for follow-up).\n- **Pairs with**: `ywc-handle-pr-reviews` (automation of inline-comment fetching \u002F threading \u002F replying — this skill governs the **what to say** and **what to do**, the other governs the **how to send**).\n\n## Validation Checklist\n\nBefore submitting any reply to review feedback, verify:\n\n- [ ] Every reviewer item was READ in full (no skim)\n- [ ] Every item is UNDERSTOOD or has been explicitly asked about\n- [ ] Every claim was VERIFIED against the current codebase (file read, test run, grep)\n- [ ] Every fix has a one-sentence rationale tied to the verification, not to the reviewer's authority\n- [ ] No forbidden vocabulary appears in the reply (\"You're absolutely right!\", \"Thanks!\", \"Great point!\")\n- [ ] Pushbacks include a technical reason + a question\n- [ ] Acknowledgments name the fix or commit hash, not gratitude\n- [ ] Unclear items are asked about, not partially implemented around\n- [ ] Multi-item replies follow the order: blockers → simple → complex\n- [ ] If reviewer's suggestion conflicts with a prior decision (ADR \u002F PR \u002F user direction), the conflict was surfaced before implementing\n\n## Common Mistakes\n\n(Procedural failure modes specific to this skill. Behavioral rationalizations are in the table above — do not duplicate here.)\n\n- **Replying to the easy comments first to show progress, leaving the hard ones for later.** The hard ones often constrain the easy ones; the easy fixes become rework when the hard answers arrive.\n- **Replying in bulk with a single \"Will address\" comment.** Each reviewer item deserves its own response thread on the PR (`ywc-handle-pr-reviews` handles the threading mechanics). Bulk replies hide the per-item verification and make the reviewer re-read everything.\n- **Pushing back without a question.** \"I disagree\" is friction; \"I disagree because \u003CX>, want me to do \u003CY> instead?\" is pushback. Always end with a path forward.\n- **Acknowledging correct feedback with \"Thanks!\" anyway, because it feels rude not to.** The codebase does not record politeness. State the fix; the speed and accuracy of the fix are the courtesy.\n- **Carrying a wrong pushback forward with a long apology after the reviewer corrects you.** Apologies undermine future pushbacks (the reviewer learns \"they cave under pressure\"). State the correction in one sentence and move on.\n\n## References\n\n| Reference | Use when |\n|---|---|\n| [references\u002Fforbidden-acknowledgments.md](references\u002Fforbidden-acknowledgments.md) | Auditing a draft reply for performative-agreement language; full vocabulary list with replacements |\n| [references\u002Fpushback-templates.md](references\u002Fpushback-templates.md) | Composing technical pushback for the five common conditions (broken functionality, missing context, YAGNI, stack incompatibility, prior decision) |\n| `ywc-handle-pr-reviews` | Automation for fetching unresolved comments, threading replies, and managing the PR-review loop — this skill governs the response *content*, that skill governs the response *plumbing* |\n| `ywc-verify-done` | Per-fix verification block (command + exit code + claim) attached to every \"fixed\" acknowledgment |\n","# ywc-receive-review\n\n**Announce at start:** \"I'm using the ywc-receive-review skill to verify review feedback before responding — no performative agreement, no blind implementation.\"\n\nThis skill is the attitude layer for receiving code-review feedback. It exists because the default LLM behavior — agreeing eagerly to whatever the reviewer says and starting to implement — produces three failure modes the ywc workflow must avoid: (1) implementing a \"fix\" that breaks a deliberately-shaped behavior the reviewer did not know about; (2) blindly removing code the reviewer thought was unused but is actually called from a path they did not see; (3) burning trust by saying \"You're absolutely right!\" to a wrong suggestion and then quietly reverting. Adapted from `superpowers:receiving-code-review`, tightened to integrate as the attitude layer of `ywc-handle-pr-reviews` (which owns the *automation*; this skill owns the *judgment*).\n\n## The Iron Law\n\n```text\nVERIFY BEFORE IMPLEMENTING. NO PERFORMATIVE AGREEMENT, EVER.\n```\n\nReceiving review feedback is **technical evaluation**, not emotional performance. Every item is a *suggestion to evaluate*, not an order to follow. The act of agreeing must be backed by a technical check; the act of disagreeing must be backed by technical reasoning.\n\n## Rationalization Defense\n\nWhen tempted to skip verification or to soften the response, check this table first:\n\n| Excuse | Reality |\n|---|---|\n| \"Saying 'You're right!' is polite — it doesn't change the technical outcome\" | It changes two things: (1) it commits you to an implementation before you have verified the suggestion holds, which makes the post-verification correction expensive; (2) it teaches the reviewer (and any teammate reading the thread) that your agreements are not load-bearing. State the fix instead of the gratitude — actions speak. |\n| \"The reviewer is more senior, I should defer\" | Authority is not a check against a codebase. A senior reviewer who has not opened the file in 6 months may suggest a change that broke something last week. Verify against current code; then defer with evidence, or push back with evidence. |\n| \"Pushing back feels confrontational — implementing is friendlier\" | Friendlier today, hostile tomorrow when the implementation breaks production and someone has to figure out why a clearly-wrong suggestion was accepted without comment. Technical pushback **is** the courteous response — it preserves the reviewer's intent, your trust, and the codebase. |\n| \"I'll batch-acknowledge all 12 items and then implement them\" | Items are often related. Partial understanding of one becomes partial implementation of another. Read all items, clarify unclear ones, **then** implement. Acknowledging without understanding is a worse failure than asking. |\n| \"The bot review is automated, no harm in agreeing reflexively\" | The bot has no context for `\u002F\u002F eslint-disable-next-line` next to a known-safe pattern, for the `as any` that documents a deliberate type erasure, for the `console.log` that was the user's manual debug tool. Bot suggestions need the same verification a human's would. |\n| \"If I push back and I'm wrong, I look incompetent\" | If you defer and you are wrong, the codebase has a documented bug *and* the reviewer trusts that subsequent acceptances mean you checked. Both costs compound. Push back with technical reasoning; if you are wrong, the correction is one sentence: \"Verified, you are right because \u003CX>. Implementing.\" |\n| \"Saying 'Thanks for catching that!' shows I'm a team player\" | The codebase does not record team-player points. It records the fix. Surface the fix; the team-player signal is implicit in the speed and accuracy of the action. |\n| \"The user is my human partner — I should not push back on them\" | The human partner asks for pushback when the partner is wrong. Implementing a wrong instruction without surfacing the concern is the failure mode. Use technical reasoning, not defiance: \"Before implementing, I want to flag that \u003CX> appears to conflict with \u003CY>. Should I proceed, or revise?\" |\n| \"Multiple reviewers gave contradicting suggestions — I'll pick whichever feels right\" | Surface the contradiction and ask the human partner. Reviewers who disagree have not seen each other's comments; you have. The job is to surface, not to arbitrate. |\n| \"Asking for clarification slows the review down\" | Implementing the wrong interpretation and then re-implementing it correctly is slower than asking once. Estimate: 1 question (~1 minute round-trip) beats a misimplementation (~30 minutes plus second review). |\n\n**Violating the letter of this discipline is violating the spirit.** The codebase records what was implemented, not what was said. Every \"You're absolutely right!\" without a corresponding verified fix is a small lie that compounds.\n\n## The Response Pattern\n\nFor every reviewer comment, execute these six steps in order. Skipping any step is the failure mode.\n\n```text\nREAD → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT\n```\n\n| # | Step | What it produces |\n|---|---|---|\n| 1 | READ | The full feedback, read without reacting. No agreement, no disagreement, no implementation tool calls yet. |\n| 2 | UNDERSTAND | Restate the technical requirement in your own words, or — if any part is unclear — ask before advancing. |\n| 3 | VERIFY | Check the claim against the current codebase: open the file, run the failing test, grep for the alleged dead reference, read the cited line. |\n| 4 | EVALUATE | Decide: does the suggestion hold for **this** codebase in **this** state? Consider compatibility, deliberate prior decisions, YAGNI, platform constraints. |\n| 5 | RESPOND | Acknowledge with a fix sentence, or push back with technical reasoning. Forbidden: \"You're absolutely right!\", \"Great point!\", \"Thanks!\" |\n| 6 | IMPLEMENT | One item at a time, test each, surface the verification block per `ywc-verify-done`. |\n\n## Forbidden Acknowledgments\n\nThe following phrases are **never** acceptable in response to review feedback. They commit you to an implementation before verification (Step 3) and they teach the reviewer that your agreements are noise.\n\n| Forbidden | Replace with |\n|---|---|\n| \"You're absolutely right!\" | State the fix: \"Fixed — `\u003Cfile:line>` now \u003Cbehavior>.\" |\n| \"Great point!\" | State the fix or the question: \"Will fix; verifying \u003CX> first.\" |\n| \"Excellent feedback!\" | Drop entirely. State the action. |\n| \"Thanks for catching that!\" | Drop entirely. The fix is the thanks. |\n| \"Thanks for the review!\" (preamble) | Drop entirely. Get to the technical content. |\n| \"Let me implement that right now\" (before Step 3) | \"Verifying before implementing: \u003Ccheck>.\" |\n| \"Good catch!\" | Drop entirely. State the action. |\n| Any unsolicited gratitude expression | Drop entirely. Actions speak. |\n\nA complete list of forbidden phrases (including paraphrases and tells) is in [`references\u002Fforbidden-acknowledgments.md`](references\u002Fforbidden-acknowledgments.md).\n\n**If you catch yourself about to write \"Thanks\":** delete it. State the fix or the question instead.\n\n## When to Push Back\n\nPush back, with technical reasoning, when the suggestion meets any of these:\n\n| Condition | Example |\n|---|---|\n| Breaks existing functionality | \"Removing the legacy branch breaks pre-10.15 clients — verified in `userAgent.test.ts:24`. Drop pre-10.15 support, or keep the branch?\" |\n| Reviewer lacks full context | \"The `console.log` is gated behind `DEBUG=auth`; removing it disables a documented debugging surface. Wrap in `if (process.env.DEBUG === 'auth')` removal, or keep?\" |\n| YAGNI violation | \"Grepped the codebase — `metricsEndpoint` is not called. Remove rather than 'implement properly'?\" |\n| Technically incorrect for this stack | \"Suggested API is Node 20+; project targets Node 18. Use the polyfill or upgrade target?\" |\n| Conflicts with prior decision | \"ADR-0007 chose Pattern X over the suggested Pattern Y on 2026-03-12 because \u003Creason>. Revisit ADR, or implement another way?\" |\n\nHow to push back well:\n\n- **Technical reasoning first.** Cite the file, line, test, or commit.\n- **End with a question, not an assertion.** Lets the reviewer accept your verification or correct it.\n- **No defensiveness.** \"I disagree\" alone is not pushback — it is friction. \"I disagree because \u003CX>; what is the path you want?\" is pushback.\n\n## Handling Unclear Feedback\n\nIf any item is unclear, **stop**. Do not implement the clear items first.\n\n```text\nIF any item is unclear:\n  STOP — do not implement anything yet\n  ASK for clarification on the unclear items, naming them by number \u002F quote\nWHY: Items are often related. Partial implementation of item 3 because items\n     4 and 5 are unclear produces work that has to be re-done once items 4\n     and 5 land.\n```\n\nExample:\n\n> Reviewer: \"Fix items 1-6\"\n> You understand 1, 2, 3, 6. Unclear on 4, 5.\n>\n> ❌ Wrong: implement 1, 2, 3, 6 now; ask about 4 and 5 later.\n> ✅ Right: \"I understand items 1, 2, 3, 6. Need clarification on 4 and 5 before implementing — specifically, what behavior do you want for \u003CX> in item 4, and is item 5 asking for \u003CY> or \u003CZ>?\"\n\n## Source-Specific Handling\n\nThe level of skepticism scales with the source.\n\n### From the user (human partner)\n\n- **Trusted by default.** Implement after understanding (Step 2) and verification (Step 3).\n- **Still ask** if scope is unclear.\n- **Still push back** when the user is technically wrong — courteously, with reasoning.\n- **No performative agreement.** Skip to the action or the technical acknowledgment.\n\n### From an external human reviewer\n\n- **Skeptical, with care.** External reviewers often see the diff without the surrounding context.\n- Before implementing, run the verification checklist:\n\n  1. Technically correct for **this** codebase?\n  2. Does it break any existing tests?\n  3. Is there a documented reason for the current implementation?\n  4. Does it work on all supported platforms \u002F versions?\n  5. Does the reviewer have the full context, or is there context they lack?\n\n- If you cannot easily verify a claim, say so: \"I cannot verify \u003CX> without \u003CY>. Should I (a) investigate, (b) ask \u003Cperson>, or (c) proceed assuming the claim?\"\n\n### From a bot reviewer (CodeRabbit, Codex Review, Claude Review)\n\n- **Skeptical, more so.** Bots lack project-specific context — the `as any` is deliberate, the `eslint-disable-next-line` is documented, the dead branch is a feature flag.\n- Apply the YAGNI check: does the suggested \"professional implementation\" cover something that is actually used?\n- If the bot suggests >5 items, batch by category (lint \u002F type \u002F behavior \u002F docs) and address the categories — not the individual items — to avoid acknowledgment-thrash.\n\n### Conflicts with prior architectural decisions\n\nWhen a suggestion contradicts a documented ADR, prior PR, or the user's stated direction: **stop**. Surface the conflict to the user before implementing or pushing back. The reviewer may not have seen the prior decision; the user is the one who decides whether to revisit it.\n\n## Acknowledging Correct Feedback\n\nWhen feedback **is** correct and you have verified it, acknowledge by stating the fix. No gratitude.\n\n| Good | Bad |\n|---|---|\n| \"Fixed. `auth.ts:42` now rejects expired tokens with 401.\" | \"You're absolutely right! Let me fix that!\" |\n| \"Fixed. `pagination.ts:18` had the off-by-one.\" | \"Thanks for catching that, fixing now.\" |\n| (Just commit the fix and reply with the commit hash) | \"Great point! Implementing now.\" |\n\nWhen acknowledging via the GitHub thread (per `ywc-handle-pr-reviews`), reply in the comment thread (`gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{pr}\u002Fcomments\u002F{id}\u002Freplies`), not as a top-level PR comment.\n\n## Gracefully Correcting Your Pushback\n\nIf you pushed back and were wrong:\n\n| Good | Bad |\n|---|---|\n| \"You were right — verified \u003CX>, the suggestion does hold because \u003CY>. Implementing now.\" | Long apology + defense of why you pushed back |\n| \"Verified, my initial read missed \u003CZ>. Fixing.\" | Over-explanation, undermining future pushbacks |\n\nState the correction factually and move on. The codebase records the fix, not the apology.\n\n## Implementation Order\n\nAfter all items are clarified and verified, implement in this order:\n\n```text\n1. Blocking issues (security, data loss, broken builds)\n2. Simple fixes (typos, imports, lint)\n3. Complex fixes (refactoring, logic, architecture)\n```\n\nTest each fix individually. Verify each via `ywc-verify-done` before claiming \"fix applied\".\n\n## Output Format\n\n```text\nStatus: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT\nItems handled: \u003Cn>\nImplemented fixes: \u003Cfile:line + verification command>\nPushbacks\u002Fquestions: \u003Ctechnical reason + question>\nRemaining blockers: \u003Cnone or explicit blocker>\n```\n\n## Integration\n\n- **Upstream callers**: user invocation; `ywc-handle-pr-reviews` (per inline-comment iteration — this skill is its attitude layer); `ywc-finish-branch` (post-CI bot reviews surfaced by `scripts\u002Fpoll-pr-reviews.sh`).\n- **Downstream**: `ywc-verify-done` (per-fix verification block); `ywc-debug-rootcause` (when a \"fix\" attempt fails ≥ 2 times on the same comment — escalate); `ywc-impl-review` (when the reviewer's suggestion turns out to expose a class of defects beyond the current PR — open a finding for follow-up).\n- **Pairs with**: `ywc-handle-pr-reviews` (automation of inline-comment fetching \u002F threading \u002F replying — this skill governs the **what to say** and **what to do**, the other governs the **how to send**).\n\n## Validation Checklist\n\nBefore submitting any reply to review feedback, verify:\n\n- [ ] Every reviewer item was READ in full (no skim)\n- [ ] Every item is UNDERSTOOD or has been explicitly asked about\n- [ ] Every claim was VERIFIED against the current codebase (file read, test run, grep)\n- [ ] Every fix has a one-sentence rationale tied to the verification, not to the reviewer's authority\n- [ ] No forbidden vocabulary appears in the reply (\"You're absolutely right!\", \"Thanks!\", \"Great point!\")\n- [ ] Pushbacks include a technical reason + a question\n- [ ] Acknowledgments name the fix or commit hash, not gratitude\n- [ ] Unclear items are asked about, not partially implemented around\n- [ ] Multi-item replies follow the order: blockers → simple → complex\n- [ ] If reviewer's suggestion conflicts with a prior decision (ADR \u002F PR \u002F user direction), the conflict was surfaced before implementing\n\n## Common Mistakes\n\n(Procedural failure modes specific to this skill. Behavioral rationalizations are in the table above — do not duplicate here.)\n\n- **Replying to the easy comments first to show progress, leaving the hard ones for later.** The hard ones often constrain the easy ones; the easy fixes become rework when the hard answers arrive.\n- **Replying in bulk with a single \"Will address\" comment.** Each reviewer item deserves its own response thread on the PR (`ywc-handle-pr-reviews` handles the threading mechanics). Bulk replies hide the per-item verification and make the reviewer re-read everything.\n- **Pushing back without a question.** \"I disagree\" is friction; \"I disagree because \u003CX>, want me to do \u003CY> instead?\" is pushback. Always end with a path forward.\n- **Acknowledging correct feedback with \"Thanks!\" anyway, because it feels rude not to.** The codebase does not record politeness. State the fix; the speed and accuracy of the fix are the courtesy.\n- **Carrying a wrong pushback forward with a long apology after the reviewer corrects you.** Apologies undermine future pushbacks (the reviewer learns \"they cave under pressure\"). State the correction in one sentence and move on.\n\n## References\n\n| Reference | Use when |\n|---|---|\n| [references\u002Fforbidden-acknowledgments.md](references\u002Fforbidden-acknowledgments.md) | Auditing a draft reply for performative-agreement language; full vocabulary list with replacements |\n| [references\u002Fpushback-templates.md](references\u002Fpushback-templates.md) | Composing technical pushback for the five common conditions (broken functionality, missing context, YAGNI, stack incompatibility, prior decision) |\n| `ywc-handle-pr-reviews` | Automation for fetching unresolved comments, threading replies, and managing the PR-review loop — this skill governs the response *content*, that skill governs the response *plumbing* |\n| `ywc-verify-done` | Per-fix verification block (command + exit code + claim) attached to every \"fixed\" acknowledgment |\n",{"name":5,"description":7},"main","7e8ac872e53df8c89d75663e031626281a2a2f5c","plugins\u002Fywc-agent-toolkit\u002Fskills\u002Fywc-receive-review",1,"https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit","https:\u002F\u002Fgithub.com\u002Fyongwoon","https:\u002F\u002Fwww.webhani.com","2026-11-08 17:14:59",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add yongwoon\u002Fywc-agent-toolkit --skill ywc-receive-review",{"tool":37,"command":38},"bunx","bunx skills add yongwoon\u002Fywc-agent-toolkit --skill ywc-receive-review",{"tool":40,"command":41},"pnpm","pnpm dlx skills add yongwoon\u002Fywc-agent-toolkit --skill ywc-receive-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fywc-agent-toolkit\u002Fskills\u002Fywc-receive-review\u002FSKILL.md",true,[45,51,55,59,63,67,71,75,79,83],{"path":46,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":49,"sourceHtmlUrl":50},"agents\u002Fopenai.yaml","REFERENCE","参考文档",341,"https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fywc-agent-toolkit\u002Fskills\u002Fywc-receive-review\u002Fagents\u002Fopenai.yaml",{"path":52,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":53,"sourceHtmlUrl":54},"evals\u002Fevals.json",716,"https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fywc-agent-toolkit\u002Fskills\u002Fywc-receive-review\u002Fevals\u002Fevals.json",{"path":56,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":57,"sourceHtmlUrl":58},"README.en.md",2677,"https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fywc-agent-toolkit\u002Fskills\u002Fywc-receive-review\u002FREADME.en.md",{"path":60,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":61,"sourceHtmlUrl":62},"README.es.md",204,"https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fywc-agent-toolkit\u002Fskills\u002Fywc-receive-review\u002FREADME.es.md",{"path":64,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":65,"sourceHtmlUrl":66},"README.ja.md",2817,"https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fywc-agent-toolkit\u002Fskills\u002Fywc-receive-review\u002FREADME.ja.md",{"path":68,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":69,"sourceHtmlUrl":70},"README.ko.md",2859,"https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fywc-agent-toolkit\u002Fskills\u002Fywc-receive-review\u002FREADME.ko.md",{"path":72,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":73,"sourceHtmlUrl":74},"README.md",2852,"https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fywc-agent-toolkit\u002Fskills\u002Fywc-receive-review\u002FREADME.md",{"path":76,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":77,"sourceHtmlUrl":78},"README.zh.md",211,"https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fywc-agent-toolkit\u002Fskills\u002Fywc-receive-review\u002FREADME.zh.md",{"path":80,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fforbidden-acknowledgments.md",5993,"https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fywc-agent-toolkit\u002Fskills\u002Fywc-receive-review\u002Freferences\u002Fforbidden-acknowledgments.md",{"path":84,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Fpushback-templates.md",6686,"https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fywc-agent-toolkit\u002Fskills\u002Fywc-receive-review\u002Freferences\u002Fpushback-templates.md",[88,94,100,107,114,121],{"skillNo":89,"name":90,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":18},"01M72TQ84GTCPCV2VJ778V17TW","missing-frontmatter","https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fscripts\u002Ffixtures\u002Fcodex-description-limit\u002Fmissing-frontmatter\u002FSKILL.md",[],[],{"skillNo":95,"name":96,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":18},"01M72TQ6M4BFWE7P9EPW0GZDCM","malformed-frontmatter","https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fscripts\u002Ffixtures\u002Fcodex-description-limit\u002Fmalformed-frontmatter\u002FSKILL.md",[],[],{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":18},"01M72TQ3ESGKXZ4QRWGTX92BKJ","fixture-501-fail","(ywc) Use when aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Do not use for x.","https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fscripts\u002Ffixtures\u002Fcodex-description-limit\u002F501-fail\u002FSKILL.md",[],[],{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":18},"01M72TQ0HJ8H3R37J9WPWGKJZR","fixture-500-pass","(ywc) Use when aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Do not use for x.","https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fscripts\u002Ffixtures\u002Fcodex-description-limit\u002F500-pass\u002FSKILL.md",[],[],{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":18},"01M72TPWNCC7NEYD0D9N12KSQS","ywc-worktrees","(ywc) Use when creating, auditing, pruning, or resolving git worktrees for isolated task workspaces, whether delegated from an executor or used standalone. Triggers: \"worktree 생성\", \"worktree audit\", \"worktree 정리\", \"worktree prune\", \"ywc-worktrees\", \"create worktree\". Do not use for branch creation\u002Fdeletion alone, PR creation (use ywc-create-pr), CI or merge delivery (use ywc-finish-branch), task orchestration (use ywc-sequential-executor or ywc-parallel-executor), or non-git isolation.","https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fywc-agent-toolkit\u002Fskills\u002Fywc-worktrees\u002FSKILL.md",[],[],{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":18},"01M72TPRNR3E6QWB91GM98ABBV","ywc-wayfinder","(ywc) Use when a large or uncertain change needs multi-session discovery with a deterministic local map and exactly one active ticket before planning or implementation. Triggers: \"wayfinder\", \"길찾기\", \"discovery map\", \"multi-session discovery\", \"탐색 ticket\", \"経路整理\", \"探索マップ\", \"ywc-wayfinder\". Do not use for ordinary planning (use ywc-plan), idea clarification (use ywc-brainstorm), direct implementation, or tracker\u002Fdatabase writes outside the local Markdown map.","https:\u002F\u002Fgithub.com\u002Fyongwoon\u002Fywc-agent-toolkit\u002Fblob\u002Fmain\u002Fplugins\u002Fywc-agent-toolkit\u002Fskills\u002Fywc-wayfinder\u002FSKILL.md",[],[]]