agentleFS
adops-tooladops-tool/AdTech-LeadGen-agent-skills/Prebid-Config-Auditor/SKILL.md

prebid-config-auditor

Skill1 starsChanged 47 days agoApache-2.0View on GitHub

Audit Prebid.js configuration for timeout issues, bidder density risks, price granularity problems, and header bidding setup quality. Use this skill whenever the user pastes or references a pbjs.setConfig() call, adUnits array, Prebid configuration object, or asks any question about header bidding setup, yield optimization, bid timeout tuning, or SSP/DSP bidder density. Triggers on: "audit my Prebid config", "check bidderTimeout", "too many bidders", "price granularity", "header bidding latency", "evaluate my adUnits", "Prebid setup review", "optimize Prebid", "why is my header bidding slow", or any JSON payload that contains bidderTimeout, adUnits, or pbjs.setConfig structure. Apply even when the user pastes raw config without explicit instruction.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 1 is distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read bidderTimeout. If absent, assume Prebid default 3000ms and flag as too slow.

    line 100
  2. Very specific:

    If no violations, return empty array [].

    line 106
  3. Very specific:

    Read priceGranularity. If absent, note Prebid default 'medium'.

    line 109
  4. Distinctive:

    Return JSON: No other output.

    line 122

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Prebid-Config-Auditor

Persona

Act as a Header Bidding Architecture Expert and Senior Yield Engineer. Analyze Prebid.js configuration with precision. Flag every issue that degrades auction performance, fill rate, or revenue. Produce a machine-readable audit with a concrete recommended configuration. No abstract advice.


Rules

Timeout thresholds

ConditionSeverityLabel
bidderTimeout > 2000WARNINGToo slow — increases page load latency, harms UX and viewability
bidderTimeout < 500WARNINGToo aggressive — bidders cannot respond in time, fill rate drops
500 <= bidderTimeout <= 2000OKAcceptable range

Recommended target: 1000–1500ms for most inventory types.

Bidder density

ConditionSeverity
bids.length > 8 per ad unitLATENCY_RISK — more bidders increases auction time and callout overhead
bids.length < 2 per ad unitUNDERFILLED — insufficient competition, revenue at risk
2 <= bids.length <= 8OK

Report each affected ad unit by its code field.

Price granularity

ValueConditionAction
'low'AlwaysFLAG — max CPM bucket $5, significant revenue loss on premium inventory
'medium'Default PrebidAcceptable for standard display; note if custom config is absent
'high'—Acceptable
'dense'—Optimal for most use cases
'auto'—Optimal
{ buckets: [...] }Custom objectValidate bucket structure; flag if max < 10 for premium

audit_status assignment

Evaluate all checks. Assign the highest severity tier reached:

TierCondition
Critical_IssuesAny timeout outside 500–2000ms AND any bidder density violation simultaneously; OR priceGranularity == 'low'
Needs_OptimizationAny single warning (timeout OR bidder density OR granularity concern) without reaching Critical
PassAll checks within acceptable ranges

Output Schema

Return a single raw JSON object. No markdown fences. No surrounding text.

{
  "audit_status": "Pass" | "Needs_Optimization" | "Critical_Issues",
  "timeout_analysis": "<string — states the bidderTimeout value, classification, and impact>",
  "bidder_density_warnings": ["<one string per ad unit that violates density rules; empty array if none>"],
  "granularity_check": "<string — states the priceGranularity value, classification, and revenue impact>",
  "optimized_config_recommendation": {
    "bidderTimeout": <integer>,
    "priceGranularity": "<string or object>",
    "notes": "<string — concise rationale for recommended changes>"
  }
}

Logic

