agentleFS
ryanmacleanryanmaclean/skills/lore/SKILL.md

lore

Skill1 starsChanged 51 days agoMITView on GitHub

Agent-facing discovery + query interface to fleet_ledger (Qdrant long-term memory). Verbs query, get, add, list, help. Use when you need to check "what do we know about X", "have we seen Y before", "did anyone catalog Z", or "lookup in fleet memory".

  • Reads credentials

12 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 0 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 11 edited versions we read keep these.

  • 0

    Distinctive

    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
  1. Very specific:

    Run lore help for the live JSON manifest.

    line 24
  2. Very specific:

    If run twice with the same (kind, subject), the second run returns idempotent_replace:true and count_before == count_after.

    line 87
  3. Very specific:

    Never change. Changing it means every lore add stops being idempotent against prior records.

    line 127
  4. Very specific:

    3-strikes cleanup convention: when an agent stops at 3-strikes, the canonical cleanup is lore add --kind blocker --subject …

    line 138

“Common” is measured: kept by at least 6 in 10 of the 11 edited versions of this file we could read. “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

lore — fleet_ledger discovery + query

Fleet institutional memory. Reads and writes fleet_ledger at 10.0.3.206:6333 (Qdrant, 1024-dim Cosine, arctic-embed2 via Ollama at localhost:11434). AX-first: structured JSON in, structured JSON out.

Why this skill exists

Today's context-orchestration-fleet-ledger decision named fleet_ledger as durable long-term memory. Every sub-agent dispatched was hand-rolling ledger-upsert.py or raw curl. lore is the one verb surface. All five verbs return schema_version: "v1" so breaking changes are detectable.

Verbs

Run lore help for the live JSON manifest. Summary:

VerbPurposePrimary flags
querySemantic search (embeds & kNN)--top-k N --min-score F --kind k1,k2
getExact lookup by (kind, subject)--kind K or kind:subject
addUpsert (idempotent UUIDv5 replace)--kind --subject --text --data
listScroll, metadata only (no text)--kind --since --limit
helpSelf-describing manifest--verb V to drill down

Example — query

Input:

lore query "fb-vm-24 disk" --top-k 3

Output (truncated):

{
  "schema_version": "v1",
  "verb": "query",
  "count": 3,
  "results": [
    {"id":"...", "score":0.82, "kind":"decision",
     "subject":"fb-vm-24-disk-fix", "ts":"2026-04-15T...",
     "text_preview":"fb-vm-24 disk grown from 6 to 24 GiB ...",
     "data":{...}}
  ]
}

Zero-result form is actionable, not silent:

{"schema_version":"v1","verb":"query","count":0,"results":[],
 "suggestion":"try lore list --kind=decision --since=2026-04-01"}

Example — get

lore get decision:fb-vm-24-disk-fix
# or
lore get fb-vm-24-disk-fix --kind decision

Returns the full payload as {schema_version, verb:"get", found:true, record:{id,kind,subject,...}} or {found:false, how_to_fix:"try lore query \"fb-vm-24 disk\""}.

Example — add (idempotent)

lore add --kind decision --subject my-decision-2026-04-15 \
  --text "We chose X over Y because ..." \
  --data '{"chose":"X","over":"Y"}'

Output:

{"schema_version":"v1","verb":"add","id":"<uuid5>",
 "count_before":55,"count_after":55,"idempotent_replace":true}

If run twice with the same (kind, subject), the second run returns idempotent_replace:true and count_before == count_after. The calling agent uses this to de-dupe its own activity.

Example — list

lore list --kind decision --since 2026-04-15 --limit 20

Output:

{"schema_version":"v1","verb":"list","count":N,
 "records":[{"id":"...","kind":"decision","subject":"...","ts":"..."}, ...]}

No text field — list view is metadata only by design.

Example — help

lore help            # full manifest (all 5 verbs)
lore help --verb query   # just query's schema

Returns JSON, not prose. Canonical discovery entrypoint.

Errors (structured, always)

{"schema_version":"v1","error":"QDRANT_API_KEY env var not set",
 "how_to_fix":"export QDRANT_API_KEY=... (see ~/.zshrc)"}

Exit codes: 0 success, 2 user error (bad flags / missing env), 3 upstream error (qdrant/ollama down), 4 not-found.

Gotchas (hard rules)

  • Canonical UUIDv5 namespace: 6b1f2c3d-4e5f-5a6b-7c8d-9e0f1a2b3d4e. Never change. Changing it means every lore add stops being idempotent against prior records. The key string is "{kind}:{subject}" (no whitespace, lowercase kind).
  • Key shape (kind, subject): subject is the human-memorable slug, kind is one of attempt|decision|probe|gem|blocker|workaround. Same pair → same id.
    • attempt — past try with outcome + evidence
    • decision — standing policy / architectural choice with rationale
    • probe — reusable claim→verify pattern (claim_shape + probe_cmd + expected)
    • gem — session conversation signal (user correction)
    • blocker — a workstream hit a wall; successor agents retrieve before attempting
    • workaround — graceful-degradation pattern for when the normal path isn't available
  • 3-strikes cleanup convention: when an agent stops at 3-strikes, the canonical cleanup is lore add --kind blocker --subject <workstream>-<date> --text @STOP-REPORT --data '{"status":"blocked","attempted":[...],"next_strategies":[...]}'. Successor agents SHOULD lore query <workstream> before re-deriving.
  • gem excluded from query by default: gems are raw corrections ("stop doing X") with noisy language; exclude unless explicitly asked with --kind gem or --kind attempt,decision,probe,gem.
  • Score floor 0.4 default: arctic-embed2 cosine scores below 0.4 are near-noise. Tune via --min-score. Don't read tea leaves below 0.3.
  • **Ollama endpoint: the runnable tries localhost:11434 first. embedding fails, set LORE_OLLAMA_URL=http://10.0.3.207:11434 (fleet embedder on qnas macvlan). 10.0.3.207:11434 via LORE_OLLAMA_URL env.
  • No secrets in code: QDRANT_API_KEY via env only. Runnable refuses with structured error if missing.

Cross-refs

  • Design doc: /Users/studio/rust-town/.planning/fleet-ledger-design-2026-04-15.md
  • Architectural decision record: fleet_ledger entry context-orchestration-fleet-ledger
  • Seed script: /Users/studio/rust-town/fleet-ops/scripts/fleet-ledger-ingest.nu
  • Related skills: fleet-eval (probe runner), proveryay (claim verifier), qcli (low-level Qdrant CLI — all collections)

Files

  • Skill doc: /Users/studio/.claude/skills/lore/SKILL.md (this file)
  • Runnable: /Users/studio/.local/bin/lore (Python 3, MIT licensed)
  • Self-test: lore help | python3 -m json.tool (must parse as JSON)

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.