Evaluate Feedback

Evaluate incoming requirements, feedback, or bug reports. Prioritize before acting on anything.

Recommended model: Sonnet

Rules

1. Classify each item

Read all feedback. For each item, assign:

2. Flag contradictions and unclear specs

Before scoring, identify:

• Items that contradict each other
• Items where the requirement is ambiguous
• Items that are out of scope for the current milestone

For unclear items, ask a clarifying question with preset options:

Q: "[unclear item]" — what is the intended behavior?
  1. [interpretation A]
  2. [interpretation B]
  3. [interpretation C]
  4. Other — describe below

Resolve ambiguities before prioritizing.

3. Output a prioritized list

Format:

Priority | # | Type       | Impact | Effort | Item
---------|---|------------|--------|--------|-----
P1       | 1 | security   | High   | Low    | JWT expiry not validated
P1       | 2 | bug        | High   | Medium | Race condition in createUser
P2       | 3 | feature    | Medium | Medium | Add pagination to /users
P3       | 4 | chore      | Low    | Low    | Rename internal variable

Priority rules:

• P1: security bugs, data-loss bugs, High impact + Low/Medium effort
• P2: features and improvements with clear specs, Medium impact
• P3: Low impact, chores, nice-to-haves

4. Suggest batching strategy

After the list, suggest how to group items into commits:

Suggested batching:

• Commit 1: Items 1 + 2 (both security/correctness fixes, same area)
• Commit 2: Item 3 (standalone feature)
• Commit 3: Item 4 (chore, separate)

5. Hard stop before implementation

End with:

Confirm this priority order or make adjustments, then choose an item to start with.

Do not implement anything until the user confirms.

What NOT to do

• Do not start implementing before the user confirms the priority list
• Do not silently pick an interpretation for unclear items
• Do not combine high-risk and low-risk changes into the same suggested commit
• Do not skip the batching suggestion — it helps keep commits small