Evidence boundary review

Skill pinkstrokes/self-distillation/skills/evidence-boundary-review

Reusable agent skills for distilling narrow human capabilities into tested behavior

Install

npx -y skills add pinkstrokes/self-distillation --skill evidence-boundary-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

28 days oldThe repository was created 28 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when reviewing whether claims are supported by provided evidence, especially paper claims, benchmark conclusions, rebuttal language, verification claims, evidence grades, unsupported inferences, overclaims, missing evidence, or cross-domain contamination.

SKILL.md

3.0 KB, as published. Nobody here has run it

Evidence Boundary Review

Judge what a claim is allowed to say from the evidence actually provided. The core rule is claim strength must not exceed evidence strength.

Workflow

Extract the exact claim.
List the evidence explicitly provided.
Classify support using exactly: Directly supported, Partially supported, Plausible but not established, Unsupported, or Contradicted.
Identify boundary issues: overclaim, causal leap, scope expansion, benchmark overgeneralization, missing evidence, cross-domain contamination, or artifact coexistence mistaken for validation.
Rewrite the claim at the strongest allowed level.
Name what remains unproven, scaled to the claim's risk.

For directly supported narrow claims, list only the nearest likely unsupported extensions. Do not enumerate every theoretical gap. For broad, causal, benchmark-generalized, or deployment-safety claims, list the missing evidence more fully.

Allowed wording should be concise and ready to reuse. For causal downgrades, state the observed association plus missing causal support in one clear sentence.

Output Contract

Return these fields:

Claim:
Evidence:
Support level:
Boundary violation:
Unsupported items:
Allowed wording:
Original claim status:
Allowed wording status:
Verdict:

Use exact labels only. Status and verdict fields must be one of: complete, partial, fail. Put explanations in narrative fields, not label fields.

Red Lines

Do not invent evidence.
Do not hide missing evidence behind confident phrasing.
Do not treat plausible inference as established fact.
Do not convert correlation, author intent, one example, or one benchmark into a general causal claim.
Do not use proved, demonstrated, validated, or established unless the evidence directly supports that strength.
Do not mix unrelated project, domain, or benchmark concepts unless the input explicitly links them.
Do not treat similar terminology, parallel artifacts, or coexisting checklists/logs as validation without an explicit bridge, mapping, or application record.

Verdict Rules

complete: original claim is directly supported within scope.

partial: non-high-stakes original claim is too broad, but evidence supports narrower allowed wording and no P0 fail condition applies.

fail: unsupported original claim with no supported replacement; high-stakes readiness/safety not established; fabricated evidence; causal proof overclaim; or cross-domain validation claim.

Before Final Answer

Check:

Is every strong verb justified by direct evidence?
Is the scope limited to the tested setting?
Are missing items named at proportional detail?
Is allowed wording concise and weaker when evidence is weak?
Are labels exact?