Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/aviatesk/jetls.jl/commitnpx skills add aviatesk/JETLS.jl --skill commitgit clone --depth 1 https://github.com/aviatesk/JETLS.jlWhat 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 | $0.00026 | $0.01166 |
| Opus 5 | $0.00013 | $0.00583 |
| Sonnet 5 | $0.00005 | $0.00233 |
| Haiku 4.5 | $0.00003 | $0.00117 |
Grade A, and why
commit 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 2d 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 — 137 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Message guideline
Title format
Use "component: Brief summary" format and imperative mood for the commit title.
Examples:
- "completions: Add support for keyword argument completion"
- "diagnostics: Fix false positive on unused variable"
- "ci: Update GitHub Actions workflow"
Body
Write a body by default, including for small, self-contained changes. Do not treat a descriptive title as a reason to omit the body. When little explanation is needed, briefly state the motivation and implementation.
Organize body paragraphs in this order and omit any paragraph that is not relevant:
- Explain the concrete problem, limitation, or goal motivating the change. For user-facing work, describe the resulting capability or behavior. For internal work, explain the engineering reason without inventing a user-visible impact. Include a small code example when it adds clarity.
- Explain the approach used to implement the change.
- Mention important caveats, follow-up work, performance notes, or test coverage when relevant.
Write body paragraphs as explanatory prose with explicit subjects:
- Prefer a concrete subject such as the affected component or newly introduced type.
- Use
This changeorThis commitwhen describing the patch as a whole. - Use
The implementationwhen explaining the mechanism. - Do not omit a subject merely to avoid
weorI.
Use backticks for code elements such as function names, variables, and paths.
Line length
Ensure the maximum line length never exceeds 72 characters. Never rely on Git or an editor to wrap the message automatically.
Before every commit, write the complete message to a uniquely named temporary
file with explicit line breaks, then commit with
GIT_EDITOR=true git -c core.hooksPath=.githooks commit -F <message-file>.
Do not use repeated git commit -m arguments for a multi-paragraph message.
The command-local core.hooksPath setting automatically runs the tracked
commit-msg hook and rejects lines longer than 72 characters.
Never use --no-verify to bypass it.
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.
- 2d ago First seen · 137 lines · 26 tokens per session scan A f546a350a143
commit is a skill published in the GitHub repository aviatesk/JETLS.jl (305 stars, last pushed 3d ago), licensed MIT. It adds 26 tokens to every session and 1,166 once invoked, about $0.0001 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
analyzing-packed-malware-with-upx-unpacker
Identifies and unpacks UPX-packed malware samples, including binaries with modified UPX magic bytes or headers that block automated decompression, to recover the original executable for static analysis. Use when a sample shows high entropy, minimal imports, or only LoadLibrary/GetProcAddress in its import table, or…
analyzing-malicious-pdf-with-peepdf
Perform static analysis of malicious PDF documents using peepdf, pdfid, and pdf-parser to extract embedded JavaScript, shellcode, and suspicious objects. Use when triaging a suspicious PDF attachment from a phishing email, analyzing a PDF-based exploit document, or building detection signatures for weaponized PDF…
analyzing-android-malware-with-apktool
Perform static analysis of Android APK malware using apktool for resource decompilation, jadx for Java source recovery, and androguard for manifest inspection, dangerous permission-combination detection, and identification of obfuscated code, dynamic code loading, and reflection-based API calls. Use to statically…
pysr
Use when fitting equations to data with PySR or SymbolicRegression.jl, when a user wants an interpretable formula, symbolic model, scaling law, or empirical relation discovered from numeric data, or when debugging a PySR search that is slow, stuck, or giving poor equations.
cli-analysis
Run the pyscn command-line tool for Python code quality analysis - CI/CD quality gates, HTML/JSON/CSV reports, full analysis runs, and project configuration. Use when user wants a CI check, a shareable report file, or to configure pyscn for a project.
health-check
Get an overall Python code quality health score using pyscn. Use when user asks how healthy or good the code is, wants a quality overview, a grade, a summary of technical debt, or a before/after quality comparison.