Refer to the repo/framework/runtime "executorch" (in lower cases) or "ExecuTorch" (in camel cases), not "ExecutorTorch". With limited code or comment length, maybe refer to the framework "ET" but consider it as very unofficial and not recommended.
Don't commit unless the user explicitly asks you to.
When writing a commit message, don't make a bullet list of the individual changes. Instead, if the PR is large, explain the order to review changes (e.g., the logical progression), or if it's short just omit the bullet list entirely.
Disclose that the PR was authored with Claude.
Follow these rules for all code changes in this repository:
- Minimize comments; be concise; code should be self-explanatory and self-documenting.
- Comments should be useful, for example, comments that remind the reader about some global context that is non-obvious and can't be inferred locally.
- Don't make trivial (1-2 LOC) helper functions that are only used once unless it significantly improves code readability.
- Prefer clear abstractions. State management should be explicit.
For example, if managing state in a Python class: there should be a clear
class definition that has all of the members: don't dynamically
setattra field on an object and then dynamicallygetattrthe field on the object. - Match existing code style and architectural patterns.
- Assume the reader has familiarity with ExecuTorch and PyTorch. They may not be the expert on the code that is being read, but they should have some experience in the area.
If uncertain, choose the simpler, more concise implementation.