An AI skill is a structured system prompt or set of custom instructions that gives AI assistants like ChatGPT, Claude, and Gemini specialized capabilities. It includes a clear role definition, specific knowledge areas, step-by-step processes, and quality criteria that help AI perform specific professional tasks.

How does Skill This work?

Simply describe your professional expertise in plain text. Our free AI skill generator analyzes your input and transforms it into a structured system prompt. The skill is then graded on clarity, specificity, and usefulness. You can share your skill via a unique URL or copy it to use as custom instructions with any AI assistant like ChatGPT, Claude, or Gemini.

Is Skill This free to use?

Yes, Skill This is completely free. No account or payment is required. You can create unlimited skills and share them with anyone.

How is my skill graded?

Skills are graded on a scale from A+ to F (0-100 points). The grade reflects how clear, specific, and actionable your skill is. Higher grades indicate skills that AI assistants can use more effectively.

How do I use my skill with an AI assistant?

Copy your generated skill and paste it into the system prompt or custom instructions of any AI assistant. For ChatGPT, use Personalization > Custom Instructions. For Claude, add it to a Project's instructions. For Cursor or other IDEs, save it as a .cursorrules or CLAUDE.md file. The AI will then adopt that skill and perform tasks according to your expertise.

AI Skill Report Card

Hunting Bug Bounties

A89·Aug 14, 2026·Source: Web

Markdown
---
name: hunting-bug-bounties
description: Guides end-to-end bug bounty methodology from reconnaissance through vulnerability testing, PoC creation, and responsible disclosure reporting. Use when scoping a target for security testing, hunting for vulnerabilities like IDOR/XSS/SQLi/broken access control/business logic flaws, or writing a bug bounty report for HackerOne/Bugcrowd/Intigriti submission.
---

Quick Start15 / 15

Given a target program, run this pipeline:

Bash
# 1. Subdomain enumeration
subfinder -d target.com -all -o subs.txt
amass enum -passive -d target.com >> subs.txt
sort -u subs.txt -o subs.txt

# 2. Alive hosts + tech fingerprint
httpx -l subs.txt -tech-detect -status-code -title -o alive.txt

# 3. Endpoint/URL discovery
katana -list alive.txt -jc -o urls.txt
gau target.com >> urls.txt

# 4. Screenshot triage for quick visual recon
gowitness file -f alive.txt

# 5. Nuclei sweep for known CVEs/misconfigs
nuclei -l alive.txt -t cves/ -t misconfiguration/ -o nuclei-findings.txt

Then manually pivot into Burp Suite for logic testing on high-value endpoints (auth, payments, admin, file upload, API).

Recommendation▾

Add a third example covering a negative/failed scenario (e.g., a report rejected as duplicate) to illustrate contrast between good and bad outcomes

Workflow14 / 15

Progress:

Step 1: Confirm scope & Rules of Engagement (RoE)
Step 2: Reconnaissance (assets, subdomains, tech stack)
Step 3: Attack surface mapping (endpoints, params, auth flows)
Step 4: Vulnerability testing (manual + automated)
Step 5: Build PoC and confirm impact safely
Step 6: Write report and submit
Step 7: Handle triage follow-ups, track disclosure

Step 1: Scope & RoE

Read the program brief in full before touching anything. Note in-scope domains/apps, explicitly out-of-scope assets, disallowed techniques (e.g., no DoS, no automated scanners at volume, no social engineering).
Save scope to a local file (scope.txt) and grep every future target against it before testing.

Step 2: Reconnaissance

Subdomain discovery: subfinder, amass, crt.sh certificate transparency, GitHub dorking for leaked subdomains.
Port/service discovery: naabu or masscan for open ports on in-scope IP ranges only.
Tech fingerprinting: httpx -tech-detect, Wappalyzer, response headers (Server, X-Powered-By), JS bundle analysis for framework versions.
Cross-reference discovered versions against known CVEs (searchsploit, nvd.nist.gov).

Step 3: Attack Surface Mapping

Crawl with katana/gau/waybackurls to enumerate historical and live endpoints.
Identify parameterized URLs, API routes (/api/v1/...), file upload forms, auth flows (login/register/password-reset/OAuth), and admin panels.
Diff endpoints across user roles (unauthenticated, low-priv, high-priv) using multiple Burp sessions/cookies — this is essential for access control testing.

Step 4: Vulnerability Testing

Work through these categories systematically per endpoint; don't just run a scanner and stop.

