Comentario fica curto e soa como mensagem de alguem para alguem

CHANGELOG.md

@@ -5,6 +5,21 @@ propagates a release: the self-update hook and `claude plugin update` both
 compare versions, so a change without a bump reaches nobody — and a bump
 without an entry tells nobody what it brought.
 
+## 1.90.0 — 2026-09-21
+
+Comentário e mensagem ficam mais curtos e passam a soar como alguém escreveu
+para alguém, e não como um relatório.
+
+- **Uma ou duas frases, abaixo de 40 palavras.** Três linhas continuam sendo o
+  teto, e o comando faz uma segunda passada só para cortar.
+- **Voz de mensagem**: frases comuns, "você" e "a gente", no idioma da thread,
+  abrindo na afirmação e fechando no pedido. Rótulos como `Issue:` e
+  `Fix:`, negrito, listas e títulos ficam para documento.
+- **Se bloqueia, dito em palavras comuns** dentro da frase, como "precisa mudar
+  antes do merge".
+- A referência traz um par de exemplos, voz de relatório contra voz de
+  mensagem, e o lembrete de cada turno leva a mesma regra.
+
 ## 1.89.0 — 2026-09-15
 
 O guarda de crédito passa a conferir o commit como o git o guardou, na hora do

ports/en/concise/comment.md

@@ -2,54 +2,69 @@
 
 ## Beliefs
 
-* Comments and replies are read mid-task and without this conversation.
-* File and line references make feedback actionable.
-* Threads are temporary; permanent context belongs in the card, PR, or linked document.
-* State the request plainly, apart from any praise.
+* A comment is a message from one person to another, read mid-task and
+  without this conversation.
+* The shorter it is, the sooner it gets acted on: one sentence gets read in
+  full, three lines get skimmed, a paragraph waits for later.
+* A file and line reference is what turns feedback into an action.
+* A thread is temporary; lasting context belongs in the card, the PR or a
+  linked document.
 
 ## Desires
 
-* The reader sees **the claim, the evidence, and the required action** immediately.
+* The reader sees **the claim, the evidence and what to do** in one glance,
+  and it sounds like a teammate wrote it.
 
 ## Intentions
 
-### Content
+### Length
 
-* **State the claim, then the evidence.**
+* **One or two sentences, under 40 words.** Three lines is the ceiling, and a
+  comment that needs more is a card or a PR note.
+* **One comment, one point**, so it can be resolved on its own.
+* Keep the single piece of evidence that proves the claim, and the exact value
+  it hangs on; the rest of the reasoning goes to the card or the PR.
 
-Example:
+### Voice
 
-`This drops the retry on 401 (api/src/auth/retry.ts:88), so a wrong password locks the account after three tries.`
+* Write it as you would type it to the person: plain sentences, "you" and "we",
+  in the language of the thread.
+* Open on the claim and close on the ask. The claim carries its evidence in the
+  same sentence when it fits.
+* Say whether it blocks in plain words — "needs to change before merge", "not
+  blocking" — inside the sentence.
+* Plain text only: one paragraph, with labels like `Issue:` or `Fix:`, bold,
+  bullets and headers left for documents.
+* Put a one-line fix as the line itself, in a suggestion block or inline code.
 
-* Keep comments to **≤3 lines**; one line is preferred.
-* Use plain text. Move complex explanations to the PR, card, or document.
-* Add only what is new to the thread.
-* **One comment, one point** so it can be resolved independently.
+Report voice:
 
-### Uncertainty
+`**Issue:** The retry logic on line 88 has been modified. **Impact:** Users may get locked out. **Suggestion:** Consider restoring the previous behavior.`
 
-When unsure, state what would change the conclusion.
+Message voice:
 
-Prefer:
+`This drops the retry on 401 (api/src/auth/retry.ts:88), so a wrong password locks the account after three tries — needs to go back before merge.`
 
-`Unless another caller handles this case.`
+### Uncertainty
 
-Avoid vague hedging such as:
+When unsure, name what would change the conclusion:
 
-`Maybe consider possibly...`
+`Unless another caller handles this case.`
 
 ### Tone
 
