agentleFS
tonydzitonydzi/second-brain-starter-kit/skills/crm-sync/SKILL.md

crm-sync

Skill6 starsChanged 2 months agoMITView on GitHub

Sync CRM knowledge notes in a vault with the live CRM code repositories: pull the read-only repos, detect which changed, and refresh only the affected reverse-engineering notes and the keep/drop/decide note. Triggers: "/crm-sync", "refresh CRM knowledge", "what changed in the CRM code".

3 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

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

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    What this is NOT: not a re-decompose-from-scratch.

    line 18
  2. Very specific:

    RECALL first (don't duplicate): Read memory crm-gitlab and _CHARM-CRM-Engine-MOC.md so you refresh, not rewrite.

    line 49
  3. Distinctive:

    No changes -> stop: If nothing moved since last sync, report "CRM unchanged since <date>, 0 notes touched" and exit.

    line 56
  4. Very specific:

    Verify + reindex: Run the vault broken-link check.

    line 69
  5. Distinctive:

    Read-only by default; the only writes are git pull (updates the clone) + the mapped vault notes, always backup-first.

    line 76
  6. Distinctive:

    Don't touch the live CRM server or its Mongo - that is the prod-access track, separate.

    line 78

“Common” is measured: kept by at least 6 in 10 of the 3 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

/crm-sync - keep the CRM knowledge layer fresh

The CRM (CHARM) is Anton's proven engine on GitLab. We reverse-engineered it once (2026-06-19) into a linked vault layer so his digital twin can /ask how the CRM works. Code keeps changing; this skill stops that knowledge from going stale silently. It is the recurring half of the standing rule evaluate-recurring-into-routine.

What this is NOT: not a re-decompose-from-scratch. It is a DIFF-DRIVEN refresh: pull, see what changed, update only the notes that map to the changed code.

Where everything lives

  • Code (read-only clone, 16 repos): <CRM_REPOS_ROOT> (memory crm-gitlab).
  • Decomposition audit (HTML, source of the notes): <CRM_REPOS_ROOT>\_AUDIT\ (Functional-Map.html, Know-How-Decomposition.html, Architecture-Deep.html).
  • Vault knowledge layer: $OBSIDIAN_VAULT/05-Resources/CRM-Engine/
    • _CHARM-CRM-Engine-MOC.md (hub)
    • crm-architecture-4-layers.md
    • crm-mtproto-engine.md
    • crm-core-autopilot.md
    • crm-admin-panel-api-brain.md
    • crm-data-model-mongo.md
    • crm-know-how-13-patterns.md
    • crm-landing-api-money.md
    • decision: $OBSIDIAN_VAULT/02-Decisions/decision-crm-keep-cc-drop-decide.md

Repo -> note map (which note to refresh when which code changes)

Code area in <CRM_REPOS_ROOT>Note(s) to refresh
admin-panel / admin-panel-api (FastAPI brain, filter-DSL, $facet)crm-admin-panel-api-brain
mtproto-api (Telethon hands, event-pool, dialog export, FloodWait)crm-mtproto-engine
core (aiocron autopilot: newsletters, gatekeeper, tapping, calls)crm-core-autopilot
landing-api (token sale, NOWPayments, CHEATING_MODE, webhook)crm-landing-api-money
shared models / Mongo schema (collections, fields)crm-data-model-mongo
cross-cutting architecture / generationscrm-architecture-4-layers
reusable patterns / know-howscrm-know-how-13-patterns
any capability added/removed/disableddecision-crm-keep-cc-drop-decide (+ MOC)

Procedure

  1. RECALL first (don't duplicate). Read memory crm-gitlab and _CHARM-CRM-Engine-MOC.md so you refresh, not rewrite. Note the date of the last sync.
  2. Pull the repos. For each repo dir under <CRM_REPOS_ROOT>: git -C "<CRM_REPOS_ROOT>\<repo>" pull --ff-only (clone is read-only; this only updates). Collect the set of repos that actually moved (non-empty pull, or git -C <repo> log --oneline <old>..<new>). If a pull needs GitLab creds and fails, stop and tell Anton (creds in secrets\; do NOT hardcode).
  3. No changes -> stop. If nothing moved since last sync, report "CRM unchanged since <date>, 0 notes touched" and exit. (Cheapest correct answer.)
  4. For each changed repo, re-read ONLY the changed files/areas (use an Explore subagent with model: 'sonnet' - this is grunt extraction, per model-routing-sonnet-grunt; escalate to Opus only if a judgement call). Ask it to report: what behavior changed vs what the mapped note currently says, with file+line evidence.
  5. Backup before writing. python "$IMPORTS_ROOT/vault_backup.py" (rule vault-backup-rule). NEVER blanket-delete; edit in place.
  6. Update the mapped note(s) - the "How it works" / "Weak spots" sections only. PRESERVE frontmatter, origin: external, authored_by: (denis-udot / gleb-taigunov), and all [[wikilinks]]. If a capability moved KEEP<->DROP<->DECIDE, update the decision note too. New behavioral pattern worth a concept? Follow concept-creation-rules (create if >=3 repeats + entity noun + domain), and relink (no-orphan-notes-rule).
  7. Verify + reindex. Run the vault broken-link check; then python "$IMPORTS_ROOT/brain_embed_update.py" (cooldown 15min; nightly @04:00 will catch it otherwise) so the refreshed notes are /ask-searchable.
  8. Report post-hoc (not for permission): which repos moved, which notes changed, any new concept, any DECIDE item that flipped, and what still needs Anton/Denis.

Guardrails

  • Read-only by default; the only writes are git pull (updates the clone) + the mapped vault notes, always backup-first.
  • Don't touch the live CRM server or its Mongo - that is the prod-access track, separate.
  • AK-47: this is one markdown procedure. If the CRM grew a whole new service, that is a new note + MOC link, still just notes - flag it, don't over-build.

When to run

On demand (after Anton hears the CRM changed), or as a light routine. Pairs with the crm-gitlab DD-audit and the decision-crm-keep-cc-drop-decide open items.


<!--kit-footer-->

Like this skill? It is one of 100 in second-brain-starter-kit: the second brain we built for ourselves and run every day at Palo Alto AI Research Lab. Install the whole set with npx skills add tonydzi/second-brain-starter-kit. Everything is open source and free, so take what you need.

Flagships worth a look on their own: secondop-panel (a second opinion from a panel of external models), claude-memory-tidy (stop your agent's memory from rotting), telegram-mcp-kit (your own Telegram over MCP in about 15 minutes).

Author: Anton Dziatkovskii, Palo Alto AI Research Lab. Telegram @tonydzi - WhatsApp +1 341 222 9178 - X @Tony_Stef_

Engineers: want to test-drive this setup? Message me. I hand out free starter seeds to engineers who test and report back, and custom skill requests are welcome.

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.