# Arc Receiving Review

> Use when receiving code review feedback, requires technical rigor not performative agreement

- Skill: `tomevault-io/arc-receiving-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/arc-receiving-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/arc-receiving-review/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/arc-receiving-review

---


# arc-receiving-review

## Core Principle

Verify before implementing. Ask before assuming. Technical correctness over social comfort.

## The Response Pattern

1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY: Check against codebase reality
4. EVALUATE: Technically sound for THIS codebase?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. IMPLEMENT: One item at a time, test each

## Forbidden Responses

- ❌ "You're absolutely right!"
- ❌ "Great point!" / "Excellent feedback!"
- ❌ "Let me implement that now" (before verification)
- ❌ ANY gratitude expression ("Thanks for...")

## Handling Unclear Feedback

IF any item is unclear:
  STOP - do not implement anything yet
  ASK for clarification on ALL unclear items

WHY: Partial understanding = wrong implementation

## Source-Specific Handling

**From your human partner:**
- Trusted input, implement after understanding
- Still ask if scope is unclear
- No performative agreement

**If external feedback conflicts with human partner:**
- Stop and discuss with your human partner before implementing

## When To Push Back

- Suggestion breaks existing functionality
- Reviewer lacks full context
- Violates YAGNI (unused feature)
- Technically incorrect for this stack

**Pushback examples:**

```
"I checked the current usage and this endpoint isn't called. Do we want to remove it (YAGNI) or keep it for future use?"
```

```
"This change would drop support for <legacy target>. If we still need that target, I can fix the issue without removing support."
```

## YAGNI Check

IF reviewer suggests "implementing properly":
  grep codebase for actual usage
  IF unused: "This isn't called. Remove it (YAGNI)?"

## After This Skill

When all feedback items are implemented and tested:

**Autonomous mode (agent-driven / looping):**
1. Request re-review via `arc-requesting-review` — loop until reviewer approves
2. Once approved → run `arc-verifying` to confirm all requirements and tests pass
3. Then use `arc-finishing` (regular branch) or `arc-finishing-epic` (worktree with `.arcforge-epic`)

**Manual mode (human-in-loop):**
- Signal completion to user — they decide whether to re-review, verify, or finish

## Integration

- **Called by:** arc-agent-driven, arc-requesting-review
- **Related:** arc-verifying (verification mindset)

---
> Converted and distributed by [TomeVault](https://tomevault.io/claim/gregoryho) — claim your Tome and manage your conversions.
<!-- tomevault:4.0:skill_md:2026-04-14 -->