Commit Message Style

Format

• •Use: type: <imperative summary>
• •Use lowercase type, no scope: fix: ..., not fix(sdk): ...
• •Prefer short, direct, present tense; no trailing period; keep to ~72 chars when possible
• •Wrap code identifiers in backticks (types, fns, flags, files, crates): ``fix: gate Felt behind `cfg(miden)```
• •Append an issue reference at the end only when relevant: ... #629
• •For non-trivial changes, add a commit body (blank line after subject) explaining:
  • •Why the change is necessary (problem/constraint), and
  • •What changed at a high level (only if complex enough to benefit from an overview).
• •Keep the body short (typically 1–8 lines), wrap at ~72 chars, and avoid implementation details.

Types

• •fix: bugfix or behavior correction
• •refactor: behavior-preserving changes (rename, extract, restructure)
• •feature: user-visible functionality / new capability
• •test: tests, fixtures, golden/expected outputs
• •chore: docs/comments, cleanup, build/CI nits, dependency housekeeping

Verbs (prefer)

• •add, remove, fix, refactor, extract, rename, unify, gate, document, update, simplify

Workflow

• •If asked to address multiple review remarks: make one commit per remark (smallest coherent change per commit).
• •Choose the type by intent (behavior change vs structure vs tests vs docs).
• •Prefer stable naming (don’t churn identifiers) unless the change is explicitly a rename/refactor.
• •When the subject/body contain backticks, avoid shell command-substitution by passing the message via stdin, e.g. git commit -F - with a quoted heredoc.

Examples (match style)

• •refactor: extract \account_id_inputs` helper`
• •feature: gate on-chain \Felt` behind `cfg(miden)``
• •fix: serialize u64 as two u32 limbs
• •chore: refine doc comments
• •test: update integration expected outputs