# Splunk Platform > 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. - Skill: `aibot88/splunk-platform` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add aibot88/splunk-platform` - Raw SKILL.md: https://api.skillmd.com/api/skills/aibot88/splunk-platform/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: aibot88 (https://skillmd.com/u/aibot88) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/aibot88/splunk-platform --- # 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: 1. **SPL2 authoring**: writing SPL2 modules, searches, custom functions, custom types, views, or Edge/Ingest pipelines. 2. **External automation**: Python or JS code talks to Splunk over REST/SDK. 3. **Search/discovery**: SPL inspects indexes, metadata, users, apps, and knowledge objects. 4. **App/add-on engineering**: packaged Splunk app, technical add-on, modular input, alert action, setup UI. 5. **Dashboards/UI**: Dashboard Studio JSON, Simple XML, or legacy SplunkJS/Web Framework. 6. **AI integration**: MCP server or other agent-facing tools over Splunk. 7. **Platform administration**: host deployment, upgrades, distributed topology, app rollout. 8. **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.