evaluate-findings

Name: evaluate-findings
Author: tobihagemann

23installs29forks

How to install evaluate-findings?

tobihagemann/turbo/evaluate-findings

$npx -y skills add tobihagemann/turbo --skill evaluate-findings

Installs into the current project.

Summary

Critically assess external feedback (code reviews, AI reviewers, PR comments) and decide which suggestions to apply using adversarial verification. Use when the user asks to \"evaluate findings\", \"assess review comments\", \"triage review feedback\", \"evaluate review output\",

Files · 1

View on GitHub

SKILL.md

1	# Evaluate Findings
2
3	Assess external feedback (code reviews, AI suggestions, PR comments) with adversarial verification. Triage findings into actionable verdicts. Do not apply fixes.
4
5	## Step 1: Assess Each Finding
6
7	If you already assessed a finding earlier in this session and recorded a verdict of Skip or Escalate — for example when an iterating loop re-runs review and the same finding resurfaces — do not re-adjudicate it from scratch. When the re-reported finding matches one you already judged (same location and substance) and presents no new evidence beyond what your recorded reason already accounts for, keep that verdict and reason without re-reading the code, re-verifying, or routing it to the Devil's Advocate in Step 2. Assess fresh only when the finding raises materially new evidence, or when you have not judged it before in this session.
8
9	For each finding:
10
11	1. Read the referenced code at the mentioned location — include the full function or logical block, not just the flagged line
12	2. Check whether the code has diverged — if the finding references code that no longer exists or has since changed, skip it and note the divergence.
13	3. Determine scope — clarify whether the issue was introduced by the PR/changeset or is pre-existing.
14	- Pre-existing issues in earlier commits on the same feature branch are in-scope by default — the entire branch is one coherent unit of work. Judge these on their merits like any in-scope finding.
15	- Findings genuinely outside the branch's work are the user's call to include. Assign Escalate so the user decides whether to widen the changeset. Reserve Skip for changes whose cost wildly dwarfs the benefit.
16	4. Verify the claim against the actual code — does the issue genuinely exist?
17	5. Assess severity:
18
19	\| Severity \| Meaning \|
20	\|----------\|---------\|
21	\| Critical \| Drop everything. Blocking release or operations. \|
22	\| High \| Urgent. Should be addressed in the next cycle. \|
23	\| Medium \| Normal. To be fixed eventually. \|
24	\| Low \| Nice to have. Minor improvement. \|
25
26	If the upstream reviewer already assigned a priority (P0-P3), map it: P0→Critical, P1→High, P2→Medium, P3→Low. Then re-assess based on what the actual code reveals. The upstream level is a starting point, not a binding constraint. When the re-assessed severity differs from the upstream level, note the change and the reason.
27
28	If the finding has no upstream priority, assess severity from scratch.
29
30	6. Assign a verdict and confidence:
31
32	\| Verdict \| Criteria \|
33	\|---------\|----------\|
34	\| Apply \| The finding is real and in scope: clear bug, missing check, genuine improvement, style violation matching project conventions \|
35	\| Skip \| False positive, subjective preference, reviewer is wrong, or the change's cost wildly dwarfs its benefit \|
36	\| Escalate \| Needs the user's judgment: behavior might be intentional, involves product intent, requires domain knowledge the agent lacks, the finding is out of scope, or two findings present a genuine trade-off \|
37
38	Also assign an internal confidence level — High, Medium, or Low — reflecting how certain you are about the verdict. Confidence is used solely to route findings to the Devil's Advocate in Step 2. It does not appear in the output.
39
40	Escalate guidance: When a finding questions whether behavior is intentional and neither docs, specs, nor code comments clarify the intent, assign Escalate. Do not autonomously accept or reject findings that hinge on product intent. If a counterpart implementation exists elsewhere, suggest checking it for consistency.
41
42	Conflict guidance: When two findings contradict each other (they suggest opposite changes to the same code), treat the conflict as input, not a reason to skip. Verify each against the code and judge each on its merits as usual. If both are defensible and the choice is a genuine trade-off, assign Escalate to both, naming the opposing options so the user can decide.
43
44	An affirmation that something is correct is not a finding and carries no evidentiary weight; agreement among reviewers, or a reviewer's authority, does not settle whether a problem exists. When reviewers disagree on whether something is a problem at all — including one asserting it is fine while another flags it — treat the question as unresolved and verify it against the code, without letting the affirmation substitute for verification.
45
46	Verdict guidance:
47
48	- Never auto-dismiss findings about security defaults, permission escalation, or fail-open vs fail-closed behavior. Always surface these even if the behavior appears intentional.
49	- Read

