| 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
- Load the finding and confirm it is
confident.
- Reconstruct the full claim (entry point, controlled data, missing control, violated boundary, impact).
- Reproduce the issue yourself in a clean, well-documented environment.
- Develop strong negative controls and edge cases.
- Harden the PoC until it is minimal, reliable, and realistic.
- Document constraints, preconditions, and any relevant mitigations.
- Decide the outcome and update
finding-tracker.
- 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.
