splunk-spl-processing

Author and review Splunk SPL for detection engineering and Enterprise Security correlation searches.

Updated Jun 24, 2026
One-click install
npx skills add https://github.com/opentidehq/skills --skill splunk-spl-processing-opentidehq
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: splunk-spl-processing
Source: https://github.com/opentidehq/skills/tree/main/skills/splunk-spl-processing
Command: npx skills add https://github.com/opentidehq/skills --skill splunk-spl-processing-opentidehq

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Writing production-quality SPL for Splunk Enterprise and Enterprise Security is error-prone: missing index constraints, unbounded time ranges, misuse of join and subsearches, and unverified CIM data model assumptions silently produce slow or empty detections. This Skill encodes the discipline needed to author fast, portable, tunable SPL detections. ## Core Features & Use Cases - SPL authoring discipline: Enforces index/sourcetype/time constraints, streaming-before-transforming command order, tstats with accelerated CIM data models, and TERM()/PREFIX() anchoring for leading wildcards. - ES correlation searches and RBA: Covers scheduled vs real-time searches, throttling, notable and risk event field shaping, and the three-layer macro architecture (source, process, filter) used by ESCU and OpenTide. - Reference catalogues: Ships anti-pattern rejection checklists (AP-S1 to AP-S12), CIM data model field mappings, detection-type patterns (TTP, anomaly, hunting, RBA, baseline), eval/stats function tables, and idioms like beaconing and impossible travel. - Use Case: Translate a KQL hunting hypothesis into a production Splunk correlation search with proper tstats acceleration, Layer 3 filter macros, throttling, and documented risk-score rationale. ## Quick Start Ask the assistant to write a Splunk detection for suspicious encoded PowerShell execution using tstats against the Endpoint.Processes data model with proper time bounds and a filter macro.

Frequently Asked Questions about splunk-spl-processing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a fast Splunk detection query?▼

Lead with index, sourcetype, and earliest/latest time bounds, push filters into the base search, and use tstats against accelerated CIM data models with summariesonly=true instead of stats over raw events. Anchor leading wildcards with TERM() tokens so the tsidx can pre-filter candidates.

When should I use tstats vs stats in Splunk?▼

Use tstats when fields exist in the tsidx or an accelerated CIM data model, since it is 10-100x faster than stats. Use stats only for search-time extracted fields not present in any accelerated model, and always pair tstats on data models with summariesonly=true.

Why does my Splunk tstats query return zero results?▼

Zero results usually mean the data model is not accelerated or the sourcetype is not mapped to the CIM model via a Technology Add-on, not that no threats exist. Verify acceleration in ES Settings, then smoke-test with tstats summariesonly=true count over the last hour.

How do I avoid join and subsearch limits in Splunk SPL?▼

Replace join with lookup, inputlookup, or stats-based correlation across event types in one search. Subsearches silently truncate at 10,000 results and 60 seconds, so use pre-loaded IOC lookups or accelerated data models for correlation at scale.

How do I convert KQL queries to Splunk SPL?▼

Map KQL operators to SPL equivalents: ago() becomes earliest=, summarize becomes stats with bin, extend becomes eval, and parse_json becomes spath. Avoid translating KQL join directly, since SPL join is expensive; prefer lookups or accelerated data models instead.

Why do scheduled Splunk detections miss late-arriving events?▼

Searches bounded only by _time miss events indexed long after generation, such as Windows Event Logs from offline laptops. Pair event-time bounds with _index_earliest and _index_latest so scheduled detections catch late-arriving data.