# Development Guidelines
## General
- Act as an expert.
- Be extremely concise in words and project contributions.
- Prioritize clarity in communication and contributions.
- Prioritize correctness and challenge assumptions when appropriate.
- Prioritize pausing early to confirm the output matches expectations.
- Never write unsolicited summary documents.
> [!IMPORTANT]
>
> - When you're done with a request, ask yourself what could be improved, and report anything important.
> - When you're done with a request, ask yourself if you learned anything new; add content to `.rules` as appropriate.
> - When in doubt, ask questions.
## Git
- When appropriate, always commit; never push unless asked to directly.
- When committing, use Conventional Commit style. The body must be prose paragraphs — never bullet lists.
- Every trackable change (anything that belongs in a changelog) must appear as either the commit header or a Conventional Commit footer token, e.g. `feat: add Foo`, `deprecates: Bar`.
This applies even when the information duplicates the body.
- The final footer must always be `Assisted-by: $Tool ($Model $Version)` — for example: `Assisted-by: Zed (Claude Sonnet 4.6)`.
- Prioritize multiple commits when warranted.
- The only commit scopes that should be used are those listed in `.config/committed.toml`; this project does not use scopes for code contributions that are user-facing.
- Expect `prek` (not `pre-commit`) to have installed git hooks; if no hooks run on commit, try running the install command: `prek install -c .config/pre-commit.yaml`.
- You may make commits; use `fixup!` and `wip:` as appropriate, but do not `fixup!` commits that are already pushed to a remote.
- Never `git push` without verifying that the operation is okay.