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/batteryshark/rekit/js-string-decodenpx skills add batteryshark/rekit --skill js-string-decodegit clone --depth 1 https://github.com/batteryshark/rekitWhat 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.00181 | $0.01413 |
| Opus 5 | $0.00090 | $0.00707 |
| Sonnet 5 | $0.00036 | $0.00283 |
| Haiku 4.5 | $0.00018 | $0.00141 |
Grade A, and why
js-string-decode 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 — 96 lines — stays where its author put it; the contents beside it link to each section on GitHub.
JavaScript Constant-Key String Decoder
Statically recover strings that JavaScript hides with a constant-key XOR / charCode scheme, and write them out as plaintext so a downstream scanner can read them. Pure-Python stdlib, read-only — it never runs a JS engine or executes any part of the input.
When to use
A file (often a carved single-file-executable bundle) keeps its telltale strings —
C2 URLs, victim domains, timezone names like Asia/Shanghai, shell commands — out
of a plain strings dump by XORing each character with a constant byte and
reassembling them with String.fromCharCode. js-covert-scan flags that an XOR /
charCode tactic is present; this skill decodes it, statically, and hands the
plaintext back for rescanning.
It is the zero-execution complement to js-deobfuscate (which recovers encoded
string arrays by running the decoder inside a sandbox). Reach for this one when the
scheme is the constant-key case and you want no execution at all.
What it does
python3 scripts/decode.py <input.js> [outdir]:
- Scan the JS with regex/heuristics (no JS engine, no execution). It finds
constant-key XOR/charCode decode sites: a
String.fromCharCode(<x> ^ <KEY>)or<c> ^ <KEY>applied over a static encoded literal. - Resolve
<KEY>when it is a small int literal (0x91,145) or a variable assigned a small int nearby (var kk5=91) — best-effort constant propagation by nearest-preceding assignment (so reused minified names resolve to the right scope). - Decode each site (apply the XOR to the encoded data → plaintext).
- Write the recovered strings to
<outdir>/decoded-strings.js:
one per line as JS string literals, so the fold rescans it as source and sees the plaintext URLs / hostnames / commands.// decoded from <input> /* key=91 base64/fn:c57 off=4835057 */ "cn,sankuai.com,netease.com,163.com,…" - Emit JSON to stdout (the default — no flag needed):
Nothing to decode →{"ok": true, "outputDir": "<abs>", "decoded": [{"key": 91, "count": 2, "sample": "cn,sankuai.com,…"}], "siteCount": 2}{"ok": true, "outputDir": "<abs>", "decoded": [], "siteCount": 0}. Bad input →{"ok": false, "error": "…"}and a non-zero exit.
What ships with it
1 file 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.
- 2d ago First seen · 96 lines · 181 tokens per session scan A 0f295c84c453
js-string-decode is a skill published in the GitHub repository batteryshark/rekit (11 stars, last pushed 24d ago), licensed Apache-2.0. It adds 181 tokens to every session and 1,413 once invoked, about $0.0009 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
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
chat-perf
Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…