agentsclimarketplace

Triage responder

Skill amansingh909/claude-bounty-skills/skills/triage-responder

Claude Code skills for bug bounty hunting and security-auditing web apps you own — recon, scope, report, triage, self-audit. Judgment, not tool wrappers.

Install
npx -y skills add amansingh909/claude-bounty-skills --skill triage-responder

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 29 days oldThe repository was created 29 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when a submitted bug bounty report gets pushback and you need to draft a reply — statuses like Needs More Info, Informative, Not Applicable (N/A), Duplicate, or a request to demonstrate more impact. Symptoms: "program said needs more info", "they marked it informative", "closed as N/A", "how do I respond to triage", "disputing a duplicate", "they want more impact".

SKILL.md

4.7 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it

triage-responder

Overview

A submitted report isn't the end — most get a response before any bounty, and a weak or emotional reply kills reports that were actually valid. This skill drafts a professional, persuasive reply to a triager's pushback: persistent without being rude, sharpening the argument without overstating it.

Core principle: You are trying to help a triager reach the right decision, not to win an argument. Answer what they actually asked, add only substance you can back up, and keep it short and respectful. Assume good faith.

When to Use

  • A report was marked Needs More Info, Informative, N/A, Duplicate, or the program asked you to show more impact.
  • The user wants to respond to a triager and isn't sure how to frame it.

When NOT to use: for writing the original report (that's report-writer).

Anti-Hallucination Rule (Critical)

Respond only from what the user actually observed and can substantiate. Do not:

  • Invent new technical claims, new impact, or evidence the user didn't gather.
  • Assert the report was accepted/paid, or that policy says something, unless the user provided that.
  • Claim you tested a chained/escalated attack you only theorized.

If a stronger response would need evidence the user doesn't have, say so and tell them what to go collect — don't fabricate it into the reply. If the triager is correct and the finding genuinely doesn't hold up, say that plainly and advise accepting the decision. A bounty is never worth a false claim.

Inputs — Ask If Missing

  1. The original finding (or its key facts: bug, asset, impact).
  2. The triager's message and the status they set.
  3. What the user can actually substantiate beyond the original report.

Response Playbook

Match the reply to the status:

StatusThe move
Needs More InfoAnswer exactly what was asked, concisely. Supply the missing repro step, request/response, or PoC. Don't re-explain what they already have.
Informative ("no/low security impact")Only push back if you have a concrete attack scenario showing real impact. Spell out who is harmed and how. If you don't have one, accept it gracefully.
N/A / Not ApplicablePoint to the specific behavior that makes it a genuine security issue, factually. If it hinges on a misread detail, clarify that detail.
DuplicatePolitely ask for the reference, or note a concrete difference if the finding is genuinely distinct (different endpoint, different root cause). Never accuse the program of hiding it.
Show more impactProvide a realistic escalation grounded in what's already demonstrated — chaining, enumeration scale, affected users. No hypotheticals you can't support.

Tone Rules

  • Professional and concise — a few tight sentences, not a wall of text.
  • No entitlement, no threats, no "I'll post this publicly / on Twitter."
  • Persistent but respectful; you can disagree without being combative.
  • Lead with the substance (the fact or evidence), not with the disagreement.

Output

Produce a ready-to-send reply. Below it, add one line noting any evidence the user should attach (screenshot, second request, log) to make the reply land.

Common Mistakes

  • Arguing severity emotionally ("this is clearly critical!!") instead of showing impact. Show, don't insist.
  • Overclaiming to win. Inflating impact to reverse a decision destroys credibility and can get you penalized. Claim exactly what you can prove.
  • Walls of text. Triagers handle many reports; respect their time.
  • Re-litigating settled points. Address the current objection, not the whole history.
  • Being combative. The triager is a person doing a job; treat them as an ally in getting to the right call.

Continuity (session log)

If a local engagement log for this report's program exists (notes/<program>.md in your working directory — gitignored, one file per program), read it first for the original finding and any earlier exchange, then append the triager's status and the reply you drafted. Only read a log that's actually present — never invent past correspondence.

Ethics

Never misrepresent what was tested or observed to change a decision. If the finding doesn't hold up, the honest move is to accept the status and move on.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.