capture-claim
Skill1 starsChanged 4 months agoMITView on GitHub
Capture a research claim and its scoped supporting evidence in a RigorGraph project. Use when recording a theorem target, literature result, empirical observation, benchmark result, synthesis, source, dataset, computation, proof packet, or human review.
In this repository4 other files it gives its agents.
- AGENTS.mdAGENTS.md
- adversarial-verifySkill
- release-auditSkill
- research-intakeSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 2 are distinctive, and 4 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.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 8
Read rigorgraph.yaml, current claims, evidence, and verifications.
- Very specific: line 13
Create evidence JSON first and run rigorgraph evidence add.
- Very specific: line 14
When the input is a versioned RigorGraph evidence bundle, preserve it with rigorgraph evidence import BUNDLE.json --claim CLAIM_ID instead …
- Very specific: line 15
Run rigorgraph audit. If it fails, report the exact issue codes and leave the epistemic status unchanged.
- Distinctive: line 17
Use localized result headings:
- Distinctive: line 26
Do not invent a locator, digest, author, verifier, experimental condition, or dependency.
≈ “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
Capture a claim
- Read
rigorgraph.yaml, current claims, evidence, and verifications. - Reply in the explicit or configured language: English, Traditional Chinese, Simplified Chinese, or Japanese. Keep claim statements, quotations, formulas, identifiers, and source titles in their original language.
- Classify the claim as
formal,literature,empirical,benchmark, orsynthesis. - State the exact scope. For a source, record its URI and precise locator. For a local artifact, record a project-relative path and SHA-256 digest.
- Classify each evidence record as
proof,source,dataset,computation,benchmark_run, orhuman_review. Never relabel numerical evidence as proof. - Create evidence JSON first and run
rigorgraph evidence add. Then create aDRAFTorPROPOSEDclaim JSON and runrigorgraph claim add. - When the input is a versioned RigorGraph evidence bundle, preserve it with
rigorgraph evidence import BUNDLE.json --claim CLAIM_IDinstead of rewriting producer metadata. Bundle hashes record observed bytes; they do not prove producer identity, runner authenticity, or correctness. - Run
rigorgraph audit. If it fails, report the exact issue codes and leave the epistemic status unchanged.
Use localized result headings:
| en | zh-TW | zh-CN | ja |
| Claim recorded | 已記錄命題 | 已记录命题 | 主張を記録しました |
| Evidence class | 證據類別 | 证据类别 | 証拠区分 |
| Supported scope | 支持範圍 | 支持范围 | 支持される範囲 |
| Remaining gap | 剩餘缺口 | 剩余缺口 | 残るギャップ |
Do not invent a locator, digest, author, verifier, experimental condition, or dependency.
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.

