Add pattern #26 for replies that re-explain shared context (#269)

[Kutomore]

Fixes #269.

Problem

Humanizer can strip every sentence-level tell from a conversational reply and still leave it sounding like a generated technical memo. The reply in #269 restates the problem, walks through the diagnosis, proves the investigation with a query and QA counts, and only then reaches the actual decision. Every sentence is fine on its own, so the current patterns do not catch it. The issue author's hand-written version was less than half the length: the decision, plus the one reason it was out of scope.

The gap is that "add something the reader did not already have" was scoped to the text being rewritten. In a reply, most of what a model re-establishes is already shared by the other person in the thread.

Change

• Core rule extended. "Every sentence you keep must add something the reader did not already have" now reads "...from earlier in the text or from the conversation around it."
• New section F, pattern feat(skill): Add SOTA prompting improvements #26, "Re-explaining what the reader knows." Watch for a short reply that restates the problem, walks the diagnosis, and lays out the evidence before the decision. Keep the decision and the least reasoning that supports it. Cut background the reader gave you, steps toward a conclusion no one questions, and proof of a claim both sides accept. Keep a fact the reader does not have, a link they need, and enough reasoning to show why the decision follows.
• Scoped narrowly. The section intro says to act only when the surrounding conversation is visible; without it, ask or leave the text alone. It does not apply to standalone writing.
• Synced the README table, "How it works" line, pattern count, and version history. Updated the section count in AGENTS.md. Bumped to 3.1.0.

I considered folding this into pattern #5 or the workflow rather than adding a pattern, per AGENTS.md. It did not fit: every existing pattern reads the text in isolation, and this one needs the thread. A new short section keeps that difference explicit and avoids renumbering 1 through 25.

Validation

Ran the updated skill against the over-explained reply from the issue, with the context that it is a reply in a PR review thread where the reviewer already flagged the code as a workaround.

Tells marked: #26 (the reviewer already knows the bug; the reply re-derives the fix location, includes a backfill query and "123 events / 6 projects" as proof, and puts the decision second to last).

Final rewrite:

Yeah, agreed, this is a workaround. The proper fix is in MergeService, which is shared and not Client A specific, and it needs a backfill for the projects that already have the wrong pipeline. That is more than this PR should take on, and the fallback here is fine to leave in for now.

I would rather keep this PR Client A specific and open a separate ticket for the MergeService fix and the backfill. Let me know if that works.

That is close to what the issue author wrote by hand: the decision and the reason it is out of scope, without the diagnosis walk-through, the query, or the QA counts. On standalone prose with no thread, #26 does not fire.

Checks run: python3 scripts/validate-package.py, npx skills add . --list, claude plugin validate .. All pass. SKILL.md is 392 lines.

🤖 Generated with Claude Code

https://claude.ai/code/session_013xPaas6J1hZVWUR1LvNMbg