memory-team
Skill19 starsChanged 3 months agoMITView on GitHub
Guided setup for sharing moflo's durable learnings through a git-tracked artifact — for a whole TEAM on one repo, OR for one person across several MACHINES (a team of one). Use when the user says "share learnings with my team", "commit our moflo memory", "sync memory across my laptop and desktop", "set up memory.team_artifact", "auto-export learnings on every PR", or "learnings.jsonl keeps conflicting". Installs a pre-commit hook so the artifact rides along in every commit. An existing learnings.jsonl moves to the conflict-free layout automatically. For many worktrees on ONE machine, use /memory-worktree.
- Commits and pushes
In this repository30 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- src/CLAUDE.mdCLAUDE.md
- communeSkill
- connector-builderSkill
- distillSkill
- divineSkill
- eldarSkill
- flflSkill
- flo-simplifySkill
- floSkill
- floSkill
- guidanceSkill
- healerSkill
- luminariumSkill
- meditateSkill
- memory-optimizationSkill
- memory-patternsSkill
- memory-worktreeSkill
- optimize-learningsSkill
- perf-auditSkill
- publishSkill
- quickenSkill
- reasoningbank-intelligenceSkill
- reset-epicSkill
- spell-builderSkill
- spell-scheduleSkill
- test-gapsSkill
- vector-searchSkill
- verifySkill
- wardSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 1 is distinctive, and 3 are 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.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Very specific: line 56
Read the project-root moflo.yaml and add/merge under memory: — preserve existing keys:
- Distinctive: line 162
If you're solo and would rather not commit learnings, carry a binary artifact instead.
- Very specific: line 176
Don't: add a merge=union attribute for the artifact — GitHub ignores it, and the directory layout does not need it.
- Very specific: line 179
Don't: use chmod / mkdir / rm in shell steps — Windows lacks them on PATH.
≈ “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
/memory-team — Share Learnings via a Git-Tracked Artifact
Wires up memory.team_artifact: a diffable directory (.moflo/shared/learnings/, one JSON file per
entry) that lives in the repo, reviewed like any other change. One file per entry means two PRs that each
add a learning never conflict — on GitHub or locally. Teammates git pull it and their next session
auto-imports the merged learnings; each entry is stamped with its git author. This skill also installs a
pre-commit hook so the artifact is re-exported and staged on every commit — the learnings ride along
in each PR with zero effort.
One mechanism, two audiences. A team and one person across machines are the same problem — push the durable slice through git. This skill covers both; the only difference is whether anyone else is on the other end. (Prefer a private, non-git file for your own machines? See "Advanced" at the bottom —
flo memory syncmoves a binary artifact that keeps embeddings verbatim.)
Arguments: $ARGUMENTS — pass --solo to skip team-oriented wording (still identical setup).
When to use
- "share learnings / memory with my team"
- "commit our moflo knowledge to the repo"
- "sync memory between my laptop and desktop"
- "auto-export the learnings on every PR / commit"
- "set up
team_artifact" - "
learnings.jsonlconflicts on every PR" → Step 2b (it migrates itself)
For many worktrees on one machine, that's a shared local store, not git — use /memory-worktree.
Procedure
Step 0 — Memory first (gate requirement)
mcp__moflo__memory_search { query: "team_artifact learnings jsonl git share import session-start", namespace: "guidance" }Step 1 — Confirm this is the git path
- Team on one repo, or one person across machines who both push to the same repo? → correct skill.
- Many worktrees on one machine, no cross-machine need? → redirect to
/memory-worktree. - A private synced file (Dropbox/USB), no git? → point at the Advanced section (
flo memory sync).
Step 2 — Set the config
Read the project-root moflo.yaml and add/merge under memory: — preserve existing keys:
memory:
team_artifact: .moflo/shared/learnings/An existing team_artifact: .moflo/shared/learnings.jsonl line is fine as it is — a .jsonl path names
the directory beside it, so there is nothing to change.
Step 2b — Existing learnings.jsonl setups migrate themselves
Do nothing. The old single file conflicted whenever two branches added neighbouring keys, and GitHub
ignores merge drivers, so merge=union never helped on the PR page. The next team-export — normally the
pre-commit hook — moves it:
| Moment | What happens |
| Session start before the first export | The old file is still imported, so nothing is lost |
Next team-export | Every entry is copied into .moflo/shared/learnings/, the .jsonl is deleted, and both changes are staged |
A teammate's older moflo re-creates the .jsonl | The next export folds it in and deletes it again |
Existing hooks keep working: when the artifact is git-tracked, team-export stages it itself. Refresh an
old hook block to the one in Step 4 anyway, so it names the directory.
Step 3 — First export (creates + tracks the artifact)
npx flo memory team-export 2>&1This writes the artifact, pins it to LF in .gitattributes, and rewrites .gitignore from a blanket .moflo/ to .moflo/* +
!/.moflo/shared/ so the shared artifact is tracked while the machine-local DB stays ignored. Surface
what it reports (entries added, .gitignore change). If there are no durable learnings yet, that's fine —
the artifact is created empty and fills in as learnings accrue.
Step 4 — Install the pre-commit hook
The hook re-exports and stages the artifact on every commit, so it's never stale in a PR. Handle three cases; do not clobber an existing hook.
Define the managed block (POSIX sh — git runs hooks via sh on Linux, macOS, and Windows):
# >>> moflo team-export (managed by /memory-team) >>>
# Refresh the shared learnings artifact so it rides along in this commit.
npx --no-install flo memory team-export >/dev/null 2>&1 || true
if [ -n "$(git status --porcelain -- .moflo/shared/learnings 2>/dev/null)" ]; then
git add -A -- .moflo/shared/learnings
fi
# <<< moflo team-export (managed by /memory-team) <<<Install it:
- Husky present (
.husky/pre-commitexists) → append the block to that file. - Existing
.git/hooks/pre-commit→ if it already contains themoflo team-exportmarkers, replace the block between them with the one above (an older block nameslearnings.jsonl); otherwise append the block after the shebang. - No hook → create
.git/hooks/pre-commitwith#!/bin/shas the first line, then the block.
On POSIX, make it executable:
node -e "require('fs').chmodSync('.git/hooks/pre-commit', 0o755)"(Use the Node fs.chmodSync primitive, not chmod — it's a harmless no-op on Windows. Never shell out
to chmod in a cross-platform step.)
- The
|| truekeeps a failed export from ever blocking a commit. - The
git status --porcelainguard means the artifact is only re-staged when it actually changed — no empty-diff churn on unrelated commits.-Aalso stages entry files export removed (expired tombstones). - Using a custom
team_artifactpath? Substitute it for.moflo/shared/learningsin both lines.
Step 5 — Commit and share
git add .moflo/shared/learnings/ .gitignore .gitattributes
git commit -m "chore: share moflo learnings"
git pushTeammates (or your other machine) run git pull; their next session auto-imports the merged artifact —
no manual import command. To pull learnings without waiting for a restart:
npx flo memory team-import 2>&1Output
End with a single-block summary:
Team Memory Sharing — configured
─────────────────────────────────
Artifact: .moflo/shared/learnings/ (git-tracked, one file per entry, author-stamped)
Config key: memory.team_artifact
PR hook: .git/hooks/pre-commit → re-exports + stages on every commit
Import: automatic at session start (after git pull) | npx flo memory team-import
Scope: learnings + knowledge only (embeddings regenerated on import)Advanced — one person, a private file (no git)
If you're solo and would rather not commit learnings, carry a binary artifact instead. It keeps the embeddings verbatim (no recompute on the far side) and merges idempotently:
npx flo memory sync --to ~/Dropbox/moflo-learnings.db # machine A
npx flo memory sync --from ~/Dropbox/moflo-learnings.db # machine BSame durable slice, no repo footprint, no review — the trade-off is it's not diffable and not shared.
Rules
- Don't reimplement export/import/migration or the
.gitignorerewrite —flo memory team-exportandteam-importown all of it. This skill sets config, runs them, and installs the hook. - Don't add a
merge=unionattribute for the artifact — GitHub ignores it, and the directory layout does not need it. - Don't overwrite an existing pre-commit hook or husky config — append the marked block only.
- Don't use
chmod/mkdir/rmin shell steps — Windows lacks them on PATH; use Nodefs. - Embeddings are intentionally omitted from the artifact (384 floats/entry would wreck diffs) — they're regenerated on import. Don't try to add them.
See Also
/memory-worktree— same-machine sharing across worktrees / Conductor (a shared local store, not git)flo memory team-export --help/flo memory sync --helpdocs/blog/memory-sharing.html— the design rationale (durable slice, why not share the whole DB)
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.

