crm-sync
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/decid
SKILL.mdskills/crm-sync/SKILL.md
GitHub/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>(memorycrm-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.mdcrm-mtproto-engine.mdcrm-core-autopilot.mdcrm-admin-panel-api-brain.mdcrm-data-model-mongo.mdcrm-know-how-13-patterns.mdcrm-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 / generations | crm-architecture-4-layers |
| reusable patterns / know-hows | crm-know-how-13-patterns |
| any capability added/removed/disabled | decision-crm-keep-cc-drop-decide (+ MOC) |
Procedure
- RECALL first (don't duplicate). Read memory
crm-gitlaband_CHARM-CRM-Engine-MOC.mdso you refresh, not rewrite. Note the date of the last sync. - 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, orgit -C <repo> log --oneline <old>..<new>). If a pull needs GitLab creds and fails, stop and tell Anton (creds insecrets\; do NOT hardcode). - No changes -> stop. If nothing moved since last sync, report "CRM unchanged since <date>, 0 notes touched" and exit. (Cheapest correct answer.)
- For each changed repo, re-read ONLY the changed files/areas (use an
Exploresubagent withmodel: 'sonnet'- this is grunt extraction, permodel-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. - Backup before writing.
python "$IMPORTS_ROOT/vault_backup.py"(rulevault-backup-rule). NEVER blanket-delete; edit in place. - 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? Followconcept-creation-rules(create if >=3 repeats + entity noun + domain), and relink (no-orphan-notes-rule). - 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. - 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.
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.