zed-industries/zed

Never silently discard errors with let _ = on fallible operations. Always handle errors appropriately:

Don't rely on LLMs to write the whole thing for you when communicating with the maintainers (meaning replies to comments, PR descriptions, and alike). The readers are humans, and we'd like to hear from you, not from a model (we have models at home). If you're a non-native English speaker using an LLM to thoroughly edit or translate your messages to the maintainers, we'd encourage you to put the machine translation in a quote block and include the original text in your native language after it.

We welcome the use of LLMs for coding, but we hold a high bar for all contributions, and we expect a human in the loop who genuinely understands the work an LLM produces on their behalf. For that reason, we don't accept contributions from autonomous agents. Pull requests that appear to violate this may be closed, sometimes without notice.

Stylistic code changes that do not alter any app logic. Reducing allocations, removing .unwrap()s, fixing typos is great; making code "more readable" — maybe not so much.

New file icons. Zed's default icon theme consists of icons that are hand-designed to fit together in a cohesive manner, please don't submit PRs with off-the-shelf SVGs.

Make the PR about one thing only, e.g. if it's a bugfix, don't add two features and a refactoring on top of that.

If you discover a non-obvious pattern that would help future sessions, include a "Suggested .rules additions" heading in your PR description with the proposed text. Do not edit .rules inline during normal feature/fix work. Reviewers decide what gets merged.

Thinking about proposing or building a larger feature? Don't start with a PR, start with reading the Zed Feature Process for how we think about feature design — what context to provide, what integration points to consider, and how to put together a strong proposal. The right place for the proposals is GitHub discussions (not GitHub issues).

Do not write organizational or comments that summarize the code. Comments should only be written in order to explain "why" the code is written in some way in the case there is a reason that is tricky / non-obvious.