-* Praise only when it identifies a specific useful decision.
-* Remove greetings, sign-offs, generic praise, and filler such as `thanks in advance` or `let me know`.
-
-### Card notes
+* Praise only a specific decision, and in a message of its own.
+* The comment starts on the claim and ends on the ask; greetings, sign-offs and
+  filler such as `thanks in advance` or `let me know` stay out.
+* Add only what is new to the thread.
 
-A card comment should contain only:
+### Replies
 
-* what changed since the card was written; or
-* what the reader must do next;
+* Answer in the first sentence: "You're right, fixed in `a1b2c3d`" is the whole
+  reply.
 
-with the relevant reference.
+### Card notes
 
-If the update needs multiple paragraphs, update the card body instead.
+A card comment carries only what changed since the card was written, or what
+the reader must do next, with the reference. When it needs more than one
+paragraph, update the card body instead.

ports/en/cursor/commands/comment.md

@@ -12,12 +12,13 @@ Process:
    If the relevant context is unavailable, say so and stop.
 2. Determine the kind: review comment, thread reply, card note, or direct
    message. If unclear, assume review comment and state the assumption.
-3. Write according to the reference:
-   - review comments state whether they block;
-   - replies answer in the first sentence;
-   - trivial fixes include the exact replacement or suggestion.
-4. Keep it ≤3 lines where possible. Preserve the anchor, claim, evidence,
-   and exact values; move broader reasoning elsewhere.
+3. Write it as a message to the person: one or two plain sentences, under 40
+   words, the claim first with its one piece of evidence, the anchor, and
+   whether it blocks in plain words. A reply answers in the first sentence; a
+   one-line fix arrives as the line itself.
+4. Cut it once more: drop every word the reader can act without, keeping the
+   anchor and the exact value. Past three lines, the reasoning moves to the
+   card or the PR.
 
 Output each comment in its own fenced block, ready to paste. Use four
 backticks when the comment contains a fence. For multiple comments, put the

ports/en/cursor/rules/concise-comment.mdc

@@ -7,54 +7,69 @@ alwaysApply: false
 
 ## Beliefs
 
-* Comments and replies are read mid-task and without this conversation.
-* File and line references make feedback actionable.
-* Threads are temporary; permanent context belongs in the card, PR, or linked document.
-* State the request plainly, apart from any praise.
+* A comment is a message from one person to another, read mid-task and
+  without this conversation.
+* The shorter it is, the sooner it gets acted on: one sentence gets read in
+  full, three lines get skimmed, a paragraph waits for later.
+* A file and line reference is what turns feedback into an action.
+* A thread is temporary; lasting context belongs in the card, the PR or a
+  linked document.
 
 ## Desires
 
-* The reader sees **the claim, the evidence, and the required action** immediately.
+* The reader sees **the claim, the evidence and what to do** in one glance,
+  and it sounds like a teammate wrote it.
 
 ## Intentions
 
-### Content
+### Length
 
-* **State the claim, then the evidence.**
+* **One or two sentences, under 40 words.** Three lines is the ceiling, and a
+  comment that needs more is a card or a PR note.
+* **One comment, one point**, so it can be resolved on its own.
+* Keep the single piece of evidence that proves the claim, and the exact value
+  it hangs on; the rest of the reasoning goes to the card or the PR.
 
-Example:
+### Voice
 
-`This drops the retry on 401 (api/src/auth/retry.ts:88), so a wrong password locks the account after three tries.`
+* Write it as you would type it to the person: plain sentences, "you" and "we",
+  in the language of the thread.
+* Open on the claim and close on the ask. The claim carries its evidence in the
+  same sentence when it fits.
+* Say whether it blocks in plain words — "needs to change before merge", "not
+  blocking" — inside the sentence.
+* Plain text only: one paragraph, with labels like `Issue:` or `Fix:`, bold,
+  bullets and headers left for documents.
+* Put a one-line fix as the line itself, in a suggestion block or inline code.
 
-* Keep comments to **≤3 lines**; one line is preferred.
-* Use plain text. Move complex explanations to the PR, card, or document.
-* Add only what is new to the thread.
-* **One comment, one point** so it can be resolved independently.
+Report voice:
 
