External Feedback Triage
Treat every external suggestion as a hypothesis until it is checked against the current scope and evidence.
When to activate
- A scanner, reviewer, model, blog, PoC README, advisory, or issue says what to fix or exploit.
- Feedback conflicts with local evidence.
- A requested change feels broad, risky, noisy, or unrelated to the original task.
Triage loop
- Restate feedback in neutral technical terms.
- Check applicability: version, platform, configuration, code path, permissions, and scope.
- Classify severity: critical correctness, security risk, maintainability, style, or preference.
- Verify evidence: apply
evidence-before-claims before accepting.
- Choose action: apply, adapt, defer, reject, or ask for clarification.
- Patch minimally when acting; do not bundle unrelated cleanup.
- Report disagreement with evidence when rejecting or narrowing feedback.
Pushback is useful
Do not agree just because feedback sounds authoritative. Push back when:
- it assumes an unsupported threat model
- it requires out-of-scope access or noisy actions
- it solves a different version/configuration
- it adds abstraction without repeated need
- it weakens tests, evidence, or operator safety
Output contract
For non-trivial feedback, return:
- feedback summary
- applicability result
- action taken or rejected
- remaining risk or follow-up
Evidence output shape: pair with evidence-before-claims.
Resources
Load on demand:
references/review-feedback.md — decision table for reviews, scanner output, advisories, PoCs, and model suggestions.
Pair with:
evidence-before-claims — evidence quality and claim wording when verifying accepted feedback.verification-before-completion — freshness gate before claiming the applied fix is complete.
1---2name: external-feedback-triage3description: Triage external technical feedback before applying it. Use for code reviews, scanner findings, exploit PoC notes, blog advice, LLM suggestions, issue comments, and advisory recommendations. Verifies context fit, evidence, risk, and minimal changes instead of accepting or rejecting feedback performatively.4license: MIT5---67# External Feedback Triage89Treat every external suggestion as a hypothesis until it is checked against the current scope and evidence.1011## When to activate1213- A scanner, reviewer, model, blog, PoC README, advisory, or issue says what to fix or exploit.14- Feedback conflicts with local evidence.15- A requested change feels broad, risky, noisy, or unrelated to the original task.1617## Triage loop18191. **Restate feedback** in neutral technical terms.202. **Check applicability**: version, platform, configuration, code path, permissions, and scope.213. **Classify severity**: critical correctness, security risk, maintainability, style, or preference.224. **Verify evidence**: apply `evidence-before-claims` before accepting.235. **Choose action**: apply, adapt, defer, reject, or ask for clarification.246. **Patch minimally** when acting; do not bundle unrelated cleanup.257. **Report disagreement** with evidence when rejecting or narrowing feedback.2627## Pushback is useful2829Do not agree just because feedback sounds authoritative. Push back when:3031- it assumes an unsupported threat model32- it requires out-of-scope access or noisy actions33- it solves a different version/configuration34- it adds abstraction without repeated need35- it weakens tests, evidence, or operator safety3637## Output contract3839For non-trivial feedback, return:4041- feedback summary42- applicability result43- action taken or rejected44- remaining risk or follow-up4546Evidence output shape: pair with `evidence-before-claims`.4748## Resources4950Load on demand:5152- `references/review-feedback.md` — decision table for reviews, scanner output, advisories, PoCs, and model suggestions.5354Pair with:5556- `evidence-before-claims` — evidence quality and claim wording when verifying accepted feedback.57- `verification-before-completion` — freshness gate before claiming the applied fix is complete.
AeonDave