Keep review and issue thread replies concise

plugins/read-the-room/skills/make-it-make-sense/references/issue-trackers.md

@@ -6,5 +6,16 @@ Shape the requested artifact so another person can assess, prioritize, implement
 - **Bug description:** Give the current behavior, impact, evidence or reproduction, and expected behavior. Distinguish observation from inference.
 - **Work item description:** Give the context, intended outcome, constraints, and acceptance criteria supplied or directly implied by the request.
 - **Acceptance criteria:** Use observable completion conditions. Do not expand the requested scope with speculative edge cases.
-- **Comment or reply:** State the current outcome, new decision, evidence, blocker, and next action when each matters. Add only the context needed to assess or act on the update.
+- **Standalone comment:** State the current outcome, new decision, evidence, blocker, and next action when each matters. Add only the context needed to assess or act on the update.
 - **Status update:** State what changed, what evidence supports it, and what remains.
+
+## Thread replies
+
+Treat the parent comment as shared context. Add acknowledgment and only new information, usually in one or two natural sentences. Do not quote or paraphrase the report merely to confirm it. Repeat only the fragment needed to distinguish multiple findings, correct a misunderstanding, or explain a partial fix.
+
+- **Accepting:** Confirm agreement; add a decision or next action only when established. "Agreed." can be enough.
+- **Verifying a finding:** State verification and useful new evidence without repeating the reported mechanism or impact.
+- **Confirming a fix:** State what changed; include a supplied commit reference, relevant check result, or limitation when useful.
+- **Disagreeing or blocked:** Identify the unresolved point and supporting evidence. Make partial completion explicit: "The fix covers retries; cancellation still needs investigation," when those facts are supplied.
+
+Keep accepted, verified, fixed, and tested distinct. Use brief prose without mandatory labels, headings, bullets, praise, or sign-offs. Do not invent commitments or checks, or imply that replying authorizes posting, changing issue state, or resolving a thread.

plugins/read-the-room/skills/make-it-make-sense/references/version-control.md

@@ -5,12 +5,23 @@ Use the contract for the requested artifact:
 - **Commit:** Use a conventional single-line subject. Apply a required ticket prefix when repository instructions or the branch establish one. Add a body only for context a future maintainer cannot recover from the diff.
 - **Pull or merge request title:** State the delivered outcome in the repository's established form. Keep required ticket prefixes exact.
 - **Pull or merge request description:** Use short sections such as Summary, Verification, and Risks when relevant, with concise bullets for delivered behavior, necessary rationale, checks, and reviewer concerns. Follow repository templates; omit empty or unnecessary sections.
-- **Review comment:** Lead with the finding or requested change and whether it blocks. For findings needing explanation, use concise bullets for evidence, impact, and the requested action rather than several prose paragraphs. When responding to feedback, state the action taken and its result. Use a plain approval when there is no finding.
-- **Discussion reply:** Answer the point raised with the decision, evidence, fix, or remaining blocker.
+- **New review finding:** Lead with the finding or requested change and whether it blocks. For findings needing explanation, use concise bullets for evidence, impact, and the requested action rather than several prose paragraphs. Use a plain approval when there is no finding.
+- **Discussion reply:** Follow the thread-reply guidance below.
+
+## Thread replies
+
+Treat the parent comment as shared context. Add acknowledgment and only new information, usually in one or two natural sentences. Do not quote or paraphrase the finding merely to confirm it. Repeat only the fragment needed to distinguish multiple findings, correct a misunderstanding, or explain a partial fix.
+
+- **Accepting:** Confirm agreement; add a decision or next action only when established. "Agreed." can be enough.
+- **Verifying a finding:** State verification and useful new evidence without repeating the reported mechanism or impact.
+- **Confirming a fix:** State what changed; include a supplied commit reference, relevant check result, or limitation when useful.
+- **Disagreeing or blocked:** Identify the unresolved point and supporting evidence. Make partial completion explicit.
+
+Keep accepted, verified, fixed, and tested distinct. Use brief prose without mandatory labels, headings, bullets, praise, or sign-offs. Given a committed fix and passing regression test, "Fixed in `<commit>`. The regression test passes." is sufficient; replace the placeholder with the supplied reference. A reply does not authorize posting or resolving the thread.
 
 ## Structure
 
-- Prefer sections and bullets over long paragraphs in PR/MR descriptions and reviews. Keep one point per bullet; avoid turning paragraphs into long bullet items.
+- Prefer sections and bullets over long paragraphs in PR/MR descriptions and new review findings. Keep one point per bullet; avoid turning paragraphs into long bullet items.
 - Use tables when comparing alternatives, before/after behavior, or several checks with the same fields. Do not force narrative explanations or a single finding into a table.
 - Group multiple findings under descriptive headings. Keep a simple comment or reply to one or two sentences when extra structure would add noise.
 - Use brief prose only where connected reasoning makes the point clearer. Do not repeat the same information in prose, bullets, and tables.

plugins/read-the-room/tests/writing-scenarios.md

@@ -10,3 +10,17 @@ Use these fixed prompts when changing the writing policy. Compare the previous a
 | Procedure | Write instructions from these facts: set API_TOKEN to the token for the target account; run `client status`; expected output is `connected`; stop if the result is `unauthorized`. | Preserve exact literals, sequence, expected result, and stopping condition; direct actions with no invented setup. |
 
 Across all scenarios, check that brevity preserves necessary information, terminology stays consistent, and the voice remains respectful. For future compression, compare the actual startup payload size as well as the outputs. Automated tests cover hook loading and package validity, not these writing judgments.
+
+## Replies to existing findings
+
+Run each prompt as both an MR review-thread reply and an issue-tracker thread reply, using the relevant guide. The quoted parent is already visible to the reader. Prefer one or two natural sentences; assess meaning rather than exact wording.
+
+| Scenario | Prompt | Criteria |
+| --- | --- | --- |
+| Acceptance | Parent: "The retry loop resets the deadline, allowing the operation to exceed the timeout." You agree with the finding; no fix, check, or next action is established. Draft a reply. | Acknowledge without repeating the finding or promising work; do not claim verification or a fix. |
+| Verified finding | Same parent. A reproduction test confirmed the finding. Draft a reply. | State the new verification without re-explaining the mechanism or claiming a fix. |
+| Completed fix | Same parent. Commit `abc1234` fixes the deadline handling; the regression test passes; integration tests were not run. Draft a reply. | Give the commit and evidence limits without repeating the parent or implying all tests passed. |
+| Partial fix | Parent: "Retries and cancellation both exceed the timeout." Retry handling is fixed; cancellation still needs investigation. Draft a reply. | Identify the covered and unresolved parts; limited repetition disambiguates the partial result. |
+| Disputed finding | Parent: "The patch removes timeout enforcement." Inspection shows enforcement moved to the shared wrapper; no runtime check was run. Draft a reply. | Correct the misunderstanding with the new evidence and its limit, without recapping the accusation or claiming runtime verification. |
+
+Replies must preserve the distinction between agreement, verification, implementation, and testing. They must not invent ownership, deadlines, or thread resolution. New findings and standalone summaries still need enough context to be understood independently.