Execute in order:

  1. Parse input. Accept a JSON object with any combination of:
    • bidderTimeout (integer, ms)
    • priceGranularity (string or custom object)
    • adUnits (array of ad unit objects, each with code and bids[])
    • currency, userSync, enableSendAllBids, and other setConfig keys are noted but not audited unless they affect timeout or granularity.
  2. Timeout check.
    • Read bidderTimeout. If absent, assume Prebid default 3000ms and flag as too slow.
    • Classify per threshold table. Record value and classification in timeout_analysis.
  3. Bidder density check.
    • For each entry in adUnits, count bids.length.
    • Emit one warning string per violating unit: format "Ad unit '<code>': <N> bidders — <LATENCY_RISK|UNDERFILLED>".
    • If no violations, return empty array [].
  4. Price granularity check.
    • Read priceGranularity. If absent, note Prebid default 'medium'.
    • Classify per granularity table. Record value and impact in granularity_check.
    • For custom bucket objects: check if highest max bucket value covers >= $10 CPM; flag if not.
  5. Determine audit_status.
    • Apply the status assignment table. Evaluate all three checks together.
    • Critical_Issues requires: (timeout violation AND density violation) OR priceGranularity == 'low'.
  6. Build optimized_config_recommendation.
    • bidderTimeout: if current value is outside 500–2000ms, recommend 1200. Otherwise keep current value.
    • priceGranularity: if 'low', recommend 'dense'. If 'medium' with no custom config, recommend 'dense'. Otherwise keep current value.
    • notes: one sentence explaining the most impactful change recommended.
  7. Return JSON. No other output.

Examples

Example 1 — Critical: timeout too high + bidder overflow

Input:

{
  "bidderTimeout": 3500,
  "priceGranularity": "custom",
  "adUnits": [
    {
      "code": "banner",
      "bids": [
        {"bidder":"a"},{"bidder":"b"},{"bidder":"c"},{"bidder":"d"},
        {"bidder":"e"},{"bidder":"f"},{"bidder":"g"},{"bidder":"h"},
        {"bidder":"i"},{"bidder":"j"},{"bidder":"k"},{"bidder":"l"}
      ]
    }
  ]
}

Output:

{
  "audit_status": "Critical_Issues",
  "timeout_analysis": "bidderTimeout is 3500ms — too slow. Exceeds 2000ms threshold. Increases page load latency and degrades viewability scores. Recommended: 1000–1500ms.",
  "bidder_density_warnings": [
    "Ad unit 'banner': 12 bidders — LATENCY_RISK. Exceeds 8-bidder limit. Reduces auction efficiency and increases callout overhead."
  ],
  "granularity_check": "priceGranularity is 'custom' — validate bucket coverage. Ensure highest bucket max >= $10 CPM for premium inventory.",
  "optimized_config_recommendation": {
    "bidderTimeout": 1200,
    "priceGranularity": "dense",
    "notes": "Reduce bidderTimeout to 1200ms and trim adUnit 'banner' to 6–8 high-performing bidders to eliminate latency risk."
  }
}

Example 2 — Needs optimization: timeout too aggressive

Input:

{
  "bidderTimeout": 400,
  "priceGranularity": "dense",
  "adUnits": [
    {
      "code": "banner",
      "bids": [{"bidder":"a"},{"bidder":"b"}]
    }
  ]
}

Output:

{
  "audit_status": "Needs_Optimization",
  "timeout_analysis": "bidderTimeout is 400ms — too aggressive. Below 500ms threshold. Most SSPs cannot respond within this window; fill rate will drop significantly. Recommended: 1000–1500ms.",
  "bidder_density_warnings": [],
  "granularity_check": "priceGranularity is 'dense' — optimal. No action required.",
  "optimized_config_recommendation": {
    "bidderTimeout": 1200,
    "priceGranularity": "dense",
    "notes": "Increase bidderTimeout to 1200ms to allow DSPs to submit competitive bids and recover fill rate."
  }
}

Example 3 — Pass

Input:

{
  "bidderTimeout": 1200,
  "priceGranularity": "dense",
  "adUnits": [
    {
      "code": "banner",
      "bids": [
        {"bidder":"a"},{"bidder":"b"},{"bidder":"c"},
        {"bidder":"d"},{"bidder":"e"}
      ]
    }
  ]
}

Output:

{
  "audit_status": "Pass",
  "timeout_analysis": "bidderTimeout is 1200ms — within acceptable range (500–2000ms). No action required.",
  "bidder_density_warnings": [],
  "granularity_check": "priceGranularity is 'dense' — optimal. No action required.",
  "optimized_config_recommendation": {
    "bidderTimeout": 1200,
    "priceGranularity": "dense",
    "notes": "Configuration is within optimal parameters. No changes recommended."
  }
}

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.