Category	Test Approach
IDOR	Swap numeric/UUID IDs in requests between two test accounts; check if Account A can read/write Account B's resource
Injection (SQLi/XSS/SSTI/Command)	Fuzz every input (params, headers, JSON body, file names) with payload sets; use `sqlmap` for confirmation, never for blind mass exploitation
Broken Access Control	Replay high-priv actions (e.g., admin API calls) using low-priv/no-auth session tokens; check HTTP verb tampering (GET→POST/PUT/DELETE)
Business Logic	Manually walk multi-step flows (checkout, coupon application, referral, rate limits) looking for state you can skip, replay, or manipulate (e.g., negative quantities, price param tampering, race conditions via repeater/turbo intruder)
Auth/Session	Test JWT alg confusion, token reuse across accounts, password reset token predictability/leakage, MFA bypass paths
SSRF	Test any endpoint accepting a URL/webhook (image fetch, PDF export, webhook config) against internal IP ranges/metadata endpoints

Use Burp Suite Repeater for manual manipulation, Intruder/Turbo Intruder for race conditions, and Autorize extension for automated access-control diffing.
Always test with the least destructive payload first (e.g., ' OR '1'='1 before a stacked query dump).

Step 5: PoC Construction

Reproduce the bug in a clean, minimal, numbered sequence — remove noise from your testing session.
Confirm impact without causing damage: for SQLi, prove data extraction on a single non-destructive row, not a full dump; for IDOR, access one benign record, not mass-scrape; for RCE, run id/whoami, never destructive commands.
Capture: request/response pairs (redacted of sensitive third-party data), screenshots/video, and exact reproduction steps a triager with zero context can follow.

Step 6: Report Writing

Use this structure every time:

Markdown
undefined

Recommendation▾

Include a brief note on tool installation/prerequisites or link references for less common tools like Turbo Intruder and Autorize

Title

[Vulnerability class] in [specific endpoint/feature] leads to [impact]

Summary

One paragraph: what it is, where, why it matters.

Severity

CVSS vector + score, or program's own severity rubric

Steps to Reproduce

Proof of Concept

[Request/response, script, or video link]

Impact

Concrete business impact (data exposure scope, account takeover reach, financial impact) — avoid generic "this is bad" language.

Remediation

Specific fix (e.g., "enforce server-side ownership check on resource_id before returning object")

References

CWE ID, OWASP category, relevant docs


### Step 7: Triage & Disclosure
- Respond to triager questions within 24-48h with additional evidence — don't let reports go stale.
- Never publicly disclose (blog, Twitter, conference talk) until the program explicitly grants disclosure permission or the disclosure window in the RoE has passed.
- If a report is marked duplicate/informative and you disagree, provide additional impact evidence once — don't argue in a loop.

Examples17 / 20

Example 1: Input: Target is app.example.com, an e-commerce platform. Recon shows /api/v2/orders/{order_id} returns order details. Output:

Tested IDOR: created Account A (order_id=1042) and Account B (order_id=1043).
Using Account B's session token, requested GET /api/v2/orders/1042 → 200 OK,
returned Account A's full name, address, and last 4 card digits.
Severity: High (CVSS 7.5) — unauthorized PII/financial data disclosure via IDOR.
Remediation: validate order_id belongs to authenticated user's account_id server-side.

Example 2: Input: Checkout flow allows applying a coupon code client-side before final price calculation. Output:

Business logic flaw: intercepted POST /api/cart/apply-coupon, discovered discount
percentage passed in request body (discount_pct=10) rather than looked up server-side.
Modified to discount_pct=100 → order total became $0.00, order placed successfully.
Severity: Critical — direct financial loss, full price bypass.
Remediation: calculate discount server-side from coupon code lookup table only; never trust client-supplied discount values.

Recommendation▾

Consider adding a short section on severity scoring rubric (CVSS calculation walkthrough) since severity assignment is referenced but not detailed

Best Practices

Always re-verify scope before testing a newly discovered subdomain — subdomain takeovers on out-of-scope assets are a common accidental RoE violation.
Prefer non-destructive PoCs; programs penalize (or ban) researchers who cause downtime or data loss.
Keep a private, timestamped research log (tool output, requests sent) — protects you if origin/duplicate disputes arise.
Chain low-severity bugs (e.g., info disclosure + IDOR + missing rate limit) into a higher-impact narrative when reporting — triagers reward realistic attack chains.
Check program history/Hall of Fame for previously reported bug classes to avoid wasting time on likely duplicates.
Rotate between manual testing and automation — scanners find low-hanging fruit, but the highest-paying bugs are almost always business logic issues found manually.

Common Pitfalls

Testing out-of-scope assets or using disallowed tools (e.g., automated scanners against explicit anti-DoS clauses) — leads to program bans.
Submitting reports without a working reproduction — triagers close these as "unable to reproduce" or "informative."
Over-exploiting to "prove severity" (mass data dumps, deleting records) — turns a valid finding into a policy violation.
Vague impact statements ("this could be bad") instead of concrete business consequences — leads to severity downgrades and lower payouts.
Publicly disclosing before receiving explicit permission — breaches RoE and can result in legal consequences and platform bans.
Ignoring rate limits/CAPTCHA bypass attempts that cross into disruptive load testing without prior written permission.