A Kaggle skill that reads the competition before it writes any code

One skill for the whole competition workflow

This is an agent plugin from a major hardware vendor that gives an assistant the ability to work through Kaggle competitions end to end. It is delivered as a single skill, and the README's framing is that one skill covers the entire arc: gathering competition context, studying public writeups and notebooks, reproducing kernels locally, submitting entries, and managing datasets.

The design choice worth noting first is the decision to package all of that as one skill rather than a dozen. The README states the skill accepts whatever is natural, a competition slug, a Kaggle URL, a kernel reference, a writeup link, or a local path, and picks the right script to run based on the request.

That is a deliberate interface decision and a good one. The alternative, a separate command for each operation, pushes onto the user the job of knowing which command matches their intent, which is exactly the mapping a language model is well suited to make. Letting the user say what they want in a sentence and having the skill route it is the interface that plays to the model's strength rather than working around it.

The audience is a competitor who already works with a coding agent and wants that agent to reach into Kaggle directly, rather than switching to a browser to read discussions and back to the terminal to run code.

Reading before writing

The workflows the README lists divide cleanly into two kinds, and the split is telling.

The first kind is about understanding. Fetching a competition's overview, rules, evaluation metric, timeline and dataset description. Finding leaderboard writeups and summarising the strongest approaches. Indexing discussions, searching them and reading selected threads. Indexing, querying and reading public kernels.

The second kind is about doing. Downloading a notebook and its inputs into a local workspace. Pushing a submission and polling for the result. Creating or updating a dataset from a local folder.

The prominence of the first kind is the interesting part. A tool built only to submit would be a thin wrapper over the existing Kaggle interface. Most of what this skill does is help an agent read the accumulated knowledge of a competition before writing any code: what has historically won, what the community has already tried, what the pitfalls are. That reflects how competitions are actually approached by people who do well at them, where the research phase is where the work is, and the modelling follows from it.

The example interactions in the README show this directly. One asks for the top solution writeups from a named mathematics competition and a summary of the key strategies. Another asks for a competition's overview and dataset description as the first thing to run when starting. The pattern is study first, build second, which is the right order and not the one a beginner reaches for.

Invocation, and the credential that matters

The skill is invoked by naming it and stating the request in plain language:

/nvidia-kaggle:nvidia-kaggle-skill Fetch the competition overview and dataset description for the ARC Prize 2025 competition.

Everything after the skill name is ordinary language, and the skill decides which script to run. That is the routing described earlier made concrete.

The requirements are modest and clearly stated. Python 3.10 or newer, an agent runtime that supports plugins or the Agent Skills specification, with the README naming a couple of compatible harnesses, and a Kaggle account with an API token for anything that touches the Kaggle backend.

The token requirement is the line to read carefully, because it separates the two halves of the tool. Reading public competition pages and writeups is one thing; the API-backed workflows, dataset access, kernels, submissions and uploads, need your Kaggle credential. That credential can act as you on Kaggle, including submitting to competitions and creating datasets under your account, so it is worth treating with the same care as any other access token and being deliberate about which environment you place it in.

Nothing about that is unusual, and it is the normal cost of a tool that acts on your behalf on a platform. It is worth stating plainly because a skill that can submit on your account is a skill whose token is worth protecting.

What the example outputs are, and are not

The README illustrates each workflow with a collapsible example answer, and these are worth reading correctly.

The mathematics-competition example shows a ranked table of top teams with the techniques attributed to each, followed by a list of extracted strategies. The tabular-competition example lists the most-referenced public kernels and the modelling approaches they used. Each ends with a note of the files written to the local workspace.

The important thing to understand is what these outputs represent. They are examples of what the skill produced on a particular run by reading Kaggle's own pages, not claims the vendor is making about competition results, and not benchmark figures the reader should take as established fact. The skill's job is to gather and summarise what is already published on Kaggle, so the accuracy of any given summary depends on the source material and on the summarisation, exactly as it would if you read those discussions yourself.

That framing matters for setting expectations. A summary of the strongest approaches is a research aid that points you at what to read, not a substitute for reading the winning solution when you are deciding what to actually implement. Used as the former it saves real time; treated as the latter it would be trusting a summary with a decision that deserves the source.

The repository includes a benchmark document and a demonstration directory, so a reader who wants to judge the skill's quality has material to look at beyond the README's curated examples.

Governance that matches its origin

For an official release from a large company, the repository carries the governance files you would expect, and their presence is part of what distinguishes this from an individual's weekend project.

There is an MIT licence, which is genuinely permissive and allows commercial use, alongside a security policy, a contributing guide, a contributor licence agreement and a third-party notices file. The third-party notices file is the one that earns its place here, because a tool that reaches into an external platform's API depends on that platform's terms, and separating those acknowledgements out is the correct way to keep the licensing legible.

The repository is laid out to support several agent runtimes at once, carrying separate plugin definition directories for more than one harness, which is consistent with the README's claim of working across compatible agents rather than a single one.

A contributor licence agreement on an MIT project is standard practice for corporate open source and signals the company wants clear rights over contributions, which is unremarkable in this context rather than the flag it might raise on a smaller project. Anyone contributing should still read it, as always, because it governs the contribution rather than the plain licence.

The project reports 327 stars, 38 forks and six open issues, with the last push on 2026-08-04, and publishes no tagged releases, so the default branch is the reference point.

Where it fits, and where it does not

The clearest way to place this skill is by what it does and does not remove from the work.

It removes the friction of moving between a browser and a terminal, and the tedium of manually gathering a competition's context and the community's prior art. For someone already working inside a coding agent, having the agent fetch the rules, index the kernels and pull down a notebook to reproduce, all from a sentence, is a real saving at the start of a competition, which is exactly when that groundwork is most valuable and least enjoyable.

What it does not do is the modelling. The skill gathers, summarises, reproduces and submits; it does not decide what to build, and the quality of an entry still comes from the competitor. That is the correct boundary for a tool like this, and the README does not overreach by claiming otherwise. The value proposition is a faster and better-informed start, not an automated competitor.

The dependence on the Kaggle API is the practical constraint to keep in mind. The submission and dataset workflows are only as available as that API and your credential, and the reading workflows are only as good as what the community has published for a given competition, which varies enormously between a popular contest and an obscure one.

Before adopting it, three steps in order. Confirm your agent runtime supports the plugin or Agent Skills specification, since that is the hard requirement. Set up a Kaggle API token and decide which environment holds it, treating it as a credential that can act on your account. Then start with a reading workflow on a competition you know, so you can judge the quality of the summaries against something you can already evaluate before trusting them on a competition you cannot.

Editorial conclusion

This plugin fits a Kaggle competitor who already works inside a coding agent and wants it to reach into the platform directly, and its real value is in the research phase, using the agent to gather a competition's context and the community's prior art from a plain sentence rather than a browser session. Read its example outputs as summaries the skill gathered from Kaggle's own pages rather than as benchmark claims, and treat the summarised writeups as pointers to what to read rather than as substitutes for the source when a decision depends on it. Confirm your agent runtime supports the plugin specification, place your Kaggle API token deliberately since it can act on your account, and start on a competition you already understand so you can judge the summaries before relying on them elsewhere.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. NVIDIA/nvidia-kaggle on GitHub
4. README