How do I install the Arc Receiving Review skill?

Run npx skillmds@latest add tomevault-io/arc-receiving-review in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Arc Receiving Review safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Arc Receiving Review?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Arc Receiving Review free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Arc Receiving Review?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Arc Receiving Review by tomevault-io

Name: Arc Receiving Review
Author: tomevault-io

File contents

arc-receiving-review

Core Principle

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

The Response Pattern

READ: Complete feedback without reacting
UNDERSTAND: Restate requirement in own words (or ask)
VERIFY: Check against codebase reality
EVALUATE: Technically sound for THIS codebase?
RESPOND: Technical acknowledgment or reasoned pushback
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):

Request re-review via arc-requesting-review — loop until reviewer approves
Once approved → run arc-verifying to confirm all requirements and tests pass
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 — claim your Tome and manage your conversions.

---name: arc-receiving-reviewdescription: Use when receiving code review feedback, requires technical rigor not performative agreement---# arc-receiving-review## Core PrincipleVerify before implementing. Ask before assuming. Technical correctness over social comfort.## The Response Pattern1. READ: Complete feedback without reacting2. UNDERSTAND: Restate requirement in own words (or ask)3. VERIFY: Check against codebase reality4. EVALUATE: Technically sound for THIS codebase?5. RESPOND: Technical acknowledgment or reasoned pushback6. 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 FeedbackIF any item is unclear: STOP - do not implement anything yet ASK for clarification on ALL unclear itemsWHY: 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 CheckIF reviewer suggests "implementing properly": grep codebase for actual usage IF unused: "This isn't called. Remove it (YAGNI)?"## After This SkillWhen all feedback items are implemented and tested:**Autonomous mode (agent-driven / looping):**1. Request re-review via `arc-requesting-review` — loop until reviewer approves2. Once approved → run `arc-verifying` to confirm all requirements and tests pass3. 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.

Frequently asked questions

Arc Receiving Review