Splunk Platform
Use this as the default skill for Splunk work. It should answer most Splunk
framework-selection questions directly and send you to exactly one or two
reference files for implementation details.
Read only the references that match the task:
references/spl2-authoring.md for writing SPL2 modules, searches, custom functions, types, views, and pipelines
references/python-sdk.md for Python automation, splunklib, and result parsing
references/javascript-sdk.md for Node/browser JS SDK work
references/rest-search-patterns.md for raw REST, search jobs, and export patterns
references/itsi-implementation.md for concrete ITSI entity integrations, HEC setup, service onboarding, correlation searches, and notable-event aggregation workflows
references/itsi-av-example.md for a concrete end-to-end ITSI onboarding pattern using entity imports, service templates, and template-linked service imports
references/admin-searches.md for read-only admin/discovery SPL
references/ucc-framework.md for add-ons, modular inputs, setup pages, and alert actions
references/dashboard-development.md for Dashboard Studio and Simple XML (framework selection)
references/dashboard-studio-v2-json.md for Dashboard Studio v2 JSON definition syntax (tokens, tabs, drilldowns, inputs, conditional formatting, chain searches, event handlers)
references/mcp-integration.md for agent-facing Splunk tool design
references/platform-admin.md for install/upgrade/deployment automation
references/app-packaging.md for AppInspect, packaging, and release hygiene
Start Here
Classify the task before you write code:
- SPL2 authoring: writing SPL2 modules, searches, custom functions, custom types, views, or Edge/Ingest pipelines.
- External automation: Python or JS code talks to Splunk over REST/SDK.
- Search/discovery: SPL inspects indexes, metadata, users, apps, and knowledge objects.
- App/add-on engineering: packaged Splunk app, technical add-on, modular input, alert action, setup UI.
- Dashboards/UI: Dashboard Studio JSON, Simple XML, or legacy SplunkJS/Web Framework.
- AI integration: MCP server or other agent-facing tools over Splunk.
- Platform administration: host deployment, upgrades, distributed topology, app rollout.
- ITSI implementation: entities, services, KPI base searches, service templates, maintenance windows, or notable event aggregation policies.
If the task spans multiple areas, pick the primary deliverable first. A script
that queries Splunk is external automation, not an add-on.
If the user asks whether a Splunk analysis plan "maps to best practices", asks
for "Tier 0" or "Tier 1", or wants to normalize an analytics repo around
Splunk-backed exploration, answer from the perspective of a full analysis
workflow, not just Splunk infrastructure.
Strong Defaults
- Prefer Python for automation, exports, CLIs, notebooks, and agent backends.
- Prefer JavaScript SDK only when the surrounding system is already Node/JS or you are in Splunk web-facing code.
- Prefer raw REST when you need streaming export semantics, exact endpoint control, or unsupported SDK behavior.
- Prefer UCC for new technical add-ons. Do not hand-roll setup pages and REST handlers unless you are maintaining an existing non-UCC app.
- Prefer Dashboard Studio for new dashboards.
- Prefer Simple XML only for legacy maintenance or when existing app behavior is tightly coupled to XML/tokens.
- Prefer read-only SPL for discovery and audits.
- Prefer ITSI import/search workflows for bulk entity or service creation before inventing unsupported direct KV-store writes.
- Prefer narrow MCP tools over one generic "run any SPL" endpoint.
- Prefer official automation repos for platform deployment before inventing custom shell glue.
- Run AppInspect/package validation before claiming an app or add-on is shippable.
What Not To Use
- Do not build a Splunk app when the real need is an external export script.
- Do not use browser-side JS SDK code to hold long-lived credentials unless there is no server-side alternative.
- Do not default to
oneshot for large searches.
- Do not expose unrestricted search execution to LLMs.
- Do not create new HTML dashboards or lean on deprecated web framework patterns for greenfield work.
- Do not use write-side SPL commands in automation unless the user explicitly wants state changes.
- Do not assume Splunk Cloud lets you use every REST/admin path that Splunk Enterprise does.
- Do not write directly to ITSI KV store collections; use ITSI REST endpoints or supported import workflows.
Decision Table
Need to write SPL2 searches, modules, custom functions, types, or pipelines?
Use spl2-authoring.md.
Default: SPL2 for new search work on Splunk 10.2+. Use from command with SQL-style
clauses for new searches. Use the module editor for multi-statement work. Use custom
functions and types when building reusable SPL2 resources. Use pipeline patterns for
Edge/Ingest Processor work.
Need data out of Splunk for analysis, ETL, or a CLI?
Use python-sdk.md and rest-search-patterns.md.
Default: Python SDK for auth/job lifecycle, raw REST export for large streaming result sets.
Need to inspect a Splunk instance, inventory objects, or audit config?
Use admin-searches.md.
Default: rest, metadata, and tstats. Avoid raw event scans unless you need event content.
Need to create or update ITSI objects like entities, services, KPI base searches, or event aggregation policies?
Use itsi-implementation.md with either python-sdk.md or rest-search-patterns.md.
Default: prefer supported ITSI import or REST object workflows, not direct KV-store writes. For recurring service/entity onboarding, bias toward saved searches plus itsiimportobjects. For event aggregation, define filtering and split-by rules deliberately and keep episode logic explicit.
Need a Splunk add-on with config UI, modular inputs, or alert actions?
Use ucc-framework.md and likely app-packaging.md.
Default: UCC. Treat packaging/AppInspect as part of the implementation, not postscript.
Need a dashboard or dashboard migration?
Use dashboard-development.md.
Default: Dashboard Studio for new work; Simple XML for edits inside an existing XML-heavy app.
Need an MCP server or AI-safe integration?
Use mcp-integration.md plus either python-sdk.md or rest-search-patterns.md.
Default: server-side credentials, read-only-by-default tools, validated SPL.
Need to install, upgrade, or automate Splunk infrastructure?
Use platform-admin.md.
Default: official Splunk automation repos and admin manual concepts, not bespoke scripts first.
Search Execution Defaults
- Add explicit time bounds.
- Add explicit limits or paging.
- Use
search/jobs for managed jobs.
- Use export endpoints when you need streaming output and do not need a persistent SID.
- Use SDK job abstractions for moderate searches where polling and result paging are acceptable.
- Keep query construction separate from result handling.
Enterprise Vs Cloud
- Splunk Enterprise gives broader host/admin access.
- Splunk Cloud often constrains platform-level operations and may require Support enablement for specific REST/API capabilities.
- For app/add-on guidance, always check whether the task is Cloud-safe before recommending local filesystem or admin-server assumptions.
- For ITSI specifically, Enterprise-only filesystem steps like editing
authorize.conf or metadata/local.meta do not translate directly to Splunk Cloud; prefer Splunk Web and documented Cloud-safe admin flows there.
Knowledge Object Defaults
Treat these as first-class assets:
- saved searches and alerts
- dashboards/views
- macros
- lookups
- field extractions and props/transforms-driven behavior
- data models
- KV store collections
For inventory and audits, start with admin-searches.md. For packaging and app
delivery, include those objects intentionally in the app structure and validate
them with app-packaging.md.
Safe Patterns
- Keep auth in env vars or approved secret stores.
- Separate read paths from write paths in code and tool design.
- Scope namespaces deliberately when using REST or SDK config/object APIs.
- Return structured output from automation and MCP tools.
- When in doubt, choose the path that is easiest to reason about operationally:
Python script > custom REST endpoint > full Splunk app.
Replaces
This skill subsumes the old:
splunk-sdk
splunk-quick-searches
Keep the shims for backward compatibility, but maintain real guidance here.
1---2name: splunk-platform3description: Deep skill for Splunk development, administration, SDK/REST integrations, dashboards, UCC add-ons, ITSI automation, SPL2 authoring, and AI-facing tooling. Use for Splunk SDK, REST, jobs/export, SPL, dashboards, packaging, and MCP-backed analysis workflows.4---5
6# Splunk Platform
7
8Use this as the default skill for Splunk work. It should answer most Splunk
9framework-selection questions directly and send you to exactly one or two
10reference files for implementation details.
11
12Read only the references that match the task:
13
14- `references/spl2-authoring.md` for writing SPL2 modules, searches, custom functions, types, views, and pipelines
15- `references/python-sdk.md` for Python automation, `splunklib`, and result parsing
16- `references/javascript-sdk.md` for Node/browser JS SDK work
17- `references/rest-search-patterns.md` for raw REST, search jobs, and export patterns
18- `references/itsi-implementation.md` for concrete ITSI entity integrations, HEC setup, service onboarding, correlation searches, and notable-event aggregation workflows
19- `references/itsi-av-example.md` for a concrete end-to-end ITSI onboarding pattern using entity imports, service templates, and template-linked service imports
20- `references/admin-searches.md` for read-only admin/discovery SPL
21- `references/ucc-framework.md` for add-ons, modular inputs, setup pages, and alert actions
22- `references/dashboard-development.md` for Dashboard Studio and Simple XML (framework selection)
23- `references/dashboard-studio-v2-json.md` for Dashboard Studio v2 JSON definition syntax (tokens, tabs, drilldowns, inputs, conditional formatting, chain searches, event handlers)
24- `references/mcp-integration.md` for agent-facing Splunk tool design
25- `references/platform-admin.md` for install/upgrade/deployment automation
26- `references/app-packaging.md` for AppInspect, packaging, and release hygiene
27
28## Start Here
29
30Classify the task before you write code:
31
321. **SPL2 authoring**: writing SPL2 modules, searches, custom functions, custom types, views, or Edge/Ingest pipelines.
332. **External automation**: Python or JS code talks to Splunk over REST/SDK.
343. **Search/discovery**: SPL inspects indexes, metadata, users, apps, and knowledge objects.
354. **App/add-on engineering**: packaged Splunk app, technical add-on, modular input, alert action, setup UI.
365. **Dashboards/UI**: Dashboard Studio JSON, Simple XML, or legacy SplunkJS/Web Framework.
376. **AI integration**: MCP server or other agent-facing tools over Splunk.
387. **Platform administration**: host deployment, upgrades, distributed topology, app rollout.
398. **ITSI implementation**: entities, services, KPI base searches, service templates, maintenance windows, or notable event aggregation policies.
40
41If the task spans multiple areas, pick the primary deliverable first. A script
42that queries Splunk is external automation, not an add-on.
43
44If the user asks whether a Splunk analysis plan "maps to best practices", asks
45for "Tier 0" or "Tier 1", or wants to normalize an analytics repo around
46Splunk-backed exploration, answer from the perspective of a full analysis
47workflow, not just Splunk infrastructure.
48
49## Strong Defaults
50
51- Prefer **Python** for automation, exports, CLIs, notebooks, and agent backends.
52- Prefer **JavaScript SDK** only when the surrounding system is already Node/JS or you are in Splunk web-facing code.
53- Prefer **raw REST** when you need streaming export semantics, exact endpoint control, or unsupported SDK behavior.
54- Prefer **UCC** for new technical add-ons. Do not hand-roll setup pages and REST handlers unless you are maintaining an existing non-UCC app.
55- Prefer **Dashboard Studio** for new dashboards.
56- Prefer **Simple XML** only for legacy maintenance or when existing app behavior is tightly coupled to XML/tokens.
57- Prefer **read-only SPL** for discovery and audits.
58- Prefer **ITSI import/search workflows** for bulk entity or service creation before inventing unsupported direct KV-store writes.
59- Prefer **narrow MCP tools** over one generic "run any SPL" endpoint.
60- Prefer **official automation repos** for platform deployment before inventing custom shell glue.
61- Run **AppInspect/package validation** before claiming an app or add-on is shippable.
62
63## What Not To Use
64
65- Do not build a Splunk app when the real need is an external export script.
66- Do not use browser-side JS SDK code to hold long-lived credentials unless there is no server-side alternative.
67- Do not default to `oneshot` for large searches.
68- Do not expose unrestricted search execution to LLMs.
69- Do not create new HTML dashboards or lean on deprecated web framework patterns for greenfield work.
70- Do not use write-side SPL commands in automation unless the user explicitly wants state changes.
71- Do not assume Splunk Cloud lets you use every REST/admin path that Splunk Enterprise does.
72- Do not write directly to ITSI KV store collections; use ITSI REST endpoints or supported import workflows.
73
74## Decision Table
75
76### Need to write SPL2 searches, modules, custom functions, types, or pipelines?
77
78Use `spl2-authoring.md`.
79
80Default: SPL2 for new search work on Splunk 10.2+. Use `from` command with SQL-style
81clauses for new searches. Use the module editor for multi-statement work. Use custom
82functions and types when building reusable SPL2 resources. Use pipeline patterns for
83Edge/Ingest Processor work.
84
85### Need data out of Splunk for analysis, ETL, or a CLI?
86
87Use `python-sdk.md` and `rest-search-patterns.md`.
88
89Default: Python SDK for auth/job lifecycle, raw REST export for large streaming result sets.
90
91### Need to inspect a Splunk instance, inventory objects, or audit config?
92
93Use `admin-searches.md`.
94
95Default: `rest`, `metadata`, and `tstats`. Avoid raw event scans unless you need event content.
96
97### Need to create or update ITSI objects like entities, services, KPI base searches, or event aggregation policies?
98
99Use `itsi-implementation.md` with either `python-sdk.md` or `rest-search-patterns.md`.
100
101Default: prefer supported ITSI import or REST object workflows, not direct KV-store writes. For recurring service/entity onboarding, bias toward saved searches plus `itsiimportobjects`. For event aggregation, define filtering and split-by rules deliberately and keep episode logic explicit.
102
103### Need a Splunk add-on with config UI, modular inputs, or alert actions?
104
105Use `ucc-framework.md` and likely `app-packaging.md`.
106
107Default: UCC. Treat packaging/AppInspect as part of the implementation, not postscript.
108
109### Need a dashboard or dashboard migration?
110
111Use `dashboard-development.md`.
112
113Default: Dashboard Studio for new work; Simple XML for edits inside an existing XML-heavy app.
114
115### Need an MCP server or AI-safe integration?
116
117Use `mcp-integration.md` plus either `python-sdk.md` or `rest-search-patterns.md`.
118
119Default: server-side credentials, read-only-by-default tools, validated SPL.
120
121### Need to install, upgrade, or automate Splunk infrastructure?
122
123Use `platform-admin.md`.
124
125Default: official Splunk automation repos and admin manual concepts, not bespoke scripts first.
126
127## Search Execution Defaults
128
129- Add explicit time bounds.
130- Add explicit limits or paging.
131- Use `search/jobs` for managed jobs.
132- Use export endpoints when you need streaming output and do not need a persistent SID.
133- Use SDK job abstractions for moderate searches where polling and result paging are acceptable.
134- Keep query construction separate from result handling.
135
136## Enterprise Vs Cloud
137
138- Splunk Enterprise gives broader host/admin access.
139- Splunk Cloud often constrains platform-level operations and may require Support enablement for specific REST/API capabilities.
140- For app/add-on guidance, always check whether the task is Cloud-safe before recommending local filesystem or admin-server assumptions.
141- For ITSI specifically, Enterprise-only filesystem steps like editing `authorize.conf` or `metadata/local.meta` do not translate directly to Splunk Cloud; prefer Splunk Web and documented Cloud-safe admin flows there.
142
143## Knowledge Object Defaults
144
145Treat these as first-class assets:
146
147- saved searches and alerts
148- dashboards/views
149- macros
150- lookups
151- field extractions and props/transforms-driven behavior
152- data models
153- KV store collections
154
155For inventory and audits, start with `admin-searches.md`. For packaging and app
156delivery, include those objects intentionally in the app structure and validate
157them with `app-packaging.md`.
158
159## Safe Patterns
160
161- Keep auth in env vars or approved secret stores.
162- Separate read paths from write paths in code and tool design.
163- Scope namespaces deliberately when using REST or SDK config/object APIs.
164- Return structured output from automation and MCP tools.
165- When in doubt, choose the path that is easiest to reason about operationally:
166 Python script > custom REST endpoint > full Splunk app.
167
168## Replaces
169
170This skill subsumes the old:
171
172- `splunk-sdk`
173- `splunk-quick-searches`
174
175Keep the shims for backward compatibility, but maintain real guidance here.