菜单
Use when receiving code review feedback, requires technical rigor not performative agreement
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when running autonomous unattended loops — cross-session execution of DAG tasks without human intervention
Use when converting design documents to structured specs, when spec quality is below threshold, or when requirements need formal acceptance criteria
Use when you need to verify work is complete before making completion claims
Use when maintaining ArcForge itself by creating, editing, or verifying ArcForge skills before deployment
Use when optional learning is enabled and observations should become reviewable candidates, inactive drafts, and explicitly activated artifacts.
Use when user asks about behavioral patterns, requests instinct status, or wants to confirm/contradict a detected pattern
| name | arc-receiving-review |
| description | Use when receiving code review feedback, requires technical rigor not performative agreement |
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 (Step 0 discriminates on .arcforge-epic)Manual mode (human-in-loop):