agentleFS
ratacatratacat/ratacats-skills/skills/lemma/SKILL.md

lemma

Skill9 starsChanged 4 months agoMITView on GitHub

Answer a hard question by building a persistent graph of atomic claims, each given a 0-1 credence by Jev from a shared evidence ledger. Keeps false and unexamined claims. Use for research questions, codebase questions, hypothesis testing, or any claim that needs careful, skeptical support.

  • Reads credentials

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Look for evidence against a claim before evidence for it.

    line 24
  2. Distinctive:

    Ask how much more expected the evidence is if the claim is true than if a rival is true.

    line 25
  3. Distinctive:

    Prefer a physical find, a primary document, or a measurement over a summary of one.

    line 28
  4. Distinctive:

    Do not score claims in your head.

    line 31
  5. Very specific:

    Next: Run python3 lemma.py next <name>.

    line 83
  6. Distinctive:

    Report: When you stop, show the graph.

    line 84
  7. Distinctive:

    expand: add claims the graph is missing: premises, rivals, or a link for an orphan claim.

    line 90

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Lemma

A question becomes a pyramid of claims. The root is the claim we want to settle. Each claim below it holds the root up or pulls it down. Evidence lives in its own ledger and links to claims. Jev gives each claim one number, its credence. The agent finds evidence, splits claims, and links them. Nothing is deleted.

Stance

  • You do not know the answer. Act as if you do not.
  • "Experts say X" is evidence that experts say X. It is not evidence of X. Record who says it and what they could observe.
  • Look for evidence against a claim before evidence for it.
  • Ask how much more expected the evidence is if the claim is true than if a rival is true. Evidence that every rival also predicts is weak.
  • Compare with a base rate. "Only 2 kings were found in their pyramids" means little until you know how often kings are found in tombs that are certainly tombs.
  • To state a rate, count the cases into one tally evidence item. Jev weighs examples; it does not count them.
  • Prefer a physical find, a primary document, or a measurement over a summary of one.
  • Many claims will never be proven. A credence is the result, not a step toward proof.
  • A false claim is a result. Keep it. An unexamined claim is a gap. Name it.
  • Do not score claims in your head. Jev scores. You gather, split, and link.

Graph

File: ~/.lemma/<name>.json (set LEMMA_HOME to change the folder).

{
  "name": "pyramids-tombs",
  "question": "Were the pyramids used as tombs?",
  "root": "n0",
  "claims": {
    "n0": {"text": "...", "evidence": [{"id": "e1"}]}
  },
  "evidence": {
    "e1": {"source": "citation or URL", "says": "...", "origin": "the underlying source, e.g. Lehner 1997", "kind": "find|primary|measurement|secondary|testimony", "access": "how the source could know this"}
  },
  "edges": [{"from": "n1", "to": "n0", "type": "required_by"}]
}
  • A claim can be true or false. Write a question as the claim that would answer it.
  • Say "as a rule" or "some" when you mean it. A claim about every case falls to one exception.
  • To reword a claim, push the old text onto its was list. Do not delete it.
  • One evidence item is one finding from one source. Link it to every claim it bears on.
  • origin names the underlying source, not the website. A Wikipedia page that summarizes Lehner has origin Lehner. next warns when half the evidence under a claim shares one origin.
  • Edge types, read from <type> to:
    • required_by: if from is false, to falls. Code caps to at the credence of from. Use it only for a necessary premise that a rival disputes.
    • sufficient_for: if from is true, to is true. Code raises to to at least the credence of from. Use it for "one case proves it".
    • supports, undermines: evidence-like weight. Jev weighs these.
    • Rival hypotheses link to the root with undermines.
  • A claim can have many parents. The graph is a DAG, not a tree.

Credence

One number from 0 to 1. 0 = established false, 0.5 = no lean, 1 = established true. A claim without a judgment shows open.

  • Leaf claims: Jev scores the claim from its own evidence. Thin or second-hand evidence cannot reach the ends.
  • Parent claims: code computes the number. Nobody asks Jev the parent question directly.
    1. Jev scores the parent from its own evidence only (local).
    2. Jev gives each supports or undermines edge a weight from -1 to 1: how the child would bear on the parent if true. A child that a rival also predicts gets about 0.
    3. Each child adds weight x log-odds(child), only when the child leans true. A false supporting child adds nothing.
    4. Children whose evidence shares an origin count as one voice (their mean).
    5. Halving: in each direction the strongest origin counts in full, the next half, the next a quarter.
    6. required_by caps the result; sufficient_for sets a floor.
  • judged.jev keeps Jev's own direct judgment for comparison. show prints it when it differs by 0.15 or more. A large gap means an edge weight or the rule needs a look.

Each evidence link also gets bears, from -1 (strongly undermines) to 1 (strongly supports).

Loop

  1. Frame. Write the root claim and the strongest rivals. Link them. Settling the root must answer the question as asked. Check for a shift between intent and outcome, possible and actual, some and all, or one case and the rule. next prints the question above the root on every loop so drift stays visible.
  2. Next. Run python3 lemma.py next <name>. It prints the shape of the graph and a ranked list of steps. Do step 1. Run next again. Repeat.
  3. Report. When you stop, show the graph. List what is probably true, what is probably false, and what is still open.

next gives four actions:

  • research: find evidence for a claim. Search for evidence against it first. Prefer a find, a primary document, or a measurement. Read sources yourself; do not trust search summaries.
  • break down: split a claim into smaller claims below it. The atomic score is a hint. You decide when a claim is small enough: one observation or one source could settle it.
  • expand: add claims the graph is missing: premises, rivals, or a link for an orphan claim.
  • judge: get a new credence from Jev after the evidence or the claims below it change.

Ranking: judge first (deepest claims first), then by leverage on the root and closeness to 0.5. required_by passes full leverage, sufficient_for passes the room its parent has left to rise, supports and undermines pass half. You can do a different step if you have a reason. Say what the reason is.

Commands

lemma.py is in this skill's folder.

python3 lemma.py next <name> [k]   # graph shape and the top k steps (default 5)
python3 lemma.py judge <name> <id> # one Jev call: credence, atomic, and bears for each linked evidence item
python3 lemma.py show <name>       # the pyramid, from the root down
python3 lemma.py explain <name> <id> # what each child added to a parent

Needs TYPESAFE_API_KEY. For large graphs, judging many claims in parallel with Python's ThreadPoolExecutor is a possible future step.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.