Skip to content
rematch

The profile

What rematch keeps on one machine should load on the next. The profile is a git repo at ~/.rematch/profile/ holding your omp setup, with every piece linked back where omp and rematch read it.

What it holds

Section titled “What it holds”
  • Directoryprofile/
    • Directoryskills/
      • Directory<name>/ kept skills and adopted hand-written skills
        • …
    • Directoryagents/
      • <name>.md kept and adopted agents
    • Directoryfragments/
      • <name>.md AGENTS.fragment.md of kept agents
    • Directoryhooks/
      • <id>.ts approved hooks
    • Directoryconfig/
      • policy.json
      • roles.yml the model behind each role, per machine
      • Directorydomains/
        • <branch>.yml each branch’s domain.yml
    • Directoryimprover/
      • <edited file> improver prompts you edited
    • profile.json

Hand-written skills and agents enter as pinned entries: measured like any entry, never moved, replaced or retired by the loop.

What stays per machine

Section titled “What stays per machine”
Stays Why
the ledger, its journal and counters counts belong to the machine that observed the sessions
the lake and its indexes history travels through the lake, not the profile
staging/, drafts/, archive/, predecessors/ provisional and retired state
traces, pending files, jobs per-session data
credentials and omp’s own config.yml model choices travel only through roles.yml
rematch.json and EXPERIENCE.md inside each skill written from this machine’s ledger (absolute paths, its state)

Kept elsewhere, loaded here

Section titled “Kept elsewhere, loaded here”

Every profile/skills/<name>/ with a SKILL.md is linked into ~/.rematch/skills/ when no ledger entry holds that name. So a skill kept on another machine loads here like this machine’s kept entries.

  • It is counted only by the machine whose ledger holds the entry.
  • A hook linked from another machine runs only where its entry is known.
  • Built-in entries have per-machine ids and are approved per machine.

How it syncs

Section titled “How it syncs”
  • Each omp process syncs in the background at its first session start: commit, pull with rebase, relink, push. It is bounded, and offline is fine.
  • Keeps land in the profile; rematch profile install-launchd adds a timer.
  • A file changed on two machines stops the sync with the tree clean, and a digest line names the file.

See also

Section titled “See also”