メニュー
Use when changing a numeric or string constant in Rust or MASM that has a counterpart on the other side — keep the two definitions from drifting apart.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Enforce type-signature conventions for public Miden Assembly (.masm) procedures. Use when adding, editing, or reviewing a `pub proc` signature — parameter and return types, semantic type aliases, struct/array/tuple types, and how the signature maps onto the operand stack and the doc-comment Inputs/Outputs.
Enforce inline commenting conventions for Miden Assembly (.masm) files. Use when editing, reviewing, or creating .masm files.
Enforce doc comment conventions for Miden Assembly (.masm) procedures. Use when editing, reviewing, or creating .masm procedures, especially when documenting inputs, outputs, panic conditions, or invocation types.
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 a Rust test that exercises a failure path or a MASM test that expects a `panic` / `assert` — assert on the specific expected error variant or error code.
Use when writing or reviewing MASM hot paths — prefer the cheaper equivalent instruction: `neq.0` over `gt.0` 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 element-wise word comparison, `u32gt`/`u32lt` over generic `gt`/`lt` on known-u32 operands.
| name | masm-rust-constant-parity |
| description | Use when changing a numeric or string constant in Rust or MASM that has a counterpart on the other side — keep the two definitions from drifting apart. |
Constants that exist on both the MASM and the Rust side must not drift. Prefer a single source of truth: define the constant in MASM and generate the Rust counterpart from it, rather than hand-maintaining the same literal in two places.
This repo already does that in crates/miden-protocol/build.rs: it scans the MASM sources for const ERR_... = "..." and const X = event("...") definitions and emits Rust files (tx_kernel_errors.rs, protocol_errors.rs, transaction_events.rs) that are pulled in with include!(concat!(env!("OUT_DIR"), ...)) (see src/errors/mod.rs and src/transaction/kernel/tx_event_id.rs). A new error or event constant added in MASM gets its Rust binding automatically.
For constants not covered by codegen (memory offsets, capacity limits, field widths still duplicated in src/constants.rs / memory.rs), update both sides in the same PR — and prefer extending the generation over adding another hand-copied literal.
The kernel reads memory at offsets the Rust host wrote. If one side changes ACCOUNT_HEADER_LEN and the other doesn't, every transaction misreads its state, and the bug stays invisible until a value happens to straddle the changed offset. Generating one side from the other removes the chance to forget.
Source of truth in MASM:
const ERR_PROLOGUE_NEW_ACCOUNT_VAULT_MUST_BE_EMPTY="new account must have an empty vault"
Generated into OUT_DIR by build.rs and included via include!(concat!(env!("OUT_DIR"), "/tx_kernel_errors.rs")):
pub const ERR_PROLOGUE_NEW_ACCOUNT_VAULT_MUST_BE_EMPTY: MasmError =
MasmError::from_static_str("new account must have an empty vault");
For a constant that is still hand-duplicated, change both in the same PR:
// crates/miden-protocol/src/constants.rs
pub const MAX_INPUT_NOTES_PER_TX: usize = 1024;
# crates/miden-protocol/asm/.../constants.masm — must equal the Rust constant
pub const MAX_INPUT_NOTES_PER_TX = 1024