From forge
Use when receiving code review feedback. Verify suggestions against the codebase before implementing. Push back when feedback is incorrect.
npx claudepluginhub caseyrtalbot/forge --plugin forgeThis skill uses the workspace's default tool permissions.
Evaluate code review feedback through technical verification, not social performance. Every suggestion gets checked against codebase reality before implementation. Disagreement backed by evidence is more valuable than agreement backed by nothing.
Verifies tests pass on completed feature branch, presents options to merge locally, create GitHub PR, keep as-is or discard; executes choice and cleans up worktree.
Guides root cause investigation for bugs, test failures, unexpected behavior, performance issues, and build failures before proposing fixes.
Writes implementation plans from specs for multi-step tasks, mapping files and breaking into TDD bite-sized steps before coding.
Evaluate code review feedback through technical verification, not social performance. Every suggestion gets checked against codebase reality before implementation. Disagreement backed by evidence is more valuable than agreement backed by nothing.
Do NOT implement review feedback without verifying it against the codebase first. Performative agreement is forbidden. "You're right, implementing now" without checking the code is not a response -- it is a failure of technical discipline. Read the feedback, verify the claims, then act.digraph receive_feedback {
"READ all feedback" [shape=box];
"UNDERSTAND: restate requirement" [shape=box];
"Unclear?" [shape=diamond];
"Ask for clarification" [shape=box];
"VERIFY against codebase" [shape=box];
"EVALUATE: sound for this codebase?" [shape=diamond];
"RESPOND: acknowledge or push back" [shape=box];
"IMPLEMENT via prove-first" [shape=doublecircle];
"READ all feedback" -> "UNDERSTAND: restate requirement";
"UNDERSTAND: restate requirement" -> "Unclear?";
"Unclear?" -> "Ask for clarification" [label="yes"];
"Ask for clarification" -> "UNDERSTAND: restate requirement";
"Unclear?" -> "VERIFY against codebase" [label="no"];
"VERIFY against codebase" -> "EVALUATE: sound for this codebase?";
"EVALUATE: sound for this codebase?" -> "RESPOND: acknowledge or push back" [label="yes"];
"EVALUATE: sound for this codebase?" -> "RESPOND: acknowledge or push back" [label="no, with evidence"];
"RESPOND: acknowledge or push back" -> "IMPLEMENT via prove-first";
}
These indicate performative agreement, not technical verification:
Instead: restate the technical requirement, verify it, then act or push back.
When feedback is wrong, say so with evidence:
When feedback contains multiple items, triage by impact:
Address critical first, not comfortable first.
"Implementing everything without checking" Some suggestions are wrong. Some are based on misreading the code. Some fix problems that do not exist. Verify first.
"Arguing with everything" Pushback requires evidence, not preference. "I don't like that approach" is not pushback. "This breaks the existing contract at api/handler.ts:87" is pushback.
"Cherry-picking easy items" Addressing the typo fix while ignoring the security vulnerability is not progress. Critical items first, regardless of effort.
"Batch-implementing without testing" Implement one item, test it, confirm it works, then move to the next. Batch changes hide which fix broke what.
When verified feedback requires code changes, implement via prove-first: write the failing test for the fix, then write the minimal code to pass it.