Evidence-Based Replies
Use this skill when the user wants to:
- compare someone's claim to a research paper, benchmark, article, or repo README
- draft a reply that corrects a misunderstanding of the evidence
- separate "the source supports X" from "the source does not support Y"
- turn a source-comparison into a Reddit/X/forum-ready response
Core principle
Do not stop at summarizing the source. The deliverable is usually the distinction:
- what the source actually establishes
- what stronger conclusion the other person is trying to import into it
- why that leap does not follow
If the user is asking for a reply, the misunderstanding of the evidence must be addressed explicitly, not left implicit.
Default workflow
- Read the conversation/claim carefully.
- Extract the specific proposition the other person is asserting from the source.
- Read the cited source.
- Split findings into:
- Supported by the source
- Not established by the source
- Reasonable but unproven extrapolations
- Compare the source type:
- empirical paper
- benchmark paper
- opinion/design README
- repo guidance / author doctrine
- Draft the response around the distinction, not around vague disagreement.
Required output shape
When explaining the comparison, prefer this structure:
- "The paper/source does show ..."
- "What it does not show is ..."
- "That is the step I disagree with."
- "So my criticism is not X; it is Y."
This pattern prevents straw-manning and keeps the correction precise.
Writing guidance for this user
the user prefers concise, practical responses. For forum replies:
- lead with the misunderstanding, not with throat-clearing
- avoid generic "both sides have a point" filler
- make the inferential gap explicit
- distinguish directionally true claims from overclaims
- prefer operational language over academic hedging
If he says a draft "needs to address the misunderstanding of the research," revise around the evidentiary gap immediately.
Pitfalls
- Do not equate "source says style matters" with "source proves this specific implementation is better."
- Do not let a repo README or manifesto carry the evidentiary weight of a paper.
- For software/config claims, prefer current upstream docs and source code over stale third-party guides; explicitly label stale or unverified config paths instead of treating all cited paths as current.
- When fact-checking a complaint, distinguish: true current behavior, stale terminology, fair UX criticism, and rhetorical overclaim. Do not collapse those into a simple true/false verdict.
- Do not answer only at the concept level if the user needs a postable reply.
- Do not bury the key distinction in paragraph four.
- Do not over-hedge once the inferential error is clear.
Heuristic: evidence ladder
From strongest to weakest:
- direct empirical finding in the cited paper
- constrained implication from that finding
- plausible implementation guess
- repo philosophy / author preference
Label which rung the person's claim sits on.
Forum-ready reply recipe
For Reddit/X/forum use:
- Sentence 1: identify the misunderstanding.
- Sentence 2: state what the paper actually supports.
- Sentence 3: state what it does not support.
- Sentence 4+: tie back to the concrete artifact under debate.
references/research-overclaim-patterns.md— session-derived example of correcting a paper-based overclaim in a SOUL.md / persona-file debate.
Public support files
references/research-overclaim-patterns.md


