From arcforge
Guides handling code review feedback with technical rigor: read, understand, verify against codebase, evaluate, respond or pushback, implement one at a time. Avoids performative agreement.
npx claudepluginhub gregoryho/arcforge --plugin arcforgeThis skill uses the workspace's default tool permissions.
Verify before implementing. Ask before assuming. Technical correctness over social comfort.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
Verify before implementing. Ask before assuming. Technical correctness over social comfort.
IF any item is unclear: STOP - do not implement anything yet ASK for clarification on ALL unclear items
WHY: Partial understanding = wrong implementation
From your human partner:
If external feedback conflicts with human partner:
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."
IF reviewer suggests "implementing properly": grep codebase for actual usage IF unused: "This isn't called. Remove it (YAGNI)?"
When all feedback items are implemented and tested:
Autonomous mode (agent-driven / looping):
arc-requesting-review — loop until reviewer approvesarc-verifying to confirm all requirements and tests passarc-finishing (regular branch) or arc-finishing-epic (worktree with .arcforge-epic)Manual mode (human-in-loop):