メニュー
Use when review feedback lands on a Maycrest deliverable — before implementing any suggestion, especially an unclear or questionable one — demanding verification over performative agreement.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | sloth-receive-review |
| description | Use when review feedback lands on a Maycrest deliverable — before implementing any suggestion, especially an unclear or questionable one — demanding verification over performative agreement. |
Review feedback is a set of claims to evaluate, not orders to obey. At Maycrest the work ships to clients who trust the verdict — so a suggestion gets verified against the codebase before it changes a line.
Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.
WHEN feedback arrives on a deliverable:
1. READ — full feedback, no reaction
2. UNDERSTAND — restate each item in your own words (or ask)
3. VERIFY — check it against codebase reality
4. EVALUATE — sound for THIS stack / THIS client?
5. RESPOND — technical acknowledgment or reasoned pushback
6. IMPLEMENT — one item at a time, test each
NEVER:
INSTEAD: restate the requirement, ask a clarifying question, push back with technical reasoning if it's wrong, or just start working. Actions speak — the code shows you heard it.
If you catch yourself about to write "Thanks": delete it. State the fix instead.
IF any item is unclear:
STOP — implement nothing yet
ASK for clarification on the unclear items
WHY: items may be related. Partial understanding = wrong implementation.
Corey: "Fix items 1-6." You understand 1,2,3,6 — unclear on 4,5.
From Corey (trusted): implement after understanding. Still ask if scope is unclear. No performative agreement — skip to action or a technical acknowledgment.
From external reviewers (skeptical):
BEFORE implementing, check:
1. Technically correct for THIS codebase?
2. Does it break existing functionality?
3. Is there a reason for the current implementation?
4. Works on all platforms / versions we support?
5. Does the reviewer have full context?
IF it seems wrong: push back with technical reasoning
IF you can't verify: say so — "Can't verify without [X]. Investigate / ask / proceed?"
IF it conflicts with Corey's prior decisions: stop and discuss with Corey first
Corey's rule: external feedback — be skeptical, but check carefully.
IF a reviewer suggests "implementing this properly":
grep the codebase for actual usage
IF unused: "Nothing calls this. Remove it (YAGNI)?"
IF used: implement it properly
Corey's rule: you and the reviewer both report to Maycrest. If the client doesn't need the feature, don't add it.
Push back when the suggestion breaks existing functionality, the reviewer lacks context, it violates YAGNI, it's wrong for this stack, legacy/compatibility reasons exist, or it conflicts with Corey's architectural decisions.
How: technical reasoning, not defensiveness. Ask specific questions. Reference working tests/code. Escalate to Corey if it's architectural.
| Mistake | Fix |
|---|---|
| Performative agreement | State the requirement or just act |
| Blind implementation | Verify against the codebase first |
| Batch without testing | One at a time, test each |
| Assuming the reviewer is right | Check whether it breaks things |
| Avoiding pushback | Technical correctness > comfort |
| Partial implementation | Clarify all items first |
| Can't verify, proceed anyway | State the limit, ask for direction |
Reviewer on the booking PR: "Remove the legacy date-parsing helper — use the native Date API."
timestamptz strings that Safari's Date
parser rejects on iOS. Native parsing breaks booking times on iPhone. Keep it, or drop
iOS Safari support? It has a Vitest case proving the Safari path."When the pushback turns out wrong: "You were right — I checked, the RN runtime handles that format. Implementing now." State it factually and move on. No apology, no over-explaining.
maycrest-ops:reality-checker.When replying to inline GitHub review comments, reply in the comment thread
(gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies), not as a top-level PR comment.
The bottom line: external feedback = suggestions to evaluate, not orders to follow. Verify. Question. Then implement. No performative agreement — technical rigor always.
Adapted from the MIT-licensed obra/superpowers project (© 2025 Jesse Vincent). See NOTICE.
Use when an approved Maycrest spec needs turning into a bite-sized TDD implementation plan a contractor could execute cold — before any code is touched on a client build.
Use when the Maycrest deliver pipeline executes an implementation plan of independent tasks in the current session — one fresh subagent per task, two-stage review each.
Use when a Maycrest build hits any bug, test failure, or unexpected behavior on the Expo/Supabase/Vercel stack — before proposing any fix.
Use when completing a task or major feature on a Maycrest build, or before merging — dispatch an independent reviewer subagent as the internal QA gate before the client sees the work.
Use when a Maycrest engagement branch is complete and tests pass — gating the handoff: verify the suite first, then choose merge, PR, keep, or discard, and produce a short client handoff package.
Use when a Maycrest client request needs scoping before any build starts — turns a fuzzy ask into an approved written spec through collaborative dialogue, before code or scaffolding.