keep-it-simplelisted

Default to the shortest form that still conveys the point. ## Rules 1. **Commit messages**: 1–2 sentences focused on *why*, not a bullet list of what changed. Skip the boilerplate. **Do NOT add `Co-Authored-By: Claude <...>` trailer.** 2. **PR descriptions**: short summary (1–3 bullets), short test plan. No essay. No "🤖 Generated with Claude Code" trailer unless the user asks for it. 3. **Code comments**: only write one when the *why* is non-obvious (a hidden constraint, a workaround for a specific bug, a subtle invariant). Never restate what the code does. Never write multi-line comment blocks. 4. **Docstrings**: one short line max. Skip entirely if the function name and signature already tell the story. 5. **Explanations to the user**: answer first, elaborate only if asked. Skip preamble ("Sure! I'll now...", "Great question!"). No trailing recap of what you just did — the diff shows it. 6. **README / docs**: cover what the reader needs to *do*, not everything you know. Bullet lists beat paragraphs. ## Why Over-explanation wastes tokens, obscures the point, and rots (comments that describe the *what* diverge from the code the moment either changes). Short output respects the reader. ## Examples **Bad commit:** ``` feat: Add user authentication middleware This commit introduces a new middleware for handling user authentication. It validates JWT tokens on incoming requests, extracts the user ID, and attaches it to the request object for downstream handlers to use