Pi-hole CSV Analyzer
Intent
Analyze Pi-hole CSV exports to identify query patterns, noisy clients, allowlist candidates, blocklist candidates, and cleanup actions.
Use When
- The user explicitly asks for
pihole-csv-analyzer. - The request matches the triggers or workflow described below.
- The task benefits from a reusable, structured output instead of a one-off answer.
Do Not Use When
- Do not use without CSV or equivalent query data, for generic Pi-hole setup, or for changes that cannot be traced to export evidence.
- Required context is missing and cannot be reasonably inferred.
- A more specific skill in this repo is a better match.
Workflow
- Identify the exact task and available source material.
- Apply the domain rules and output format in this skill.
- State assumptions, uncertainty, and missing inputs clearly.
- Return the requested artifact, recommendation, or review in a practical format.
- Check the result against the validation checklist before finishing.
Constraints
- Do not fabricate missing facts, measurements, dates, sources, or user context.
- Keep output aligned with Mick's direct, practical communication style unless the skill says otherwise.
- Preserve safety, legal, medical, financial, and operational boundaries stated in this file.
- Prefer concise, usable output over broad explanation.
Validation Checklist
- The output matches the skill's intended task and platform.
- Required inputs, assumptions, and uncertainty are explicit.
- Safety, scope, and source limits are respected.
- The response follows the requested format or the skill's default output format.
- The result is practical enough to use without another cleanup pass.
Analyze Pi-hole CSV exports and turn them into practical, reviewable cleanup actions.
Supported Inputs
This skill should handle:
- query log exports
- top domains exports
- top clients exports
- blocklist or adlist exports
If the format is ambiguous, inspect the header row and the first few rows before proceeding.
Export Type Detection
Use the CSV header to identify the likely export type.
| Export Type | Typical Columns | Typical Source |
|---|---|---|
| Query Log | time, type, domain, client, status, reply_type, reply_time, dnssec | Pi-hole web UI query log export |
| Top Domains | domain, count or hits | Dashboard top permitted or blocked domains |
| Top Clients | client, count or hits | Dashboard top clients |
| Blocklist or Adlist | address, enabled, comment, group, date_added | Adlist or domain export |
Pi-hole v6 exports can vary slightly. Normalize column names before applying logic.
Query Status Mapping
When analyzing query-log exports, use Pi-hole's documented query-database status meanings.
Common blocked status values:
1blocked by gravity4blocked by regex denylist5blocked by exact denylist6blocked by upstream known blocking IP7blocked by upstream null response8blocked by upstreamNXDOMAINwithRAbit unset9blocked by gravity during deep CNAME inspection10blocked by regex during deep CNAME inspection11blocked by exact denylist during deep CNAME inspection15blocked while the database is busy16blocked special domains18blocked by upstreamEDE 15
Common allowed status values:
2allowed and forwarded3allowed and replied from cache12allowed retried query13allowed retried but ignored query14allowed already forwarded17allowed and replied from stale cache
Treat unknown or new status values carefully and flag them instead of guessing.
Analysis Workflow
1. Normalize the data
- normalize column names to lowercase
- strip extra whitespace
- detect whether status values are numeric or text
2. Compute the high-value summary
For query-log exports, compute:
- total query volume
- blocked versus allowed volume
- top allowed domains
- top blocked domains
- top clients by volume
- unusually noisy clients
- suspicious allowed domains that may deserve review
For top domains or top clients exports, normalize the columns and rank by count.
For blocklist or adlist exports, summarize enabled versus disabled state and obvious cleanup opportunities.
3. Generate review candidates
Blocklist candidates
Flag allowed domains that look suspicious based on signals such as:
- telemetry or tracking patterns
- free-TLD abuse indicators such as
.tk,.cf,.gq,.ml - IP-style subdomain patterns
- long random-looking subdomains
- repeated high-volume domains tied to a single client with no obvious user-facing purpose
Avoid recommending major infrastructure or obviously essential domains without a strong reason. Be conservative.
Allowlist candidates
Flag blocked domains that may be legitimate when they:
- are tied to sign-in, updates, streaming, or other common core functionality
- appear frequently among blocked queries
- clearly belong to major legitimate platforms
4. Output
Always provide an in-chat summary with:
- overview metrics
- top allowed and blocked domains
- top clients
- noisy-client callouts
- suspicious allowed domains
- possible allowlist candidates
- practical next-step recommendations
Also produce reviewable candidate outputs named:
blocklist_candidates.txtallowlist_candidates.txt
If the environment supports file output, create those files. Otherwise, present their contents inline in clearly separated sections.
Reference Logic
Use Pi-hole's documented status values as the source of truth. For example, a basic numeric mapping can start like this:
BLOCKED_STATUSES = {1, 4, 5, 6, 7, 8, 9, 10, 11, 15, 16, 18}
ALLOWED_STATUSES = {2, 3, 12, 13, 14, 17}
When string-style status values appear instead of integers, use cautious text matching and keep uncertainty visible.
Edge Cases
- Empty or malformed CSV files: explain what is wrong and what is expected
- No blocked queries: say so directly
- No suspicious domains: say so directly
- IPv6 clients: display as-is
- Large files: summarize and sample pattern analysis if needed
- Unknown status values: flag them as unknown instead of forcing a blocked or allowed label
Style
- Lead with the most actionable findings
- Keep the output concise and practical
- Do not invent recommendations
- Be explicit when confidence is low
- Treat generated blocklist and allowlist entries as review queues, not final policy
Help And Examples
If the user is not sure how to use this skill, asks what it needs, or asks for examples:
- Explain in plain language what this skill can do.
- Tell the user the minimum input needed for a useful first pass.
- Show the example prompts below.
- Offer the fastest next prompt the user can send.
Minimum useful input:
- A Pi-hole CSV export or a summary of what you want analyzed.
Example prompts:
Use pihole-csv-analyzer to review this Pi-hole export and tell me what cleanup actions make sense.Analyze this Pi-hole CSV and surface the top noisy domains, trends, and practical next steps.Show me an example prompt for using this skill with a pasted CSV summary.