| TL;DR: The OpenSearch Project’s first hackathon is complete! Over four weeks, participants built agentic skills for search, log analytics, compliance, and operational workloads. A panel of Project maintainers, collaborators, and OpenSearch Ambassadors evaluated submissions across five criteria to select three winners. The winning skills share a common philosophy. They prove their work. They never write to the cluster. They ship with real evaluation. |
When we launched the OpenSearch Agent Skills Hackathon in July, we issued a challenge to the community: build agentic skills that solve real problems for OpenSearch users, skills rigorous enough to ship in the official Project. The hackathon ran from July 15 through August 17, open to U.S. residents working individually or in teams of two. Every submission required working code under the Apache 2.0 license, a clear README, and a five-minute demo video.
Our judging panel, selected from OpenSearch Project maintainers, collaborators, and Ambassadors, evaluated each entry across five weighted dimensions: technical innovation (25%), community creativity and utility (25%), operational excellence (20%), vendor neutrality and portability (15%), and documentation and enablement (15%). The full criteria are published on the hackathon evaluation page.
What stood out across the top submissions was a shared commitment to rigor. The winning entries do not just work; they prove that they work, they make their reasoning transparent, and they respect the boundaries that operators expect in production environments.
First place: Unclosed—log root-cause analysis that audits its own premise
Winner: Ciki Zeng
Github: @simpleciki
Issue: #92
Code: simpleciki/unclosed
Demo video: Watch on YouTube
Anyone who has triaged a latency spike knows the pattern: an agent finds a correlate, reports it as the cause, and moves on. unclosed challenges that workflow by addressing three specific failure modes that make this pattern unreliable: the anomaly itself may be an artifact, the search for a cause may be too narrow, and the resulting explanation may not have been validated against the available evidence. The skill enforces a gate for each:
Premise audit: Before searching for a cause, the skill verifies that the observed anomaly is real. A backfill that shifts @timestamp can look exactly like a latency spike, and an agent that skips this step is chasing an artifact.
Hypothesis tree: Rather than following a single thread and stopping at the first plausible correlate, unclosed explores hypotheses as an explicit tree and records every branch, including the ones it chose not to pursue.
Closure check: A candidate cause that accounts for 8 ms of a 400 ms regression is not an explanation. The skill forces the arithmetic: does this derivation actually close the gap?
The skill never tells the user “the cause of this anomaly is X.” Rather, its deliverable is the traversal record itself, a fully auditable trail that makes the reasoning transparent. It operates read-only against the cluster, primarily uses OpenSearch PPL, and runs on any distribution. The Project ships with a labeled test corpus that includes the case that matters most: when the spike is real but no cause is discoverable.
The judges noted that this skill stood out for performing genuine multi-step root-cause analysis rather than returning a single confident guess. It will not name a cause unless the full chain of evidence closes — a rare discipline for this kind of tool. The testing and operational tooling behind it were the strongest of any submission, and the pull request itself reflected real engineering depth.
Second place: GDPR Forget-Me Agent Skill
Winner: Jeff Zemerick
Github: @jzonthemtn
Issue: #84
Code: philterd/opensearch-agent-skill-right-to-be-forgotten
Demo video: Watch on YouTube
GDPR’s “right to be forgotten” sounds straightforward until you consider the data that keyword scans miss. Under GDPR Recital 26, a person is identifiable whenever they can be recognized by indirect reference. The submitted issue gives as an example “the solo senior frontend engineer on-call during incident #4091 who resigned at the end of March.” No name, no employee ID, but still personal data that must be discoverable and erasable.
The GDPR Forget-Me Agent Skill closes this gap. The skill combines a direct-identifier pass (name, email, phone, IP) with hybrid BM25 plus neural vector search to find records where people are described but never named. It then reasons over each candidate, scores confidence, and extracts the exact identifying snippets to redact.
The safety model reflects the sensitivity of the domain:
Read-only enforcement. Every action is emitted as a reviewable curl script targeting documents by exact (index, _id), never a broad query. The skill never writes to the cluster.
Legal-hold awareness. Any index marked as under legal hold is refused outright.
Hash-chained audit trail. Each run produces an erasure certificate providing the evidence that GDPR Art. 5(2) and Art. 30 require.
Vendor neutrality. The embedding model runs locally inside the cluster via ML Commons, so text never leaves the deployment boundary. The skill falls back to BM25 when no model is available, and runs on any OpenSearch distribution.
The Project ships with a synthetic evaluation corpus and a methodology for building ground truth against the Enron email dataset, including a masking protocol designed so the corpus cannot carry its own answer key.
The judges confirmed that the skill applies rank fusion hybrid search that combines BM25 and k-NN search for optimized document retrieval. Its hash-chained SHA-256 audit trail includes tamper detection, and every file count matched exactly across the library, scripts, and tests. CI was confirmed running on GitHub Actions across Python 3.11 and 3.12, and its legal-hold enforcement was verified working as intended.
Third place: slow-query-doctor—diagnose a slow query, then prove the fix
Winner: Gorav Soni
Github: @goravsoni
Issue: #122
Code: goravsoni/slow-query-doctor
Demo video: Watch on YouTube
Performance troubleshooting advice is easy to find. Verified performance improvements are harder. slow-query-doctor bridges that gap for one of the most common OpenSearch pain points: understanding why a specific search query is slow.
The skill profiles a query using the Profile API, localizes where the time is actually spent — query phase, aggregation, or fetch — and scans the query body for documented latency traps: leading wildcards, script_score scoring, deep from/size pagination, and more. When node-level APIs are available, it also checks for search thread-pool rejections and tripped circuit breakers.
What distinguishes this skill is the verification model. Because running a search query does not change cluster state, the skill runs both the original and the rewritten query, then reports the real before-and-after latency. The improvement is measured, not asserted. Anything that would actually mutate state — eager_global_ordinals, force-merge, replica changes — is prescribed as a runbook for the operator to execute. The skill does not run those itself.
The Project includes an array of unit tests, four live Docker scenarios that seed an index and profile a known-slow query, and 11 LLM-as-judge evaluations covering routing and rule-compliance behavior. It is designed to run on any OpenSearch 1.x+ distribution: self-managed, Docker, Kubernetes, or managed service. It has zero dependencies beyond the Python standard library and curl.
The judges highlighted that this skill earns its place by making a real diagnostic tool out of the OpenSearch Profile API. It does not just flag documented latency traps; it verifies where the time is actually going in the query, and when it proposes a rewrite, it runs both versions and reports real before-and-after timing rather than a guess.
A shared philosophy
A review of the winning entries shows a pattern that says something about where the OpenSearch community is heading with agentic tooling. All three skills:
Prove rather than assert. Each one runs its own verification rather than trusting its first answer.
Never write to the cluster. Every action that would change state is emitted for human review, not executed silently.
Ship with real evaluation. Test corpora, labeled datasets, live scenarios, and LLM-as-judge harnesses — not just unit tests, but evidence of how the skill performs and where it fails.
Run anywhere. Pure OpenSearch APIs, no proprietary dependencies, Apache 2.0 licensed.
These characteristics were not prescribed in the judging criteria, and it’s interesting to see these themes emerge organically from independent teams solving different problems. It shows that the OpenSearch community is bringing a disciplined, thoughtful approach to agentic tooling: prioritizing agents that are accountable, transparent, and designed to be trustworthy for production environments.
What comes next
Selected skills from the hackathon may be contributed to the official OpenSearch Agent Skills repository, giving these projects visibility across the global developer community.
The winners have been invited to present their skills live at OpenSearchCon North America in San Jose, California, September 22–24, 2026.
This was the OpenSearch Project’s first hackathon, and the intention was always to build a repeatable framework. While this event was scoped to U.S. participants, we are eager to develop future events for developers across the world. If you did not participate this time, building agent skills for OpenSearch is an ongoing effort. Start building, join the conversation in our #hackathon Slack channel, try out OpenSearch Agent Skills for yourself, and watch opensearch.org for what comes next.
Congratulations to our winners, and thank you to everyone who submitted, to our judges for their careful evaluation, and to the OpenSearch community for making this first hackathon a success!
