Getting it into your agent
There is no command for this one: it runs only inside a plugin, and the catalogue could not identify which plugin ships it. The source is linked below.
Wrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/syhya/mlsys26-flashinfer-contest/flashinfer-submission-tagger)<a href="https://agentmods.dev/skills/syhya/mlsys26-flashinfer-contest/flashinfer-submission-tagger"><img src="https://agentmods.dev/badge/skills/syhya/mlsys26-flashinfer-contest/flashinfer-submission-tagger/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/syhya/mlsys26-flashinfer-contest/flashinfer-submission-tagger"><img src="https://agentmods.dev/badge/skills/syhya/mlsys26-flashinfer-contest/flashinfer-submission-tagger.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00100 | $0.01585 |
| Opus 5 | $0.00050 | $0.00792 |
| Sonnet 5 | $0.00020 | $0.00317 |
| Haiku 4.5 | $0.00010 | $0.00159 |
Grade A, and why
flashinfer-submission-tagger scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 120 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Flashinfer Submission Tagger
Overview
Create a new submission-vN tag for the current commit, push that tag to the remote repository, and verify the exact tag and commit that FlashInfer contest evaluation should consume.
Use the bundled script to compute the next tag deterministically instead of re-implementing version selection by hand.
Use the bundled topology checker to block invalid config.toml layouts before commit, tag, or push.
Workflow
- Check repository state before tagging.
- Read the current branch, commit SHA, existing
submission-*tags, and remotes. - Assume
originis the push remote unless the user explicitly asks for another remote ororiginis missing.
- Choose the tag name.
- If the user provides a concrete tag, use it exactly.
- Otherwise, select the next numeric version after the highest existing
submission-vN. - Never reuse or retarget an existing tag unless the user explicitly asks for that destructive action.
- Validate
config.tomltopology before touching metadata. This is a hard gate.
- Run:
python3 /Users/yue/.codex/skills/flashinfer-submission-tagger/scripts/check_config_topology.py --repo /path/to/repo
- If the checker exits non-zero, STOP. Do not commit, tag, or push until the layout is fixed.
- The checker only evaluates the submission surface: the repo root, immediate definition subdirectories, and the
solution/trees attached to them. It intentionally ignores archived artifacts under directories such asoptimize_ops/orreference/. - Accepted layouts:
- Single-definition root layout: root
config.toml+ rootsolution/<language>/... - Definition-subdir layout: one or more
<definition>/config.tomlfiles, each paired with<definition>/solution/<language>/...
- Single-definition root layout: root
- Forbidden layouts:
- root
config.tomlin a multi-definition repo - both root
config.tomland definition-subdir configs in the same repo - any
config.tomlnested undersolution/ - a config whose
entry_pointfile does not exist under the resolved source dir - a resolved source dir with zero real source files
- root
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 10d ago First seen · 120 lines · 100 tokens per session scan A b34f76499072
flashinfer-submission-tagger is a skill published in the GitHub repository syhya/mlsys26-flashinfer-contest (22 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 100 tokens to every session and 1,585 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
release-manager
Manage software releases end-to-end: bump version, generate changelog, tag, push, GitHub release, publish to PyPI/npm. Use when asked to ship, cut a release, or tag a version. Don't use for routine commits or marketplace publishing.
gem-release
Automates the complete process of releasing a new version of the openclacky Ruby gem. Supports both stable releases (auto-increment) and pre-release versions (user-specified, e.g., 1.0.0.beta.1). Handles version bumping, testing, building, RubyGems publishing, GitHub Releases, and OSS CDN mirroring.
lime-release-workflow
A release workflow for the Lime software project. It covers version numbers, release notes, cleaning generated files, required checks, commits, tags, and pushing changes.
release
Verify, sweep docs, cut a version — then hand the release sequence back.
cf-ship-custom
This is a version bump + ship + release operation. Run these steps BEFORE the standard cf-ship workflow.
cf-ship
Verify, commit, push, and create a PR. Triggers: "ship it", "push and create PR", "let's ship", "create a PR", "open a pull request", "ready to merge". Supports --dry-run.