菜单
Use when adding or editing MASM `assert*` instructions — give every assertion a descriptive error (a named `ERR_*` constant or an inline string).
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
Use when constructing a `Felt` from a numeric value in Rust — avoid silently producing a non-canonical Felt that no longer equals the original input.
Critical pitfalls and safety rules for Miden frontend development. Covers WASM initialization, concurrent access crashes, COOP/COEP headers, BigInt handling, Bech32 network mismatches, IndexedDB state loss, auto-sync side effects, Vite configuration, and React rendering race conditions. Use when reviewing, debugging, or writing Miden frontend code.
Guide for advanced Miden frontend development using source repo exploration. Covers AI development practices (Plan Mode, verification-driven development, context engineering, sub-agents) and maps the Miden web-sdk source repository for discovering advanced patterns. Use when building complex applications beyond basic hook usage, implementing custom signers, working with WasmWebClient directly, or troubleshooting SDK internals.
| name | masm-error-constants |
| description | Use when adding or editing MASM `assert*` instructions — give every assertion a descriptive error (a named `ERR_*` constant or an inline string). |
Every MASM assertion should carry a descriptive error message. There are two valid forms in v0.15 source:
ERR_* constant — preferred for reusable or shared errors, and the dominant style in protocol/standards code:assert.err=ERR_NOTE_NOT_FOUND
assert_eqw.err=ERR_COMMITMENT_MISMATCH
.err="..." — valid and common, especially in core-lib/stdlib and for one-off, local checks:u32assert2.err="number of storage map elements should fit into a u32"
assert.err="number of storage map elements must be a multiple of 8"
Prefer a named constant when the same error is raised in more than one place, when it is part of a module's documented error surface, or when Rust code needs to match on it (named ERR_* constants are codegen'd into Rust bindings — see masm-rust-constant-parity). Reach for an inline string for a purely local, single-site check where a named constant would only add indirection.
When you define a named error constant, it must:
ERR_ prefix.masm-constants skill).const ERR_NOTE_NOT_FOUND = "note not found".ERR_ across two unrelated asserts.A bare assert traps with the default error code 0, which tells the debugger nothing about which check failed; a descriptive error message (a named ERR_* constant or an inline string) ties each trap site to a specific failure mode. (The error string is hashed into a field element; an omitted code defaults to 0.) Distinct constants per condition also let tests pin the expected error rather than matching a generic failure.
# Good
const ERR_NOTE_NOT_FOUND = "note not found"
const ERR_COMMITMENT_MISMATCH = "stored commitment does not match recomputed value"
proc verify_note
# ...
assert.err=ERR_NOTE_NOT_FOUND
# ...
assert_eqw.err=ERR_COMMITMENT_MISMATCH
end
# Bad: bare assertion
proc verify_note
assert
end
# Bad: shared generic constant for unrelated cases
const ERR_INVALID = "invalid"
assert.err=ERR_INVALID # used in 6 places, each meaning something different