People who liked this also viewed

6 picks

Type

evaluate-findings

23installs29forks

View on GitHub

How to install evaluate-findings?

tobihagemann/turbo/evaluate-findings

$npx -y skills add tobihagemann/turbo --skill evaluate-findings

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Evaluate Findings
2
3	Assess external feedback (code reviews, AI suggestions, PR comments) with adversarial verification. Triage findings into actionable verdicts. Do not apply fixes.
4
5	## Step 1: Assess Each Finding
6
7	If you already assessed a finding earlier in this session and recorded a verdict of Skip or Escalate — for example when an iterating loop re-runs review and the same finding resurfaces — do not re-adjudicate it from scratch. When the re-reported finding matches one you already judged (same location and substance) and presents no new evidence beyond what your recorded reason already accounts for, keep that verdict and reason without re-reading the code, re-verifying, or routing it to the Devil's Advocate in Step 2. Assess fresh only when the finding raises materially new evidence, or when you have not judged it before in this session.
8
9	For each finding:
10
11	1. Read the referenced code at the mentioned location — include the full function or logical block, not just the flagged line
12	2. Check whether the code has diverged — if the finding references code that no longer exists or has since changed, skip it and note the divergence.
13	3. Determine scope — clarify whether the issue was introduced by the PR/changeset or is pre-existing.
14	- Pre-existing issues in earlier commits on the same feature branch are in-scope by default — the entire branch is one coherent unit of work. Judge these on their merits like any in-scope finding.
15	- Findings genuinely outside the branch's work are the user's call to include. Assign Escalate so the user decides whether to widen the changeset. Reserve Skip for changes whose cost wildly dwarfs the benefit.
16	4. Verify the claim against the actual code — does the issue genuinely exist?
17	5. Assess severity:
18
19	\| Severity \| Meaning \|
20	\|----------\|---------\|
21	\| Critical \| Drop everything. Blocking release or operations. \|
22	\| High \| Urgent. Should be addressed in the next cycle. \|
23	\| Medium \| Normal. To be fixed eventually. \|
24	\| Low \| Nice to have. Minor improvement. \|
25
26	If the upstream reviewer already assigned a priority (P0-P3), map it: P0→Critical, P1→High, P2→Medium, P3→Low. Then re-assess based on what the actual code reveals. The upstream level is a starting point, not a binding constraint. When the re-assessed severity differs from the upstream level, note the change and the reason.
27
28	If the finding has no upstream priority, assess severity from scratch.
29
30	6. Assign a verdict and confidence:
31
32	\| Verdict \| Criteria \|
33	\|---------\|----------\|
34	\| Apply \| The finding is real and in scope: clear bug, missing check, genuine improvement, style violation matching project conventions \|
35	\| Skip \| False positive, subjective preference, reviewer is wrong, or the change's cost wildly dwarfs its benefit \|
36	\| Escalate \| Needs the user's judgment: behavior might be intentional, involves product intent, requires domain knowledge the agent lacks, the finding is out of scope, or two findings present a genuine trade-off \|
37
38	Also assign an internal confidence level — High, Medium, or Low — reflecting how certain you are about the verdict. Confidence is used solely to route findings to the Devil's Advocate in Step 2. It does not appear in the output.
39
40	Escalate guidance: When a finding questions whether behavior is intentional and neither docs, specs, nor code comments clarify the intent, assign Escalate. Do not autonomously accept or reject findings that hinge on product intent. If a counterpart implementation exists elsewhere, suggest checking it for consistency.
41
42	Conflict guidance: When two findings contradict each other (they suggest opposite changes to the same code), treat the conflict as input, not a reason to skip. Verify each against the code and judge each on its merits as usual. If both are defensible and the choice is a genuine trade-off, assign Escalate to both, naming the opposing options so the user can decide.
43
44	An affirmation that something is correct is not a finding and carries no evidentiary weight; agreement among reviewers, or a reviewer's authority, does not settle whether a problem exists. When reviewers disagree on whether something is a problem at all — including one asserting it is fine while another flags it — treat the question as unresolved and verify it against the code, without letting the affirmation substitute for verification.
45
46	Verdict guidance:
47
48	- Never auto-dismiss findings about security defaults, permission escalation, or fail-open vs fail-closed behavior. Always surface these even if the behavior appears intentional.
49	- Read

People who liked this also viewed

6 picks

Type