osint-dorking
- Repo stars 1
- License MIT
- Author updated Live
- Author repo agent-toolkit
- Domain
- Engineering
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 94 / 100 · audit passed
- Author / version / license
- @000001000000 · MIT
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- Python
- Permissions
-
- Read-only
- Shell exec
- Env read
- Write / modify
- Network behavior
- External requests
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: osint-dorking
description: Use this skill whenever a user asks for OSINT dorks, Google dorks, GHDB queries, Shodan filters…
category: engineering
runtime: Python
---
# osint-dorking output preview
## PART A: Task fit
- Use case: Use this skill whenever a user asks for OSINT dorks, Google dorks, GHDB queries, Shodan filters, GitHub code search dorks, search operators, or exposed asset discovery. Prioritize this workflow even if the user does not explicitly mention GHDB..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Why this workflow / Examples / Safety and scope rules” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Use this skill whenever a user asks for OSINT dorks, Google dorks, GHDB queries, Shodan filters, GitHub code search dorks, search operators, or exposed asset discovery. Prioritize this workflow even if the user does not explicitly mention GHDB.”.
- **02** When the source has headings, the agent prioritizes “Why this workflow / Examples / Safety and scope rules” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, run shell commands, read environment variables, write/modify files; may access external network resources; usually needs no extra API key.
## Running Rules
- read files, run shell commands, read environment variables, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. Choose the trigger
The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Provide inputs and boundaries
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, run shell commands, read environment variables, write/modify files.
Validate with a small run
Start with a small task and check whether the result follows “Why this workflow / Examples / Safety and scope rules”. Inspect diffs, logs, previews, or tests before expanding scope.
Review before delivery
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: osint-dorking
description: Use this skill whenever a user asks for OSINT dorks, Google dorks, GHDB queries, Shodan filters…
category: engineering
source: 000001000000/agent-toolkit
---
# osint-dorking
## When to use
- Use this skill whenever a user asks for OSINT dorks, Google dorks, GHDB queries, Shodan filters, GitHub code search do…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Why this workflow / Examples / Safety and scope rules” and keep inference separate from source facts.
- read files, run shell commands, read environment variables, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. Evidence boundary and execution chain
The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "osint-dorking" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Why this workflow / Examples / Safety and scope rules
rules -> SKILL.md triggers / order / output contract
runtime -> Python | read files, run shell commands, read environment variables, write/modify files | may access external network resources
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}OSINT Dorking Skill
This skill teaches an agent how to reliably answer OSINT dorking requests. It currently uses GHDB as a robust baseline data source and can be extended with additional dork sources.
Why this workflow
Exploit-DB pages can enforce anti-bot protections and rate limits. Instead of scraping HTML pages, use the official GHDB XML feed from the ExploitDB GitLab repository through the bundled helper script.
Primary data source used by the helper:
Examples
Use these as few-shot references for what strong, practical dorks look like.
- Exposed environment files:
- Dork: inurl:.env OR intitle:"index of" ".env"
- Why useful: helps detect leaked runtime secrets in misconfigured deployments.
- Open directory listings:
- Dork: intitle:"index of" "backup" OR intitle:"index of" "/uploads"
- Why useful: surfaces browseable file indexes that may expose sensitive artifacts.
- WordPress configuration backups:
- Dork: intitle:"index of" "wp-config.php.bak"
- Why useful: identifies accidental backup exposure of database credentials.
- Database dump files:
- Dork: ext:sql "dump" ("db" OR "backup")
- Why useful: finds potentially exposed SQL exports for defensive verification.
- Git metadata exposure:
- Dork: intitle:"index of" ".git"
- Why useful: highlights repositories accidentally exposed via directory listing.
Safety and scope rules
- Only provide dorking guidance for authorized, legal, and defensive use.
- If the user requests clearly unauthorized targeting, refuse and offer benign alternatives (hardening checks, self-audit queries, training/lab examples).
- Prefer least harmful, discovery-focused dorks over intrusive guidance.
- Do not provide step-by-step exploitation instructions.
Procedure
- Clarify intent and constraints.
- Ask what technology, file type, product, or exposure class the user wants to detect.
- If needed, ask whether they want broad discovery or highly specific dorks.
- Query dork data via bundled script.
- Run commands from this skill directory:
skills/osint-dorking. - Run:
- ./scripts/search.sh --keyword "
" --limit 10
- ./scripts/search.sh --keyword "
- Equivalent direct Python entrypoint:
- python3 scripts/search_dorks.py --keyword "
" --limit 10
- python3 scripts/search_dorks.py --keyword "
- For category filters:
- ./scripts/search.sh --keyword "
" --category "Files Containing Juicy Info" --limit 10
- ./scripts/search.sh --keyword "
- For exact reproducibility in machine-readable format:
- ./scripts/search.sh --keyword "
" --format json --limit 20
- ./scripts/search.sh --keyword "
- If results are weak, iterate.
- Try synonyms and related products.
- Switch between broad and narrow terms.
- Use multiple keywords with match-any mode:
- ./scripts/search.sh --keyword "wordpress" --keyword "wp-config" --match any --limit 20
- Respond with curated output.
- Return a concise list including:
- GHDB ID
- Category
- Dork query
- Why it is relevant
- Add a short caution reminding the user to test only systems they own or are authorized to assess.
- If the feed cannot be fetched.
- Retry once with --refresh.
- If network still fails, rely on cached data at data/ghdb.xml.
- Tell the user the data may be stale and provide date context if available.
Output template
Use this structure in responses:
Match 1:
- ID:
- Category:
- Dork:
- Relevance:
- ID:
Match 2:
- ID:
- Category:
- Dork:
- Relevance:
- ID:
Notes for agents
- Preferred entrypoint is ./scripts/search.sh because it handles Python interpreter selection and forwards args safely.
- Prefer running the local script over direct Fetch calls to exploit-db pages.
- Keep answers practical and defensive.
- If the user asks for more, expand with adjacent categories and safer variants.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review