メニュー
Process code review feedback with technical rigor — verify before implementing, push back when wrong. USE WHEN receiving code review feedback, before implementing review suggestions.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Pick brandable available domains via RDAP, detect broker listings, plan brand families, and choose registrars without overpaying premium tiers. USE WHEN picking a domain, naming a project, checking domain availability, registering a domain, brand research, TLD hack, ccTLD pricing.
Drive cmux from its Unix-socket CLI: open a new split, pane, or tab and run a command in it by sending text and keys, build declarative layouts, render a diff in the native viewer, and resolve window / workspace / pane / surface handles. USE WHEN opening tuicr or any command in a new cmux pane, splitting the current pane from the CLI, sending commands or keys to another surface, watching logs in a side pane, showing a diff in cmux, or scripting cmux layouts. For app config, persistence, and hooks see the cmux tldr.
Jujutsu (jj) as a colocated VCS front-end over git for AI-agent work: colocate strategy, git-hook-tool coexistence (Entire, gitleaks, safety-net), parallel agents via jj workspaces, op-log recovery, provisioning. USE WHEN colocating a repo with jj git init --colocate, deciding whether jj coexists with Entire / gitleaks / safety-net or other git-hook tooling, isolating parallel agents with jj workspace, recovering jj state with jj undo or op restore, or debugging jj-and-git interaction. For commit and push discipline see VersionControl's Jujutsu companion; for commands see the jj tldr.
Manage the pull request lifecycle: author the body to the house standard, create via gh or glab, retrieve and address feedback, retarget stacked PRs, merge and clean up. USE WHEN create a PR, open a pull request, draft a PR, write a PR body, PR description, address PR feedback, PR comments, retarget a stacked PR, PR merged but changes missing from main, merge a PR. For the merge-vs-PR-vs-discard decision use FinishBranch; for processing review feedback rigor use ReceiveReview; for authoring the review-request message use RequestReview.
Author a clear scoped request when asking for a code review. USE WHEN ready for review, finishing a task, or requesting review feedback on a piece of code. For creating the pull request itself use PullRequest.
Server-rendered web dashboards and apps in Rust using axum + htmx + Askama + rust-embed. USE WHEN building a web dashboard, adding a web UI to a CLI tool, server-rendered HTML, htmx partials, Askama templates, axum routes, embedded static assets, localhost webserver.
| name | ReceiveReview |
| version | 0.1.0 |
| description | Process code review feedback with technical rigor — verify before implementing, push back when wrong. USE WHEN receiving code review feedback, before implementing review suggestions. |
Process code review feedback critically. Verify suggestions are correct before implementing. Push back when they're wrong. Never performatively agree.
Forbidden responses: "You're absolutely right!", "Great point!", "Thanks for catching that!" — these are performative, not technical. Respond with what you did and why.
When pushing back, provide technical reasoning:
When the reviewer is right, just fix it. No performance needed.
| Thought | Reality |
|---|---|
| "They're probably right, I'll just do it" | Verify first. Reviewers have limited context. |
| "I don't agree but I'll do it anyway" | Push back with evidence. Silent compliance ships bad code. |
| "Let me add this feature they suggested" | YAGNI check. Is it in the spec? Is it needed? |
| "I'll implement all suggestions at once" | One at a time, in priority order. Batching hides interactions. |
| "Great point!" (about to implement blindly) | Read the code. Is it actually a great point? |
| "This feedback is wrong, I'll ignore it" | Respond with reasoning. Ignoring erodes trust. |
@ReceivingCodeReview.md
