Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/transilienceai/communitytools/hackeronenpx skills add transilienceai/communitytools --skill hackeronegit clone --depth 1 https://github.com/transilienceai/communitytoolsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/transilienceai/communitytools/hackerone)<a href="https://agentmods.dev/skills/transilienceai/communitytools/hackerone"><img src="https://agentmods.dev/badge/skills/transilienceai/communitytools/hackerone.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00036 | $0.01883 |
| Opus 5 | $0.00018 | $0.00941 |
| Sonnet 5 | $0.00007 | $0.00377 |
| Haiku 4.5 | $0.00004 | $0.00188 |
Grade A, and why
hackerone scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 138 lines — stays where its author put it; the contents beside it link to each section on GitHub.
HackerOne Bug Bounty
Automates: scope parsing → parallel testing per asset → authoritative finding validation → submission reports.
Quick start
- Input: HackerOne program URL or scope CSV.
- Parse scope and program guidelines.
- Spawn one coordinator per eligible asset (parallel).
- Each coordinator runs the standard engagement flow (see
skills/coordination/SKILL.md). - Run the
validate-findingsworkflow per asset (authoritative submission gate). Generate HackerOne reports from the validated set ONLY — never submit a finding that is notVALID/REPAIRED.
Scope CSV format
Expected columns:
identifier— asset URL/domain.asset_type— URL, WILDCARD, API, CIDR.eligible_for_submission— must betrue.max_severity— critical / high / medium / low.instruction— asset-specific notes.
Parse with skills/hackerone/tools/csv_parser.py. Filter for eligible_for_submission=true.
Agent deployment
One coordinator per asset, spawned in parallel:
coordinator_role = Read("skills/coordination/SKILL.md")
Agent(prompt=f"{coordinator_role}\n\nTARGET: {asset_url}\nSCOPE: {program_guidelines}\nOUTPUT_DIR: ...",
run_in_background=True)
10 assets → 10 parallel coordinators (~2-4 h vs 20-40 h sequential). Each coordinator follows skills/coordination/SKILL.md and reference/role-matrix.md.
Finding validation (authoritative submission gate)
Every finding requires poc.py (executable exploit), poc_output.txt (timestamped execution proof), manual repro steps, and evidence (screenshots / HTTP captures / video). This is the input the validator consumes.
After each asset's coordinator returns, the orchestrator runs the validate-findings workflow for that asset and submits ONLY findings it marks VALID or REPAIRED:
v = Workflow(name="validate-findings", args={
"output_dir": asset_output_dir, # the coordinator's OUTPUT_DIR
"target": asset_url,
"business_tier": "revenue", # production/external bug-bounty scope; else "unknown"
"votes": 3, # adversarial refuters per finding (bounty = stricter)
"repair": True, # regenerate broken/absent PoCs so each finding has a runnable evidence script
"strict": True, # one failed gate => REJECTED
})
# v.counts -> {total, valid, repaired, rejected}; v.validated[] / v.rejected[]
# Verdicts at {asset_output_dir}/artifacts/validated/{id}.json (+ false-positives/).
# Asset report at {asset_output_dir}/reports/validation-report.md.
What ships with it
6 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 138 lines · 36 tokens per session scan A 4e2342f8e606
hackerone is a skill published in the GitHub repository transilienceai/communitytools (509 stars, last pushed 1mo ago), licensed MIT. It adds 36 tokens to every session and 1,883 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
pentester-playwright
Phases 1b/3/4 authorized browser automation — SPA recon, multi-role auth, route/API catalog, PoC screenshots, Evidence landing (scoped proxy). Skill-gate read for web phases. Use when Phase 1b/3/4 web work, JS-rendered SPA, real browser needed, HAR/network capture, or Playwright PoC evidence.
osint-recon
Phase 1 conditional OSINT depth — four-dimension model (server→site→domain→people; people is conditional). Skill-gate companion to pentester-enum-services / pentester-recon. Use for passive OSINT depth, full recon dimensions, author tracking, not as Phase 0/Schema replacement.
pentester-exploit
Phase 4 exploitation — PoC construction, exploit-db/msf search, safe verification. Required Skill-gate read at Phase 4. Use when starting Phase 4, exploitation, exploit, PoC, exploit-db, msf, Metasploit, or payload delivery.
pentester-recon
Phase 1 intelligence recon methodology — passive+active recon, stack fingerprint, attack-surface map. Required Skill-gate read at Phase 1 (with pentester-enum-services). Use when starting Phase 1, intelligence gathering, recon, reconnaissance, OSINT prep, target profiling, or attack surface mapping.
pentester-toolkit
Provision the pinned pentest toolset via DotSlash for the current scanenv (host-kali or kali-target-${ID}). Adapter, not a tool wrapper.
pentester-waf-bypass
Phase 4 conditional — WAF/filter bypass for authorized CTF/range/pentest when payloads are blocked. Use at Phase 4 if blocked, or when user mentions WAF bypass, filter evasion, SQL/XSS/command-injection bypass, or security filter analysis.