Bulk triages open reports across assigned HackenProof programs: discovers reports via API, syncs local git repos, analyzes each, outputs structured recommendations for human review.
How this skill is triggered — by the user, by Claude, or both
Slash command
/hackenproof-bulk-triage:hackenproof-bulk-triageThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Analyze all open reports across all assigned programs and produce a structured recommendation report for human review. Never change state, severity, labels, or post comments without explicit user confirmation.
Analyze all open reports across all assigned programs and produce a structured recommendation report for human review. Never change state, severity, labels, or post comments without explicit user confirmation.
~/.claude/hackenproof-repos.yaml.list_companies + list_programs.Read ~/.claude/hackenproof-repos.yaml using the Read tool. See references/setup-guide.md for file format and examples.
Parse the programs mapping: program-slug → { repo?, branch?, explorer?, enabled? }.
Skip any program entry where enabled: false.
A program entry may have:
repo — path to a local git clone (for source-based validation)explorer — a blockchain explorer URL to a deployed contract (e.g. https://nearblocks.io/address/intents.near)After loading the config, present the user with a numbered list of all enabled programs and ask which to include in this run:
Programs available for triage:
1. near-intents-smart-contracts (repo: ~/hackenproof/bb/near/intents)
2. bluefin-dex-contracts (repo: ~/hackenproof/private_programs/bluefin/...)
3. kai-finance-yield-protocol (repo: ~/hackenproof/bb/kai-finance/...)
...
Which programs to triage? (default: all)
→ Type numbers separated by commas (e.g. 1, 3), program slugs, or "all"
all or just presses enter (empty input), include all enabled programs.list_companies to get all companies with assigned roles.list_programs to enumerate programs.(company_slug, program_slug) pairs, filtered to the selection from Step 1.5.enabled: false, exclude it from this list.For each program in config, determine validation mode:
repo is set (source repo)repo path (expand ~ if needed).git -C {repo} fetch --quiet to update remote refs without modifying working tree.git -C {repo} log -1 --oneline to get the current local HEAD.git -C {repo} rev-parse origin/{branch} to get the remote HEAD (use branch from config, or detect with git -C {repo} rev-parse --abbrev-ref HEAD).git -C {repo} pull --ff-only.explorer is set (deployed contract, no local repo)get_program_info scopes.get_program_info scopes to confirm the contract address is in scope.get_report_details.No local validation possible. Analyze using get_report_details, get_program_info, and attachments only. Note "no local code validation" in the recommendation output.
For each (company, program) pair:
list_reports with state=["New", "In review", "Need more info"] and page=1 first.For each report, apply the full single-report triage logic from hackenproof-triage-marketplace:
get_program_info (once per program, cache result).get_report_details to get description, target, version, steps.get_attachments; read relevant ones with fetch_attachment.git -C {repo} log --oneline or git -C {repo} show {commit} to verify the reported commit exists and is in scope.get_program_info scopes list.list_reports search on same component/root cause.
dup-{id} label is already set, fetch the original report with get_report_details and verify the root cause actually matches (don't trust the label blindly).In review / Triaged / New → recommend closing as DuplicateNot applicable / Out of scope / Informative / Spam → recommend the same state as the original, with the same reasoning (the new report fails on the same grounds, not merely because it's a duplicate)get_comments to avoid contradicting prior decisions.Do NOT call change_state, change_severity, add_labels, or add_comment during this step.
Before printing, classify each report into one of two buckets:
Can Be Closed — recommended state is Invalid, Out of scope, Duplicate, Spam, or Informational with no further action needed. Safe to act on without broader team input.
Needs Team Review — any of the following:
Triaged (valid vulnerability)Print a structured report grouped by program:
## Program: {program_slug} ({company_slug})
Source: [repo: {path} — commit {hash} on {branch} — synced/up-to-date/sync failed: {reason}]
| [explorer: {url}]
| [API-only — no local source configured]
Open reports: {count}
---
### 🟢 CAN BE CLOSED ({n} reports)
#### {report_id}: {title}
Recommend: {state} | Severity: {severity}
Labels to add: {labels}
Reason: {one-line rationale}
Comment to post: "{draft comment}"
Confidence: High
---
### 🔴 NEEDS TEAM REVIEW ({n} reports)
#### {report_id}: {title}
Recommend: {state} | Severity: {severity}
Labels to add: {labels}
Why team: {one-line reason it needs review}
Comment to post: "{draft comment}"
Confidence: Medium/Low — {what's unclear or what evidence is missing}
| Report | Program | Current State | Recommended State | Severity | Bucket | Confidence |
|-------------|---------------|---------------|-------------------|----------|-------------------|------------|
| HACK-123 | citrea-sc | New | Invalid | - | Can be closed | High |
| HACK-124 | citrea-sc | New | Triaged | High | Needs team review | Medium |
After printing the full recommendation report, ask:
"Which recommendations should I apply?
apply closeable— apply all 'Can be closed' recommendationsapply all— apply everything including team-review items- List specific report IDs (e.g.
apply HACK-123, HACK-125)none— exit without changes"
change_state, change_severity, add_labels, and add_comment calls using the standard triage tool sequence.change_state, change_severity, add_labels, add_comment).git log or git cat-file.get_program_info results — call it once per program, not once per report.Duplicate if the original was closed as Not applicable, Out of scope, etc.npx claudepluginhub hackenproof-public/skills --plugin hackenproof-bulk-triageTriages HackenProof bug bounty reports: validates scope, commit/version, PoC evidence, duplicates; assigns severity, state, labels, and comments.
Validates and triages Hacktron security findings against source code and optionally a live deployment, distinguishing true/false positives, adjusting severity, and committing fixes or updating states via the Hacktron REST API.
Provides Bugcrowd-specific reporting tactics: VRT category fallback strategy, manual severity override, OOS-clause rebuttal templates, chained-finding cross-references, and target selection for QA-vs-prod programs.