proposal-evaluator

Proposal Evaluator

Evaluate an incoming proposal, suggestion, or review comment before deciding how to act on it. Produces a structured verdict with explicit reasoning — not just "what was said" but "whether it should be done."

Input

• One or more proposals/comments to evaluate
• Context: the file, code, or design they refer to (optional but recommended)

---

Step 1: Understand the Proposal

Read the proposal carefully and extract:

• Claim: What is being asserted? (e.g., "this code will crash if X")
• Suggested action: What change is being requested?
• Implicit assumption: What does the proposer assume to be true?

---

Step 2: Score on 5 Axes

Score each axis 1–3 and note a brief rationale.

Axis	Score	Question
Accuracy	1–3	Is the claim technically correct? Are the premises sound?
Fit	1–3	Does it align with project conventions and CLAUDE.md?
Severity	1–3	How serious is the underlying issue? (Bug/Security=3, Style=2, Nitpick=1)
Value/Cost	1–3	Does the benefit justify the implementation cost?
Timing	1–3	Must this be addressed now in this PR/task, or can it wait?

Total = sum of scores (max 15)

---

Step 3: Decide Action

Total	Default Action
12–15	Accept — implement as suggested
8–11	Counter — valid concern, but propose a better solution
6–7	Defer — acknowledge, create follow-up issue if warranted
5	Decline — reject with explanation

The score is a guide, not a rule. Override with explicit reasoning if context warrants it. A score of 1 on Accuracy alone can override a high total (wrong premise = don't act).

---

Step 4: Produce Verdict

For each proposal, output:

### [Proposal summary — one line]

**Accuracy**: N/3 — [rationale]
**Fit**: N/3 — [rationale]
**Severity**: N/3 — [rationale]
**Value/Cost**: N/3 — [rationale]
**Timing**: N/3 — [rationale]

**Total**: N/15 → **ACTION**

**Reasoning**: [1–3 sentences explaining the decision]

**Response to proposer**: [Draft reply text — be direct, not defensive]

---

Step 5: Act on Decision

Action	What to do
Accept	Implement the change, reply "Fixed in <commit>."
Counter	Implement your alternative, reply with explanation of why your approach is better
Defer	Do not change code, reply with acknowledgement + link to follow-up issue if created
Decline	Do not change code, reply with clear reasoning — invite further discussion if appropriate

---

Notes

• A Decline is not a dismissal — explain the reasoning respectfully and invite pushback
• A Counter is still an Accept of the underlying concern, just with a better solution
• If Accuracy is 1 (claim is wrong), Decline regardless of other scores
• When in doubt between Defer and Decline: Defer if the concern has merit but poor timing; Decline if the premise is flawed

---

Related Skills

• pr-comment-handler — uses this skill in Step 2 (Triage) to evaluate each review comment