skeptical-triage
О программе
Этот навык Claude реализует 3-раундную самопроверку с арбитром для строгой фильтрации ложных срабатываний в результатах или заключениях. Он предназначен для высокорисковых сценариев, где ложное срабатывание, ведущее к блокировке, было бы дорогостоящим — например, при остановке развертывания или записи в доверенные отчеты. В процессе проверки навык использует такие инструменты, как Read, Grep и Bash, для анализа путей в коде и документации.
Быстрая установка
Claude Code
Рекомендуетсяnpx skills add avelikiy/great_cto -a claude-code/plugin add https://github.com/avelikiy/great_ctogit clone https://github.com/avelikiy/great_cto.git ~/.claude/skills/skeptical-triageСкопируйте и вставьте эту команду в Claude Code для установки этого навыка
Документация
Skeptical Triage
Filter false positives from multi-angle review, security audit, QA regression flags, or any high-stakes judgment before it turns into a blocker.
Three rounds of skeptical self-review + an impartial arbiter, with a confidence score from the vote.
When to invoke
| Caller | Finding type | Apply triage? |
|---|---|---|
/review | Angle 2/4/7/9 P0/P1 (security, SQL, privacy, concurrency) | Yes |
/review --deep | Any angle P0/P1 | Yes |
security-officer | CSO audit P0/P1 | Yes |
security-officer | Secret in source/git, confirmed CVE | No — hard finding |
qa-engineer | Flaky-test verdict (is this a regression or flake?) | Yes |
architect | ADR trade-off dispute (option A vs. B when both look reasonable) | Yes |
| Any | P2/advisory | No |
The 4-step pattern
Run these sequentially. Each round sees prior reasoning. Arbiter sees all rounds.
Round 1 — Reachability / Premise
Question: is the premise true?
- For security/reliability: can an external attacker reach this code path with untrusted input? Trace input flow backward from the bug site to its origin. If only trusted internal callers → lean INVALID.
- For regressions: does the failing behavior reproduce from a clean state on the target branch?
- For ADR trade-offs: is the constraint that forces the choice actually binding? (e.g. "we need <10ms p99" — is that real or aspirational?)
Output: {round: 1, verdict: VALID|INVALID|UNCERTAIN, reasoning: "...", crux: "single key fact"}
Round 2 — Verify cited defenses / counter-evidence
Question: are claimed defenses real and sufficient?
- Every cited defense → use
Grepto find its actual implementation line. - Resolve constant names to numeric values.
MAX_BUF_SIZEis not a verified bound —#define MAX_BUF_SIZE 64is. - For regressions: is the cited "test covers this" actually asserting the right invariant?
- For ADR: is the cited benchmark/precedent real (grep for it, read it), or rumored?
If you cannot point to the line that enforces the defense, it does not exist.
Output: same JSON shape, with grep_used: true/false.
Round 3 — Missed angles
Question: what did Rounds 1-2 not consider?
- Error paths, integer overflow, race windows, different callers, platform differences
- Do NOT rehash prior rounds — add new evidence or concede
- For QA: retry logic masking the failure? Test pollution from another test?
- For ADR: option C that neither reviewer raised?
Output: same JSON shape.
Arbiter
Input: all 3 rounds + original finding/question + source code.
Question: final call — which side has the stronger evidence?
- Deliver single
verdict: VALID|INVALID(no UNCERTAIN — make the call). - Deliver one-sentence
crux— the key fact the verdict turns on. - If 3 prior rounds all said the same thing, only override with overwhelming new evidence and explain why.
Output:
{
"verdict": "VALID",
"crux": "memcpy at auth.c:142 copies network-controlled len bytes into 64-byte stack buffer with no bound check",
"reasoning": "Rounds 1 and 3 verified attacker reach; Round 2 found no size check in 50 LOC radius; arbiter confirms no caller clamps len."
}
Hard rules
Burn these into every round's prompt:
- Absence of defense → VALID, not UNCERTAIN. If you searched for a defense and did not find one, that is the answer. "Other code probably handles this" is not a valid defense.
- A constant name is not a verified bound — only its resolved value is. Grep for the
#define/constdeclaration. - Name the line or it does not exist. Vague references to "assumptions in this codebase" do not count.
- Do not contradict your own conclusion in the same response. If you verified a defense is insufficient, that is the verdict. Stop searching for reasons to flip.
- Code quality issue ≠ security vulnerability. Data race on diagnostic state, NULL check on internal-only API, UB only in debug builds → INVALID.
- Trust your own reasoning. If you see the crux on first read, don't manufacture a counter-argument.
Confidence scoring
confidence = valid_rounds_before_arbiter / 3
100%(VVV) — 3/3 rounds VALID. Arbiter rubber-stamps unless it finds something brand-new.67%(VVI or VIV or IVV) — majority VALID. Arbiter breaks tie with new evidence.33%(IIV or IVI or VII) — majority INVALID. Arbiter usually confirms INVALID.0%(III) — 3/3 INVALID. Arbiter rarely overrides.
Arbiter overrides the final verdict; confidence reflects the round vote for transparency. Record both in the output so humans can see where the arbiter diverged.
Applying triage results to severity
Once the arbiter returns:
| Arbiter verdict | Confidence | Severity action |
|---|---|---|
VALID | ≥ 50% | Keep original severity |
VALID | < 50% | Demote: P0→P1, P1→P2 |
INVALID | any | Remove from gate tally, record as [FILTERED] in report for audit |
UNCERTAIN (only if arbiter could not decide) | n/a | Keep original severity, flag for manual CTO review |
Output schema
Every caller logs triage results to .great_cto/triage-log.jsonl (append-only, one JSON per line):
{
"timestamp": "2026-04-19T12:34:56Z",
"caller": "review|security-officer|qa-engineer|architect",
"finding_id": "SEC-042",
"file": "src/auth.c:142",
"original_severity": "P0",
"rounds": [
{"round": 1, "verdict": "VALID", "crux": "..."},
{"round": 2, "verdict": "VALID", "crux": "...", "grep_used": true},
{"round": 3, "verdict": "INVALID", "crux": "..."}
],
"arbiter": {"verdict": "VALID", "crux": "..."},
"confidence": 0.67,
"final_severity": "P0"
}
This log is how we measure whether triage earns its keep. Review it weekly:
# False-positive rate: how many findings the arbiter flipped to INVALID
jq 'select(.arbiter.verdict=="INVALID")' .great_cto/triage-log.jsonl | wc -l
# Average rounds-to-consensus (did we need all 3 or did R1+R2 agree?)
jq '[.rounds[].verdict] | unique | length' .great_cto/triage-log.jsonl
If FP rate < 10% after 50 triages — triage is filtering noise that wasn't there. Lower threshold or skip triage for that angle. If FP rate > 40% — original review prompt is too trigger-happy; tighten the angle rules.
Token budget
Per triaged finding: ~4 LLM turns (3 rounds + arbiter). At typical review sizes (~5-10 triaged findings per PR), total budget: 20-40 extra turns per /review. Batch when possible — one arbiter can handle multiple findings in a single call if their cruxes are independent.
For cost-sensitive runs (approval-level: auto on a huge PR), consider: triage only P0, leave P1 untriaged. Re-tune based on .great_cto/triage-log.jsonl data.
Anti-patterns
- Don't triage P2/advisory findings. The whole point is gate decisions. P2 is advisory — let the author see it and move on.
- Don't let rounds rehash each other. Round 3 prompt must say "add NEW evidence or concede." If 3 rounds produce identical reasoning, you wasted 2 turns.
- Don't skip the arbiter on UNCERTAIN. If all 3 rounds say UNCERTAIN, the arbiter's job is to decide — not to join the fog.
- Don't hide arbiter overrides. When the arbiter flips the majority vote, record both
confidence(the vote) andfinal_verdict(the arbiter). Humans deserve to see the disagreement.
GitHub репозиторий
Похожие навыки
llamaguard
ДругоеLlamaGuard — это модель от Meta с 7–8 миллиардами параметров для модерации входных и выходных данных больших языковых моделей по шести категориям безопасности, таким как насилие и разжигание ненависти. Она обеспечивает точность 94–95% и может быть развернута с помощью vLLM, Hugging Face или Amazon SageMaker. Используйте этот навык, чтобы легко интегрировать фильтрацию контента и защитные механизмы в ваши ИИ-приложения.
cost-optimization
ДругоеЭтот навык Claude помогает разработчикам оптимизировать облачные расходы за счет правильного подбора ресурсов, стратегий тегирования и анализа затрат. Он предоставляет framework для сокращения облачных расходов и внедрения управления затратами в AWS, Azure и GCP. Используйте его, когда вам нужно проанализировать расходы на инфраструктуру, оптимизировать ресурсы или уложиться в бюджетные ограничения.
quantizing-models-bitsandbytes
ДругоеЭтот навык выполняет квантизацию LLM до 8-битной или 4-битной точности с использованием библиотеки bitsandbytes, обеспечивая сокращение использования памяти на 50-75% при минимальной потере точности. Он идеально подходит для запуска больших моделей при ограниченной памяти GPU или для ускорения вывода, поддерживая форматы INT8, NF4 и FP4. Навык интегрируется с HuggingFace Transformers и позволяет использовать обучение QLoRA и 8-битные оптимизаторы.
dispatching-parallel-agents
ДругоеЭтот навык Claude распределяет нескольких агентов для исследования и устранения трёх и более независимых проблем параллельно. Он предназначен для сценариев с несвязанными сбоями, которые можно устранить без общего состояния или зависимостей. Ключевая возможность — параллельное решение проблем, где за каждую независимую предметную область назначается отдельный агент для максимальной эффективности.
