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/tangosdev/sm64ds-decomp/agent-locknpx skills add tangosdev/sm64ds-decomp --skill agent-lockgit clone --depth 1 https://github.com/tangosdev/sm64ds-decompWhat 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.00129 | $0.01422 |
| Opus 5 | $0.00064 | $0.00711 |
| Sonnet 5 | $0.00026 | $0.00284 |
| Haiku 4.5 | $0.00013 | $0.00142 |
Grade A, and why
agent-lock 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 3d 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 — 115 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Local agent locking (Redis, this machine only)
tools/agentlock.py is a local lock, backed by a Redis container in
local-infra/. It exists for the case tools/claims.py doesn't cover: several agents
(forks, worktrees, a Workflow's parallel stages) running on this machine in this
session, about to edit the same file or the same address range at the same time.
It is not a substitute for tools/claims.py — that one coordinates with other
contributors over the network and only understands address ranges. This one also locks
plain filenames, has near-zero latency, and every lock expires on its own (crash-safe).
When to reach for it
- An orchestrator is about to fan out several agents/forks that each edit files —
especially shared ones like headers,
config/rombuild-versions.txt,CLAIMS.md, or anything underbuild/(concurrent builds there already fake failures — see memoryconcurrent-builds-fake-failures). - Two agents might independently pick the same class/function address range to migrate or byte-match in the same run.
- You're not sure two agents' file sets overlap — cheaper to lock and find out than to debug a corrupted merge afterward.
Skip it for read-only work (matching research, reading source, running fdiff) and for
a single agent working alone — it's overhead with no payoff there.
Setup (once per machine, or after a restart)
docker compose -f local-infra/docker-compose.yml up -d
No persistence by design — a restart starts with an empty lock table, never resurrects
stale locks. If agentlock.py can't reach Redis it says so and names this command.
Identity
Locks are owned by a holder string: AGENTLOCK_HOLDER env var, else the OS username.
If you are one of several agents/forks running concurrently under the same OS user,
set a distinct AGENTLOCK_HOLDER per agent (its worktree name or agent name is a good
choice) — otherwise it can renew or release a sibling agent's locks by accident, since
holder identity is the only check (this is a local convenience lock, not an auth
system).
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.
- 3d ago First seen · 115 lines · 129 tokens per session scan A 4c93aba2313e
agent-lock is a skill published in the GitHub repository tangosdev/sm64ds-decomp (138 stars, last pushed 3d ago), licensed MIT. It adds 129 tokens to every session and 1,422 once invoked, about $0.0006 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
th08-matching
Compile TH08 functions with the repository VC7 build and compare configured COFF functions against the hash-attested 1.00d target using config/match-units.toml and scripts/compare-function.py. Use for focused code-generation tuning, relocation diagnosis, or exact-match verification.
th08-typed-re
Generate and interpret target-pinned TH08 instruction and ABI fact packets with scripts/typed-re.py. Use for stack layout, register homes, access widths, direct calls, return cleanup, or VC7 source-shape diagnosis before strict comparison.
th08-re
Reconstruct bounded functions from the original Japanese TH08 1.00d executable using hash-attested target evidence, upstream GensokyoClub source, and explicitly labeled TH06/TH07 corroboration. Use for TH08 disassembly, ABI recovery, function naming, layout recovery, source migration, or implementation work.
th08-library
Recover and attest target-linked TH08 VC7 CRT, compiler-runtime, and D3DX library functions after authored coverage. Use for library inventory boundaries, archive/member provenance, hash pinning, relocation-aware comparison design, or whole-link preparation; do not use for repository third-party submodules.
th08-semantic
Replace raw TH08 object offsets, anonymous fields, and absolute field views with evidence-backed C++ types and names while preserving accepted VC7 bytes and playable modern-port behavior. Use for semantic cleanup of already-authored source; do not use for new function recovery or target-linked library work.
analyzing-android-dex-malware
Reverses Android malware: unpacking APKs, decompiling DEX bytecode to readable Java, auditing the manifest for abused permissions and components, and locating dynamically loaded or native payloads. Activates for requests to analyze an APK, decompile DEX, or investigate a suspicious Android app.