evidence-content
Skill0 starsChanged 49 days agoMITView on GitHub
Draft content from a provenance-tagged claim ledger when factual support and approval boundaries matter.
In this repository9 other files it gives its agents.
- content-qaSkill
- eval-engineering-liteSkill
- failure-analyzerSkill
- faq-builderSkill
- meeting-to-actionsSkill
- project-handoffSkill
- requirement-clarifierSkill
- research-synthesizerSkill
- workflow-plannerSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Use for public, sales or technical content where a source map is needed and invented proof would be harmful.
- Distinctive: line 30
Run a final contradiction/privacy check and send uncertain claims to a named human reviewer.
- Very specific: line 34
If a material statement lacks support, remove it or label it explicitly as a hypothesis.
- Very specific: line 42
Run python3 tests/validate.py from the repository root to check this skill's contract and example provenance.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Evidence Content
Purpose
Turn approved claims into channel-ready copy while exposing unsupported or provisional claims.
When to Use
Use for public, sales or technical content where a source map is needed and invented proof would be harmful.
Inputs
claims: [{text,source_id,verification_state,scope}], audience, channel, optional style_rules[].
Outputs
draft, claim_map[], uncertain_claims[], review_state.
Workflow
- Classify each claim as verified, source-limited, hypothetical or unsupported.
- Exclude unsupported metrics, customer outcomes and authority claims from the draft.
- Draft for the audience without strengthening the claim beyond its source scope.
- Map each material statement back to a source ID and retain important qualifications.
- Run a final contradiction/privacy check and send uncertain claims to a named human reviewer.
Failure Handling
If a material statement lacks support, remove it or label it explicitly as a hypothesis; set review_state=BLOCKED for unapproved high-impact claims.
Example
synthetic_unverified: a fictional feature claim cites spec-1; an adoption number without a source is omitted.
Tests
Run python3 tests/validate.py from the repository root to check this skill's contract and example provenance. This is a structural test, not model-quality evidence.
Limitations
The skill structures evidence but does not prove a source is authentic, licensed or up to date.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.