-### Uncertainty
+`**Issue:** The retry logic on line 88 has been modified. **Impact:** Users may get locked out. **Suggestion:** Consider restoring the previous behavior.`
 
-When unsure, state what would change the conclusion.
+Message voice:
 
-Prefer:
+`This drops the retry on 401 (api/src/auth/retry.ts:88), so a wrong password locks the account after three tries — needs to go back before merge.`
 
-`Unless another caller handles this case.`
+### Uncertainty
 
-Avoid vague hedging such as:
+When unsure, name what would change the conclusion:
 
-`Maybe consider possibly...`
+`Unless another caller handles this case.`
 
 ### Tone
 
-* Praise only when it identifies a specific useful decision.
-* Remove greetings, sign-offs, generic praise, and filler such as `thanks in advance` or `let me know`.
-
-### Card notes
+* Praise only a specific decision, and in a message of its own.
+* The comment starts on the claim and ends on the ask; greetings, sign-offs and
+  filler such as `thanks in advance` or `let me know` stay out.
+* Add only what is new to the thread.
 
-A card comment should contain only:
+### Replies
 
-* what changed since the card was written; or
-* what the reader must do next;
+* Answer in the first sentence: "You're right, fixed in `a1b2c3d`" is the whole
+  reply.
 
-with the relevant reference.
+### Card notes
 
-If the update needs multiple paragraphs, update the card body instead.
+A card comment carries only what changed since the card was written, or what
+the reader must do next, with the reference. When it needs more than one
+paragraph, update the card body instead.

skills/concise/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "concise",
   "description": "English. The answer goes in the first sentence; cut preamble and process narration; keep every caveat that changes what the reader does. Governs chat replies, plans, decisions, commit messages, PR descriptions, cards, review comments and release notes — and the text written into code, from comments to screens. Forces its output style on while enabled, restates the style beside every prompt, and ships a SessionStart hook with self-update, a credit guard on the commands that publish text, fourteen commands — rewrite, pr, card, commit, comment, release, plan, decide, draw, status, handoff, audit, trim, woman — and an audit agent.",
