- Write elegant, efficient, and concise code. Prefer simple, clear designs; concise does not mean clever.
- Prefer the smallest coherent change. Reuse existing mechanisms and avoid wrappers or abstractions for speculative or unmeasured gains.
- Prefer direct
iformatchcontrol flow and explicit state types over clever combinators, wrappers, or invalid boolean/Optioncombinations. Prefer plainif/elseto.then()or.then_some(). - Try hard to avoid
panic!,unreachable!,.unwrap(), and.expect(). Encode those constraints in the type system instead. More explicit code or a larger refactor is acceptable when it avoids these calls. - Do not narrate code in comments. Explain invariants and unusual decisions in plain language that makes sense to a first-time reader. Be more verbose when clarity requires it.
- Fix Clippy findings. If suppression is necessary, prefer a narrow
#[expect(...)]with a reason.
- Write natural, direct English that sounds like a human collaborator, not a template or an AI-generated response.
- Avoid canned introductions, generic filler, repetition, and unnecessary summaries.
- Avoid dash-heavy prose, especially em dashes or
-used to join thoughts. Prefer a period, comma, colon, or an explicit conjunction. For example, preferThis is safe because the fallback still validates the state.overThis is safe - the fallback still validates the state.
-
Linked worktrees must share the primary Cargo target. Before running
cargoor a Cargo-backedmisetask, set:export CARGO_TARGET_DIR="$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")/target"
-
Check existing coverage and nearby style before adding a test. Prefer focused tests; do not run the full integration suite by default.
-
In integration tests, prefer
cmd_snapshot!snapshot coverage over string assertions such ascontains. -
Regenerate
instasnapshots with the relevant test and review them withcargo insta review; do not edit them manually.
- Draft GitHub comments locally. Do not post, submit reviews, resolve threads, or otherwise mutate GitHub state without explicit authorization.
- Keep commits focused with short imperative subjects. Never publish unrelated history or changes.
- Use the shortest practical branch name without a
codex/prefix. - Use a moderately descriptive title that clearly states the core action while
remaining concise. Prefer
Build and reuse a run-scoped file indexoverBuild run file index once. - Keep the PR body short; it may be only
Closes #<issue no>. - Do not include verification steps in the PR body.
- Add an appropriate
bug,enhancement,performance,internal,ci, ordocumentationlabel. - Do not create a draft PR unless explicitly requested.
- On an existing PR branch, amend only a trivial same-scope change; otherwise add a commit. Do not push or alter review state unless explicitly requested.