SPL Forge

Inspiration

SPL Forge started from a pretty simple frustration: Splunk work still has too much manual glue in it.

You can know exactly what you want to find, type out a decent prompt, and still end up doing the annoying part by hand. Fix the query. Check the fields. Realize the sourcetype is wrong. Run it again. Then turn the working search into a dashboard or alert in a separate step.

A lot of AI tools help with the first draft. They do not help enough with the part right after that, which is usually where the time goes.

What it does

SPL Forge is a VS Code extension that takes a plain-English Splunk task and turns it into working SPL. It runs the query against Splunk, checks what came back, repairs common mistakes when it can, and then uses the final query to build a dashboard, an alert draft, and an exportable app package.

The point was to make something that does more than autocomplete a search.

How we built it

We built it in TypeScript on top of the VS Code extension API. The main interface is a webview panel inside VS Code, and we also built a small browser dashboard so we could test the flow outside the editor.

On the Splunk side, the project supports MCP and REST. The generation step uses a Splunk-hosted model, then the app runs the query, inspects the results, checks schema when needed, and tries to repair common problems like wrong fields, bad sourcetypes, missing indexes, or time windows that are too narrow.

We also added artifact generation on top of that loop, so a working query does not just sit there as text. It becomes something you can review and use.

For testing, we used sample auth data and a richer auth_complex dataset with risk scores, MFA outcomes, blocked logins, privileged actions, and service-account activity.

Challenges we ran into

The hardest part was making the product honest.

It is easy to fake a nice AI demo with one generated query and a screenshot. It is harder to run the search for real, deal with empty results, and show the user exactly what went wrong. That is where most of the work ended up.

Splunk environments are messy in very normal ways. Field names drift. Sourcetypes are inconsistent. Time filters hide data you know is there. CSV imports behave differently than you expect. We had to spend real time on the repair loop and on making the panel transparent enough that users can follow what happened.

Getting from a working search to usable artifacts was another challenge. A dashboard, alert draft, and app package all sound simple until you need them to be clean, reviewable, and safe enough for an actual workflow.

What we learned

The big lesson for us was that query generation is the easy part to show off and the least interesting part to rely on.

What actually helps is the full loop: generate, run, inspect, repair, and then package the result into something useful. Once we leaned into that, the project got much more grounded.

We also learned that people trust this kind of tool more when it shows its work. Seeing the query plan, provider output, parsed SPL, repair history, and execution summary in one place makes a big difference.

What's next

Next we want better app packaging, stronger validation for generated imports, and a clearer approval step before alerts get enabled.

We also want to make the agent flow more observable. Right now the system is useful. The next step is making each stage easier to inspect without turning the interface into a wall of logs.

Built With

• esbuild
• eslint
• html
• javascript
• mcp
• node.js
• npm
• splunk
• typescript