keep-it-simplelisted

Default to the shortest form that still conveys the point. Structure follows a convention where one exists; tone stays terse everywhere. ## Rules 1. **Commit messages** — always conventional-commit format: ``` <type>(<scope>): <subject> [optional body — only if the "why" isn't in the subject] ``` - **Types**: `feat` `fix` `perf` `refactor` `docs` `test` `build` `ci` `chore` `revert`. - **Subject**: imperative mood, no trailing period, ≤72 chars, focused on *why* not just *what*. - **Body**: 1–2 sentences, only when the subject doesn't cover it. Skip otherwise. - **Detect project convention first**: check `.commitlintrc.json` / `.commitlintrc.yml` / `commitlint.config.js` / `commitlint` key in `package.json`. If a `scope-enum` exists, use only those scopes. If none, derive from the touched area or omit. - **Do NOT add `Co-Authored-By: Claude <...>` trailer.** Ever. 2. **PR titles** — same conventional format as commits. Since squash-merge uses the PR title as the commit message on main, a bad title poisons history. 3. **PR descriptions** — short summary (1–3 bullets), short test plan (checklist). No essay. **Do NOT add "🤖 Generated with Claude Code" trailer.** 4. **Code comments** — necessity bar, not brevity bar. Write one when the *why* is non-obvious: a hidden constraint, a workaround for a specific bug, a subtle invariant, a landmine warning for future refactors. **Keep necessary comments fully** — a 3-line note explaining a real invaria