사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/ljagiello/ctf-skills --skill ctf-similar-search시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 Skill 문서
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
CTF Similar Challenge Search
Search for similar CTF challenge writeups using Tavily API.
Prerequisites
bash
pip install requests tavilySet your Tavily API key (from https://tavily.com) before running:
bash
export TAVILY_API_KEY='tvly-...'API Overview
This skill provides two interfaces:
| Interface | Purpose | Command |
|---|---|---|
| Tavily Search | Search for writeups and articles | ./search.sh search <keyword> |
| Tavily Extract | Extract content from URLs | ./search.sh extract <url1> [url2] ... |
Search Workflow
Step 1: Search with Keywords
Choose keywords based on available information:
Scenario 1: Known Competition + Challenge Name
bash
# Format: [Competition Name] [Challenge Name] — max 3 words
./search.sh search "DASCTF URL Storage"
./search.sh search "HGAME baby web"
./search.sh search "BUUCTF pwn1"Scenario 2: Challenge Name Only (no competition info)
bash
# Use challenge name directly — max 3 words
./search.sh search "URL Storage"
./search.sh search "baby overflow"
./search.sh search "crypto-rsa"Scenario 3: Unique Identifiers (code snippets, strings)
bash
# Use unique, non-trivial strings from the challenge — NO word limit
./search.sh search "def encrypt_flag(key): return base64"
./search.sh search "CUSTOM_MAGIC_BYTES"
./search.sh search "ERROR: invalid padding in AES block"⚠️ Critical: 3-Word Limit for Non-Code Queries
All keyword searches that are NOT code snippets or unique identifier strings MUST NOT exceed 3 words. This constraint ensures precise, focused queries that return relevant CTF writeup results instead of broad, diluted searches.
| Search Type | Word Limit | Examples |
|---|---|---|
| Competition + Challenge name | ≤ 3 words | "DASCTF URL Storage", "HGAME baby web" |
| Challenge name only | ≤ 3 words | "URL Storage", "baby overflow" |
| Code snippets / strings | No limit | "def encrypt_flag(key): return base64" |
| Error messages / identifiers | No limit | "CUSTOM_MAGIC_BYTES", "ERROR: invalid padding in AES block" |
For competition + challenge name searches, drop filler words (year numbers, "CTF", "competition", "writeup", "solution") and keep only the 3 most distinctive words:
- ❌
"HGAME 2024 baby web challenge"(5 words) - ✅
"HGAME baby web"(3 words) - ❌
"DASCTF 2023 URL Storage writeup"(5 words) - ✅
"DASCTF URL Storage"(3 words) - ❌
"PlaidCTF 2025 zero day exploit solution"(6 words) - ✅
"PlaidCTF zero day"(3 words)
For code/string searches, use the entire unique snippet — these are exempt from the word limit:
- ✅
"def xor_encrypt(data, key):"(code — exempt) - ✅
"ERROR: invalid padding in AES block"(error string — exempt) - ✅
"CUSTOM_MAGIC_BYTES"(identifier — exempt)
Keyword Rules
| ✅ Good Keywords | ❌ Bad Keywords |
|---|---|
| Competition + Challenge name (≤3 words) | Single vulnerability type (SSRF, XSS) |
| Challenge name (≤3 words) | Generic terms (web, pwn, crypto) |
| Unique code snippets (no word limit) | Full sentences |
| Specific error messages (no word limit) | Articles (a, the, in) |
| Library/framework names | Generic strings (flag{}, etc.) |
| Custom function names | Tool names alone |
Why avoid these?
- "SSRF" → returns generic vulnerability explanations, not CTF writeups
- "flag{" → returns millions of unrelated results
- "URL Storage DASCTF" → returns specific CTF challenges
Why the 3-word limit?
- Forces precision: only the most distinctive keywords survive
- Filters noise: filler words like "challenge", "writeup", "solution" dilute results
- Improves API efficiency: shorter, focused queries consume fewer credits
Key principle: Use keywords that uniquely identify THIS challenge, not the general technique or common patterns. Keep non-code queries to 3 words or fewer.
Step 2: Review Search Results
The search returns:
- Answer: AI-generated summary if available
- Results: List of URLs with titles and content previews
- Credits: API usage information
Step 3: Extract Content (Optional)
If a search result looks promising, extract its full content:
bash
# Single URL
./search.sh extract "https://example.com/writeup"
# Multiple URLs
./search.sh extract "https://url1.com" "https://url2.com"Step 4: Analyze and Pivot
Based on extracted content:
- Identify common techniques used in similar challenges
- Determine if the approach is applicable
- Pivot to category-specific skill if needed
When to Pivot
- If the challenge is already well-categorized, use the specific
ctf-*skill - If you need OSINT techniques, use
ctf-osint - If you need to generate a writeup after solving, use
ctf-writeup
Quick Start
bash
# Scenario 1: Competition + Challenge name (≤3 words)
./search.sh search "DASCTF URL Storage"
# Scenario 2: Challenge name only (≤3 words)
./search.sh search "URL Storage"
# Scenario 3: Unique identifier from challenge (no word limit)
./search.sh search "def xor_encrypt(data, key):"
./search.sh search "ERROR: invalid padding"
# Extract content from promising results
./search.sh extract "https://ctftime.org/writeup/12345"Tips
- Be specific: Use competition name + challenge name when available
- Use unique strings: Code snippets, error messages, unique identifiers
- Avoid generic terms: Don't search "SSRF CTF writeup" - too broad
- Review first: Check search results before extracting
- Extract selectively: Only extract URLs that look relevant
- Respect the 3-word limit: For non-code queries, strip filler words and keep only the 3 most distinctive keywords
$ARGUMENTS
