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 skills add solokeys/solo2 --skill flash-solo-hackergit clone --depth 1 https://github.com/solokeys/solo2Wrote 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/solokeys/solo2/flash-solo-hacker)<a href="https://agentmods.dev/skills/solokeys/solo2/flash-solo-hacker"><img src="https://agentmods.dev/badge/skills/solokeys/solo2/flash-solo-hacker.svg" alt="Measured on agentmods" 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.00091 | $0.01113 |
| Opus 5 | $0.00046 | $0.00557 |
| Sonnet 5 | $0.00018 | $0.00223 |
| Haiku 4.5 | $0.00009 | $0.00111 |
Grade A, and why
flash-solo-hacker 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 7d 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 — 74 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Build & flash a Solo 2 Hacker — safely
⚠️ A Hacker key has no easily accessible debug probe (SWD exists but isn't broken out over USB like a dev board's J-Link). A flash that doesn't boot + enumerate is effectively permanently bricked — unrecoverable in practice. Read this whole skill before writing anything to a Hacker.
Golden rules
- EVK-first. If a dev board (LPC55S69-EVK) is available, build and validate the equivalent EVK build first (same source + features, just the EVK board target) — it has a J-Link and is fully recoverable. It is not a byte-identical binary — the EVK uses a different board target and no flash encryption — but it exercises the same code paths. Only flash the Hacker once the EVK build is proven. A bad shard/storage build has bricked a Hacker before.
- Match the build to the key's storage mode (see step 2). Flashing a PRINCE-encrypted build onto a plain key (or vice-versa) bricks it.
- Never attempt to flash custom firmware onto a Secure key — it only accepts SoloKeys-signed updates, and you must not try to unlock a user's production key (it won't work).
1. Build the firmware
git checkout <release-tag> # reproduce a known release, or use your branch
make -C runners/lpc55 build-hacker # → runners/lpc55/app-hacker.bin
# EVK equivalent for pre-validation:
make -C runners/lpc55 evk # → app-hacker-evk.bin (hacker feature set on the EVK)
2. Verify lock state and storage mode (Secure vs Hacker)
Lock state. "Secure vs Hacker" = locked vs unlocked, which is the PFR seal field — not secure boot. Read it two ways:
solo2 app admin locked # quick: Hacker → unlocked, Secure → locked
lpc55 pfr native # authoritative: the `seal` field — true = locked (Secure), false = unlocked (Hacker)
⚠️
seal≠ secure boot. A key can havesecure_boot_enabledset (and even the "Solo 2 Security Key" label) and still be unlocked. Thesealfield is the source of truth for locked/Secure vs unlocked/Hacker. Do not flash a sealed (seal = true) key — it's a Secure/production key.
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.
- 7d ago First seen · 74 lines · 91 tokens per session scan A d0009b6fce2d
flash-solo-hacker is a skill published in the GitHub repository solokeys/solo2 (708 stars, last pushed 17d ago), licensed Apache-2.0. It adds 91 tokens to every session and 1,113 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
gke-compute-classes
Configures, optimizes, and troubleshoots GKE ComputeClasses. Use when configuring Spot VMs with on-demand fallback, targeting specific accelerators (GPUs/TPUs) or machine families, restricting ComputeClass access, or debugging pending pods related to node pool auto-creation. Do not use for cluster-level Node Auto…
jetson-diagnostic
Read-only Jetson health snapshot for identity, memory, GPU, thermal, power, storage, services, and top processes.
doca-socket-relay
Use this skill when the operator is driving the DOCA Socket Relay to bridge a socket-oriented host application onto a BlueField DPU peer without rewriting it — picking the deployment shape (in-process, sidecar, or BlueField service container), configuring the host-side socket and the DPU-side forwarding endpoint…
offensive-z-wave
Z-Wave attack methodology — sniffing with Z-Force / EZ-Wave / RTL-SDR + ZniffMobile, S0 (legacy) network-key derivation flaw and key reuse, S2 (modern) ECDH commissioning analysis, replay/injection on unauthenticated nodes, default-key brute-force on test deployments, and home-automation hub pivots. Use when targeting…
hsb-flash
Flash the FPGA on an HSB board connected to an NVIDIA devkit. Supports HSB Lattice boards (FPGA versions 2407, 2412, 2507, 2510) and Leopard Imaging VB1940 "all-in-one" cameras (FPGA versions 2507, 2510). Uses release-specific YAML manifests and board-type-specific program commands. Lattice and VB1940 commands must…
jetson-validate-image
Use after jetson-flash-image to run static BSP checks, on-target smoke/regression tests on a flashed DUT, or both. Not for build or flash steps. Triggers: validate bsp, on-target validation.