web-scraping
This skill activates for web scraping and Actor development. It proactively discovers APIs via traffic interception, recommends optimal strategy (traffic interception/sitemap/API/DOM scraping/hybrid), and implements iteratively. For production, it guides TypeScript Actor creation via Apify CLI.
By yfe404 · 391 installs
npx skills add yfe404/web-scraper --skill web-scraping
Source repository · Upstream listing
Web Scraping with Intelligent Strategy Selection
When This Skill Activates
Activate automatically when user requests:
"Scrape [website]"
"Extract data from [site]"
"Get product information from [URL]"
"Find all links/pages on [site]"
"I'm getting blocked" or "Getting 403 errors" (loads strategies/anti blocking.md )
"Make this an Apify Actor" (loads apify/ subdirectory)
"Productionize this scraper"
Input Parsing
Determine reconnaissance depth from user request:
User Says Mode Phases Run
"quick recon", "just check", "what framework" Quick Phase 0 only
"scrape X", "extract data from X" (default) Standard Phases 0 3 + 5, Phase 4 only if protection signals detected
"full recon", "deep scan", "production scraping" Full All phases (0 5) including protection testing
Default is Standard mode. Escalate to Full if protection signals appear during any phase.
Adaptive Reconnaissance Workflow
This skill uses an adaptive phased workflow with quality gates. Each gate asks "Do I have enough?" — continue only when the answer is no.
See : strategies/framework signatures.md for framework detection tables referenced throughout.
Phase 0: QUICK ASSESSMENT (curl, no browser)
Gather maximum intelligence with minimum cost — a single HTTP request.
Step 0a: Fetch raw HTML and headers
Step 0b: Check response headers
Match headers against strategies/framework signatures.md → Response Header Signatures table
Note Server , X Powered By , X Shopify Stage , Set Cookie (protection markers)
Check HTTP status code (200 = accessible, 403 = protected, 3xx = redirects)
Step 0c: Check Known Major Sites table
Match domain against strategies/framework signatures.md → Known Major Sites
If matched: use the specified data strategy, skip generic pattern scanning
Step 0d: Detect framework from HTML
Search raw HTML for signatures in strategies/framework signatures.md → HTML Signatures table
Look for NEXT DATA , NUXT , ld+json , /wp content/ , data reactroot
Step 0e: Search for target data points
For each data point the user wants: search raw HTML for that content
Track which data points are found vs missing
Check for sitemaps: curl s https://[site]/robots.txt grep i Sitemap
Step 0f: Note protection signals
403/503 status, Cloudflare challenge HTML, CAPTCHA elements, cf ray header
Record for Phase 4 decision
See : strategies/cheerio vs browser test.md for the Cheerio viability assessment
QUALITY GATE A : All target data points found in raw HTML + no protection signals?
→ YES: Skip to Phase 3 (Validate Findings). No browser needed.
→ NO: Continue to Phase 1.
Phase 1: BROWSER RECONNAISSANCE (only if Phase 0 needs it)
Launch browser only for data points missing from raw HTML or when JavaScript rendering is required.
Step 1a: Initialize browser session
proxy start() → Start traffic interception proxy
interceptor chrome launch(url, stealthMode: true) → Launch Chrome with anti detection
interceptor chrome devtools attach(target id) → Attach DevTools bridge
interceptor chrome devtools screenshot() → Capture visual state
Step 1b: Capture traffic and rendered DOM
proxy list traffic() → Review all traffic from page load
proxy search traffic(query: "application/json") → Find JSON responses
interceptor chrome devtools list network(resource types: ["xhr", "fetch"]) → XHR/fetch calls
interceptor chrome devtools snapshot() → Accessibility tree (rendered DOM)
Step 1c: Search rendered DOM for missing data points
For each data point NOT found in Phase 0: search rendered DOM
Use framework specific search strategy from strategies/framework signatures.md → Framework → Search Strategy table
Only search patterns relevant to the detected framework
Step 1d: Inspect discovered endpoints
proxy get exchange(exchange id) → Full request/response for promising endpoints
Document: method, headers, auth, response structure, pagination
QUALITY GATE B : All target data points now covered (raw HTML + rendered DOM + traffic)?
→ YES: Skip to Phase 3 (Validate Findings). No deep scan needed.
→ NO: Continue to Phase 2 for missing data points only.
Phase 2: DEEP SCAN (only for missing data points)
Targeted investigation for data points not yet found. Only search for what's missing.
Step 2a: Test interactions for missing data
proxy clear traffic() before each action → Isolate API calls
humanizer click(target id, selector) → Trigger dynamic content loads
humanizer scroll(target id, direction, amount) → Trigger lazy loading / infinite scroll
humanizer idle(target id, duration ms) → Wait for delayed content
After each action: proxy list traffic() → Check for new API calls
Step 2b: Sniff APIs (framework aware)
Search only patterns relevant to detected framework:
Next.js → proxy list traffic(url filter: "/ next/data/")
WordPress → proxy list traffic(url filter: "/wp json/")
GraphQL → proxy search traffic(query: "graphql")
Generic → proxy list traffic(url filter: "/api/") + proxy search traffic(query: "application/json")
Skip patterns that don't apply to the detected framework
Step 2c: Test pagination and filtering
Only if pagination data is a missing data point or needed for coverage assessment
proxy clear traffic() → click next page → proxy list traffic(url filter: "page=")
Document pagination type (URL based, API offset, cursor, infinite scroll)
QUALITY GATE C : Enough data points covered for a useful report?
→ YES: Go to Phase 3.
→ NO: Document gaps, go to Phase 3 anyway (report will note missing data in self critique).
Phase 3: VALIDATE FINDINGS
Every claimed extraction method must be verified. A data point is not "found" until the extraction path is specified and tested.
See : strategies/cheerio vs browser test.md for validation methodology
Step 3a: Validate CSS selectors
For each Cheerio/selector based method: confirm the selector matches actual HTML
Test against raw HTML (curl output) or rendered DOM (snapshot)
Confirm selector extracts the correct value, not a different element
Step 3b: Validate JSON paths
For each JSON extraction (e.g., NEXT DATA , API response): confirm the path resolves
Parse the JSON, follow the path, verify it returns the expected data type and value
Step 3c: Validate API endpoints
For each discovered API: replay the request (curl or proxy get exchange )
Confirm: response status 200, expected data structure, correct values
Test pagination if claimed (at least page 1 and page 2)
Step 3d: Downgrade or re investigate failures
If a selector doesn't match: try alternative selectors, or downgrade to PARTIAL confidence
If an API returns 403: note protection requirement, flag for Phase 4
If a JSON path is wrong: re examine the JSON structure, correct the path
Phase 4: PROTECTION TESTING (conditional)
See : strategies/proxy escalation.md for complete skip/run decision logic
Skip Phase 4 when ALL true :
No protection signals detected in Phases 0 2
All data points have validated extraction methods
User didn't request "full recon"
Run Phase 4 when ANY true :
403/challenge page observed during any phase
Known high protection domain
High volume or production intent
User explicitly requested it
If running :
Step 4a: Test raw HTTP access
200 → Cheerio viable, no browser needed for accessible endpoints
403/503 → Escalate to stealth browser
Step 4b: Test with stealth browser (if needed)
Already running from Phase 1 — check if pages loaded without challenges
interceptor chrome devtools list cookies(domain filter: "cloudflare") → Protection cookies
interceptor chrome devtools list storage keys(storage type: "local") → Fingerprint markers
proxy get tls fingerprints() → TLS fingerprint analysis
Step 4c: Test with upstream proxy (if needed)
proxy set upstream("http://user:pass@proxy provider:port")
Re test blocked endpoints through proxy
Document minimum access level for each data point
Step 4d: Document protection profile
What protections exist, what worked to bypass them, what production scrapers will need
Phase 5: REPORT + SELF CRITIQUE
Generate the intelligence report, then critically review it for gaps.
See : reference/report schema.md for complete report format
Step 5a: Generate report
Follow reference/report schema.md schema (Sections 1 6)
Include Validated? status for every strategy (YES / PARTIAL / NO)
Include all discovered endpoints with full specs
Step 5b: Self critique
Write Section 7 (Self Critique) per reference/report schema.md :
Gaps : Data points not found — why, and what would find them
Skipped steps : Which phases skipped, with quality gate reasoning
Unvalidated claims : Anything marked PARTIAL or NO
Assumptions : Things not verified (e.g., "consistent layout across categories")
Staleness risk : Geo dependent prices, A/B layouts, session specific content
Recommendations : Targeted next steps (not "re run everything")
Step 5c: Fix gaps with targeted re investigation
If self critique reveals fixable gaps: go back to the specific phase/step, not a full re run
Example: "Price selector untested" → run one curl + parse, don't re launch browser
Update report with results
Step 5d: Record session (if browser was used)
proxy session start(name) → proxy session stop(session id) → proxy export har(session id, path)
HAR file captures all traffic for replay. See strategies/session workflows.md
IMPLEMENTATION (after reconnaissance)
After reconnaissance report is accepted, implement scraper iteratively.
Core Pattern :
1. Implement recommended approach (minimal code)
2. Test with small batch (5 10 items)
3. Validate data quality
4. Scale to full dataset or fallback
5. Handle blocking if encountered
6. Add robustness (error handling, retries, logging)
See : workflows/implementation.md for complete implementation patterns and code examples
PRODUCTIONIZATION (on request)
Convert scraper to production ready Apify Actor.
Activation triggers : "Make this an Apify Actor", "Productionize this", "Deploy to Apify"
Core Pattern :
1. Confirm TypeScript preference (STRONGLY RECOMMENDED)
2. Initialize with apify create command (CRITICAL)
3. Port scraping logic to Actor format
4. Test locally and deploy
Note : During development, proxy mcp provides reconnaissance and traffic analysis. For production Actors, use Crawlee crawlers (CheerioCrawler/PlaywrightCrawler) on Apify infrastructure.
See : workflows/productionization.md for complete workflow and apify/ for Actor development guides
Quick Reference
Task Pattern/Command Documentation
Reconnaissance Adaptive Phases 0 5 workflows/reconnaissance.md
Framework detection Header + HTML signature matching strategies/framework signatures.md
Cheerio vs Browser Three way test + early exit strategies/cheerio vs browser test.md
Traffic analysis proxy list traffic() + proxy get exchange() strategies/traffic interception.md
Protection testing Conditional escalation strategies/proxy escalation.md
Report format Sections 1 7 with self critique reference/report schema.md
Find sitemaps RobotsFile.find(url) strategies/sitemap discovery.md
Filter sitemap URLs RequestList + regex reference/regex patterns.md
Discover APIs Traffic capture (automatic) strategies/api discovery.md
DOM scraping DevTools bridge + humanizer strategies/dom scraping.md
HTTP scraping CheerioCrawler strategies/cheerio scraping.md
Hybrid approach Sitemap + API strategies/hybrid approaches.md
Handle blocking Stealth mode + upstream proxies strategies/anti blocking.md
Session recording pro