-  "version": "1.89.0",
+  "version": "1.90.0",
   "author": {
     "name": "Ricardo Albuquerque",
     "url": "https://github.com/RicardoAlbuquerquet"

skills/concise/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "concise",
-  "version": "1.89.0",
+  "version": "1.90.0",
   "description": "English. The answer goes in the first sentence; cut preamble and process narration; keep every caveat that changes what the reader does. Under Codex it loads the core at session start, restates the style beside every prompt with the rule of the artifact being written, and denies a commit, PR, issue, card or file that would carry AI credit.",
   "author": {
     "name": "Ricardo Albuquerque",

skills/concise/commands/comment.md

@@ -1,5 +1,5 @@
 ---
-description: Draft a comment or message — claim first, evidence second
+description: Draft a comment or message — short, and written like one
 argument-hint: "[subject, optionally destination]"
 ---
 
@@ -17,12 +17,13 @@ Process:
    If the relevant context is unavailable, say so and stop.
 2. Determine the kind: review comment, thread reply, card note, or direct
    message. If unclear, assume review comment and state the assumption.
-3. Write according to the reference:
-   - review comments state whether they block;
-   - replies answer in the first sentence;
-   - trivial fixes include the exact replacement or suggestion.
-4. Keep it ≤3 lines where possible. Preserve the anchor, claim, evidence,
-   and exact values; move broader reasoning elsewhere.
+3. Write it as a message to the person: one or two plain sentences, under 40
+   words, the claim first with its one piece of evidence, the anchor, and
+   whether it blocks in plain words. A reply answers in the first sentence; a
+   one-line fix arrives as the line itself.
+4. Cut it once more: drop every word the reader can act without, keeping the
+   anchor and the exact value. Past three lines, the reasoning moves to the
+   card or the PR.
 
 Output each comment in its own fenced block, ready to paste. Use four
 backticks when the comment contains a fence. For multiple comments, put the

skills/concise/hooks/hooks.json

@@ -28,7 +28,7 @@
         "hooks": [
           {
             "type": "command",
-            "command": "bash \"$CLAUDE_PLUGIN_ROOT/hooks/turn-reminder.sh\" 'Style concise, this turn. Put the answer in the first sentence, with the result. Keep the whole reply within five lines, fences not counted, unless the user asks for more. A report on finished work fits in five lines too. Group the work, and let the details wait until asked. Use plain words and short sentences. Say one idea per sentence. Describe a technical thing by what it does. Keep its name only when the user will type, click or open it. Keep bad news, exact values and real uncertainty, each said once. Cut the preamble, the recap, the narration, the plan for your next steps and the tour of what you did. Asked what something is, answer in one sentence and stop. A choice the user makes gets its options side by side in a table, with your recommendation. In code, a comment says only what the code leaves unsaid.' .concise-no-turn-reminder ' card , cards ,tarefa,ticket, issue , issues |If this turn writes a card: it stands alone - the title opens with the area, then what changes; current state and expected state; numbered steps to reproduce a bug; every exact value; the open question named; a done criterion; no headers inside the body, and nothing only a reader of this conversation would understand.' 'coment,comment, revis, review|If this turn writes a review comment: three lines or fewer in one paragraph - the claim first, the evidence that matters, the anchor path in full, and whether it blocks the merge; no greeting, praise, sign-off, header, or note after it.' ' pr , prs ,pull request,merge request|If this turn writes a PR description: three sections under headers - what is solved, what was done, how to test - the problem first in the words of the reader, each deliverable said once, at most twenty-five lines of prose, every caveat kept, each command in its own fence with the output it prints, no internal name the reviewer never types or opens, and the exact path of every file the reviewer opens.' 'commit|If this turn writes a commit message: the title says what changed in the shape the log of the repository uses, and a body of six lines at most that is usually unnecessary.' 'desenh,diagram, draw|If this turn draws: one fenced block tagged text, under fifteen lines, no line past 72 characters, one glyph set throughout, every arrow labelled, each cost or note hanging off the box it belongs to, what you did not measure named as unmeasured, and no legend.'",
+            "command": "bash \"$CLAUDE_PLUGIN_ROOT/hooks/turn-reminder.sh\" 'Style concise, this turn. Put the answer in the first sentence, with the result. Keep the whole reply within five lines, fences not counted, unless the user asks for more. A report on finished work fits in five lines too. Group the work, and let the details wait until asked. Use plain words and short sentences. Say one idea per sentence. Describe a technical thing by what it does. Keep its name only when the user will type, click or open it. Keep bad news, exact values and real uncertainty, each said once. Cut the preamble, the recap, the narration, the plan for your next steps and the tour of what you did. Asked what something is, answer in one sentence and stop. A choice the user makes gets its options side by side in a table, with your recommendation. In code, a comment says only what the code leaves unsaid.' .concise-no-turn-reminder ' card , cards ,tarefa,ticket, issue , issues |If this turn writes a card: it stands alone - the title opens with the area, then what changes; current state and expected state; numbered steps to reproduce a bug; every exact value; the open question named; a done criterion; no headers inside the body, and nothing only a reader of this conversation would understand.' 'coment,comment, revis, review|If this turn writes a review comment or a message to someone: one or two plain sentences under forty words, typed the way a teammate would say it - the claim first with its one piece of evidence, the anchor path in full, and whether it blocks in plain words; one paragraph of plain text that opens on the claim and ends on the ask.' ' pr , prs ,pull request,merge request|If this turn writes a PR description: three sections under headers - what is solved, what was done, how to test - the problem first in the words of the reader, each deliverable said once, at most twenty-five lines of prose, every caveat kept, each command in its own fence with the output it prints, no internal name the reviewer never types or opens, and the exact path of every file the reviewer opens.' 'commit|If this turn writes a commit message: the title says what changed in the shape the log of the repository uses, and a body of six lines at most that is usually unnecessary.' 'desenh,diagram, draw|If this turn draws: one fenced block tagged text, under fifteen lines, no line past 72 characters, one glyph set throughout, every arrow labelled, each cost or note hanging off the box it belongs to, what you did not measure named as unmeasured, and no legend.'",
             "timeout": 5
           }
         ]