docs(claude): avoid CSS comments

The rule only forbade comments narrating a change. CSS comments are now
avoided outright: a rule reads through its selector and properties, and
why a margin is negative or a selector excludes a class goes in the
commit message. The exceptions stay: a browser workaround, a value that
must match one in another file, a `z-index` in a stacking contract.

The building-client-ui skill carries the rule in its styling summary,
and the PR review's comment-style check flags any other added CSS
comment rather than only `/* was Npx */`.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

.claude/skills/building-client-ui/SKILL.md

@@ -7,7 +7,7 @@ description: Use when building or changing any UI in the Trilium client (`apps/c
 
 The client is a Preact app (legacy widgets are jQuery `BasicWidget`s; new UI is Preact). Shared components live in `apps/client/src/widgets/react/`. **Always reuse them instead of writing raw HTML elements or a custom implementation** — every hand-rolled `<input>`, `<select>`, `<button>`, `<a>`, pill or overlay button is a second copy of styling, focus handling and accessibility that drifts.
 
-The general styling rules (no inline styles, one `.css` file per component imported at the top, scope by root class + native CSS nesting) are in the repo `CLAUDE.md`; this skill is about *which component* and *how to drive it*.
+The general styling rules (no inline styles, one `.css` file per component imported at the top, scope by root class + native CSS nesting, no CSS comments beyond a browser workaround, a value shared with another file or a stacking contract) are in the repo `CLAUDE.md`; this skill is about *which component* and *how to drive it*.
 
 > **CLAUDE.md still foregrounds the jQuery widget lifecycle** (`doRenderBody` / `refreshWithNote` / `this.$widget`). That is for maintaining existing widgets. New UI is a `.tsx` component using the hooks below; reach for `useLegacyWidget` only to embed an existing jQuery widget into a Preact tree.
 

.claude/skills/reviewing-pull-requests/references/accepted-shape.md

@@ -181,7 +181,7 @@ written beside the codebase rather than in it. Run them in the verify worktree
 | generated help never alone | `doc_notes/**` or `help_meta.json` changed ⇔ `docs/User Guide/**` changed |
 | only the `en` catalogues edited | `git diff --name-only $R \| grep -P 'translations/(?!en/)'` is empty |
 | `en-GB` twin for US spellings | an added `en` string with `color\|center\|meter\|recogni[sz]e\|labell?ed\|cancell?ed` needs the `en-GB` entry |
-| comment style | added comment lines with `—`, ` may `, `was \|previously\|no longer\|moved from\|removed\|intentionally not`; CSS `/* was Npx */` |
+| comment style | added comment lines with `—`, ` may `, `was \|previously\|no longer\|moved from\|removed\|intentionally not`; any added CSS `/* … */` that is not a browser workaround, a value shared with another file or a `z-index` contract |
 | no ~10-SLOC module | `git diff --diff-filter=A --numstat $R \| awk '$1 <= 15 && $3 !~ /spec/'` |
 | helpers below the primary export | in an added module, the first non-exported `function` comes after the first `export` |
 | CJS dynamic-import interop in split ESM | `const mod = await import("pkg"); const { x } = mod.default ?? mod;` — a plain destructure is the trap (`analyzing-backend-bundle` skill) |

CLAUDE.md

@@ -206,7 +206,7 @@ Use `note.getOwnedAttribute()` for direct, `note.getAttribute()` for inherited.
   - **This rule overrides the file you are editing.** Most comments in the repository predate it and use a literary register — personified subjects, em-dash asides, inverted clauses. Do not match them; they are history, not house style. Code has no voice: a card does not *state*, a row does not *say*, a request does not *stand*, a tool does not *hand over*.
   - Name the identifier instead of alluding to it. Write ``// Erasing changes the note and attachment counts, so `DatabaseInfo` reads them again.`` — not `// Erasing frees pages inside the file rather than shrinking it, so what the card above has to re-read is what the database holds.`
   - **Never comment an absence.** A removal — a prop, a flag, a CSS rule, a branch, a whole widget — is explained by the commit that makes it, not by a note left where the code was: at the call site it defends something the reader cannot see. The same goes for a removal's mirror image: don't annotate a default that was left alone, or an option deliberately not passed. If an absence needs defending in the source, name the code better instead.
-- **CSS comments** never narrate a change (`/* was 8px */`, `/* moved from the toolbar */`) — that is the commit message. Comment only what is non-obvious in place: a browser workaround, a value that must match one elsewhere, a `z-index` in a stacking contract.
+- **Avoid CSS comments.** A rule is read through its selector and properties; a comment explaining why a margin is negative or a selector excludes a class belongs in the commit message. Comment only what no reader can recover from the stylesheet: a browser workaround, a value that must match one in another file, a `z-index` in a stacking contract. Never narrate a change (`/* was 8px */`, `/* moved from the toolbar */`).
 
 ## Testing