メニュー
Use when writing MASM `u32*` instructions on values from user input or untrusted sources — ensure the operands are valid u32s first.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
SOC 職業分類に基づく
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/0xMiden/agent-tools --skill u32-assert-before-u32-opsコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
Use when writing kernel, account, or note MASM code that reads from or writes to the advice provider (advice stack / advice map) — validate advice data.
Use when writing or reviewing MASM hot paths — prefer the cheaper equivalent instruction: `neq.0` over `push.0 gt` for non-zero checks, `cdrop` over an `if/else` selecting between two values, `dup.N` over `loc_load` for a value still on the stack, `eqw` over hand-rolled element-wise word comparison, `u32gt`/`u32lt` over generic `gt`/`lt` on known-u32 operands.
Use when writing a GENERIC MASM storage utility (one that operates over a caller-chosen slot or map) inside a reusable account component — receive the slot id as a parameter so the utility works against any slot, not one hard-coded one.
| name | u32-assert-before-u32-ops |
| description | Use when writing MASM `u32*` instructions on values from user input or untrusted sources — ensure the operands are valid u32s first. |
MASM's u32* instructions require their operands to be valid u32 values (i.e. fit in 32 bits, <= u32::MAX). Applied to a non-u32 value the behavior is undefined: in the current VM such an op typically traps with the generic error (operation expected u32 values, but got values: ...) rather than telling you which precondition was violated — but trapping is not guaranteed (it may instead wrap/truncate and silently poison the proof).
Before applying any u32* instruction to a value that is not already known to be a valid u32 (e.g. it came from the stack as input, was read from memory, or arose from a non-u32 arithmetic op), assert the bound with a descriptive error:
u32assert # assert the one value on top of the stack
u32assert2 # assert the two values on top of the stack
u32assertw # assert the four elements of the word on top of the stack
All three accept a named error via .err=, e.g. u32assert2.err=ERR_NOT_U32.
If the operand is already known-valid (just produced by another u32* op, or a value loaded from a slot whose layout is u32 by construction), skip the assert.
u32* instructions are tuned for the precondition that operands fit in 32 bits. Passing an out-of-range operand to a u32* op is undefined behavior: the current VM almost always traps with the generic operation expected u32 values, but got values: ... error, but trapping is not guaranteed — it may instead wrap/truncate and silently poison the proof, and even when it traps it does not name the precondition or the call site. Asserting first with u32assert*.err= turns this fragile/undefined path into a deterministic, named failure mode, so a non-u32 input fails loudly and diagnosably at the point where the assumption is introduced.
# Good: assert u32 before the u32 op
u32assert.err=ERR_VALUE_NOT_U32
u32overflowing_add
# Good: both operands at once
u32assert2.err=ERR_VALUES_NOT_U32
u32lt
# Bad: u32 op on untrusted input
u32overflowing_add # if an operand exceeds 2^32 the behavior is undefined; the current
# VM typically traps with the generic "operation expected u32 values"
# error instead of a named one (but may instead wrap and poison the proof)