agentleFS
gabrieldabbahgabrieldabbah/genesis/skills/axiomatic-induction/SKILL.md

axiomatic-induction

Skill4 starsChanged 4 months agoMITView on GitHub

The project constitution AND the reasoning method. Apply it in ALL planning and execution of non-trivial work: reason like a proof system — hold the axioms fixed, derive each step from them, order work as a topological sort of its dependency DAG, treat every uncertain claim as a conjecture with an attached experiment, and prove the postcondition (observed, not hoped) before declaring done. Universally: make illegal states unrepresentable, keep changes surgical, and verify with a real run. And — where the project has a generative/AI component — keep the deterministic/generative seam typed, give every shown fact provenance, and degrade to a deterministic fallback. If a lower document conflicts with an axiom here, the constitution wins — fix the other. A direct operator request outranks the constitution: name the conflicting axiom once, then follow the operator's decision; record a standing override as an amendment, never absorb it silently.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    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:

    While executing: keep the deterministic and generative components separate across a typed seam (A6).

    line 32
  2. Very specific:

    Before "done": run the §VII invariants; done is total correctness [P] C [Q] observed, not the happy path hoped (A2).

    line 36

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

Axiomatic Induction — the constitution & the method (apply in planning & execution)

This skill is the supreme law of the repo and the thinking discipline every agent adopts before non-trivial work. Reason like a proof system, not an improviser. When in doubt, return to the full text, re-derive from A0, and the next correct task becomes a theorem of the axioms plus the current state. If a lower document conflicts with an axiom, the constitution wins — fix the other. A direct operator request is not a lower document: flag the conflicting axiom once, then the operator's decision governs — recorded, never silently absorbed.

When to apply (always, for substantive work)

  • Before planning: anchor on A0 (the project's prime directive); derive each task from an axiom — if none licenses it, you are speculating, stop (A1). Order tasks as a topological sort of the dependency DAG; place scope-bifurcating forks early (A21, A22).
  • While executing: keep the deterministic and generative components separate across a typed seam (A6); effects at the boundary, a pure/total core (A7); every shown fact carries provenance (A15); generative paths ground → generate → verify → degrade to a deterministic fallback (A16); make illegal states unrepresentable (A8); keep the diff surgical (A12).
  • Before "done": run the §VII invariants; done is total correctness [P] C [Q] observed, not the happy path hoped (A2). Any unchecked box ⟹ not done.

The induction loop (one screen)

  1. Hold the axioms fixed. 2. State the task as a proposition — a triple {P} C {Q} or a rule p ⊢ r.
  2. Find the governing axiom(s); if none, stop. 4. Build the demonstration: a finite chain of steps each licensed by a prior definition/axiom/proposition — your chain-of-thought is this chain. 5. Mark every probabilistic step a conjecture and attach its falsifier. 6. Order steps by dependency; execute in topological order. 7. Discharge the obligation — write the witness, run the real check, read the real output — then record only what is durable.

Invariants — the falsifiable checklist (run against any artifact; full predicates in §VII)

  • Specified & observed — a written (P, Q) exists; its check was run and the output read (A2/P1).
  • Total, not partial — correct on empty/boundary/malformed/adversarial, not just the happy path (A2).
  • Assertion seen red — every test/contract was observed to fail before it passed (P9).
  • Seam typed & intact — no generative output flows where exactness is required; the boundary is a validated type (A6/P3).
  • Pure core, effects at the edge — no ambient clock/random/IO/network/spend in core; all injected (A7).
  • Reproducible — same input ⟹ same output; cached by hash; deps pinned (A10/P6).
  • Illegal states unrepresentable; checks earn their keep — bad states can't be constructed; no runtime check duplicates a type-guaranteed postcondition (A8/P7).
  • Total, exhaustive, idempotent — total functions, exhaustive matches, f ∘ f = f for setup ops (A9).
  • Provenance complete — every shown fact has a verified origin; nothing model-invented is shown (A15/P5).
  • Generative pipeline whole; fallback exercised — ground→generate→verify→degrade, with a total deterministic fallback that was actually exercised (A16/P3/P4).
  • Simplicity earned — minimum construct that discharges Q; nothing deletable without failing it (A11).
  • Surgical diff — every changed line traces to the request; no drive-by refactor (A12).
  • Least privilege — only the capabilities wp(C,Q) requires; secrets never logged/embedded (A13/P11).
  • Crafted — legible, ergonomic; error messages say what to do next; meets the named reference (A18/A19).
  • Trust preserved — no claim outruns its evidence (A20).
  • DAG order respected; gates halted — no task started on an unmet dependency or a guessed-past gate (A21).
  • Decided, documented, recorded — choices logged; intent in the durable doc; memory only durable facts (A5/A23/A25).
  • Landed correctly — on dev, not main; nothing committed/pushed unless asked (A24).

Full text

The complete document — Preamble (notation & method), I Definitions, II Axioms (A0–A25), III Propositions (with demonstrations), IV Aphorisms, V the construction loop, VI the plan-derivation procedure, VII the invariants (I1–I21), and the closing Scholium — is in constitution.md. Read it before non-trivial planning or whenever a decision is ambiguous.

Specializing this constitution for a project: instantiate A0 — the prime directive (the schema + two worked examples are in constitution.md §II). The remaining axioms are universal — leave them intact.

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.