triage-verifier

name	triage-verifier
description	Final proof gate for red-team findings. Produce high-quality, near-submission-ready proof packets that can be used directly in strong bug bounty reports. Use only after a finding has reached "confident" in finding-tracker. The goal is not just verification — it is to create a clean, convincing, and well-documented exploit PoC that stands up to real triager scrutiny.
metadata	{"short-description":"Red-team proof gate — produce submission-quality proof packets and high-realism PoCs","category":"vulnerability-research","priority":"critical"}

Triage Verifier (Red Team Edition)

This is the stage where a promising lead becomes something you can actually submit with confidence.

The job of triage-verifier is no longer just "confirm it works." It is to produce a high-quality, realistic, and well-documented proof packet that is as close as possible to what a strong HackerOne or Bugcrowd submission would contain.

We are deliberately raising the bar here so that most of the heavy lifting for a good report is already done by the time something leaves this skill.

Core Philosophy

• A finding is only truly "proofed" when the evidence package is strong enough that a competent triager would take it seriously with minimal additional work.
• We want realistic PoCs — not toy examples. The reproduction should feel like something an actual attacker could use.
• Negative controls and constraints are not optional theater. They are what make the finding credible and defensible.
• triage-theater is now optional. It is for creating beautiful video walkthroughs when you want them. It is not required to reach high submission quality.

When to Bring a Finding Here

Only escalate findings that are already confident in finding-tracker. If the upstream work (from code-vulnerability-review, web-app-security-inspection, binary-debugging, etc.) is still half-baked, send it back.

Submission-Quality Proof Packet Standard

The final output of this skill should aim for the following qualities:

• Clear, professional claim — A concise, accurate description of the vulnerability and its impact.
• Minimal but realistic reproduction — The smallest set of steps that reliably demonstrates the issue in an authorized lab environment.
• Strong negative controls — Multiple states showing what should fail vs. what succeeds (owner vs non-owner, correct role vs incorrect role, patched vs unpatched, etc.).
• Honest constraints — Explicit documentation of what an attacker would need (authentication level, specific conditions, timing, feature flags, etc.).
• Evidence quality — Request/response pairs, screenshots, console output, memory/register state, or other artifacts that are clean and convincing.
• Impact narrative — Not just "this is bad," but a clear explanation of what an attacker could actually achieve.

The proof packet should be written at a level where it could be dropped into a report with only light editing.

Verification Workflow

1. Load the finding and confirm it is confident.
2. Reconstruct the full claim (entry point, controlled data, missing control, violated boundary, impact).
3. Reproduce the issue yourself in a clean, well-documented environment.
4. Develop strong negative controls and edge cases.
5. Harden the PoC until it is minimal, reliable, and realistic.
6. Document constraints, preconditions, and any relevant mitigations.
7. Decide the outcome and update finding-tracker.
8. Generate a high-quality proof packet using the helper script.

PoC Hardening Rules (Raised Standard)

Rewrite PoCs until they meet these higher expectations:

• The reproduction is deterministic and as small as reasonably possible.
• It demonstrates real attacker value (not just a theoretical or low-impact condition).
• Negative controls clearly prove the security boundary matters.
• The PoC fails closed and gives useful feedback when preconditions are not met.
• Artifacts are redacted but still realistic (no obvious "this is a lab-only toy").
• The overall package tells a coherent story that supports the claimed severity.

If a finding cannot reach this level after reasonable effort, it should usually go back to needs-more-work or be de-escalated.

Acceptable Outcomes

• proofed: The evidence package meets the submission-quality standard. Create the proof packet and mark the finding accordingly.
• needs-more-work: The core issue looks real, but the current PoC or evidence is not yet strong enough for a high-quality submission. Return it with specific gaps.
• de-escalated: After real reproduction effort, the impact collapses or the attack path is not viable. Document the reasons clearly.
• split-or-duplicate: The verification reveals the finding should be merged or broken apart.

Helper Script

Use proof_packet.py to generate a structured, high-quality proof artifact:

python3 .grok/skills/triage-verifier/scripts/proof_packet.py \
  --finding-id F-00XX \
  --title "..." \
  --target "..." \
  --claim "..." \
  --reproduction "..." \
  --expected "..." \
  --actual "..." \
  --impact "..." \
  --negative-control "..." \
  --constraints "..." \
  --poc "path/to/repro.py"

After verification, update the tracker:

python3 .grok/skills/finding-tracker/scripts/findings.py update F-00XX \
  --state proofed \
  --proof-ref "data/triage-verifier/F-00XX-proof.md"

Handoffs

• Primary path: After a strong proof packet is created → report-writer (for bounty submission or internal advisory).
• exploit-chain-analysis — if this proofed finding can be combined with others.
• triage-theater — optional only. Use when you specifically want a polished, human-operated video reproduction kit. It is no longer required for quality.
• Return to the originating skill when a specific gap needs more research.

Bottom Line

In this red-team stack, triage-verifier is the last quality filter before something becomes a real submission.

We are not just checking boxes. We are producing proof packets that are as close as possible to real, submittable exploit demonstrations — honest, well-documented, and convincing.

If it doesn't feel strong enough to attach to a serious report, it is not ready to be marked proofed.