mattrguerra.comHouston area
Matt Guerra
  1. 01AI & Automation
  2. 02Photography
  3. 03Design
  4. 04About
  5. 05Notes
  6. 06Contact
Back to the systems

mattrguerra/meridian-outreach-vaultmainPrivate on GitHub, published here in full

CLAUDE.md

Markdown5.1 KB52 lines

CLAUDE.md

  1. ---
  2. type: claude-instructions
  3. scope: project-root
  4. tags: [claude, outreach]
  5. created: 2026-06-16
  6. updated: 2026-07-24
  7. ---
  9. # CLAUDE: Quarterly Outreach Project Instructions
  11. ## What this project is
  12. A client research database for Meridian Display Co.'s quarterly outreach, covering the **full Partner Program client base (Palladium and up)** plus the original Check-In/Winback cohorts. This repo ships a generated sample book: 381 Plinth accounts, 130 of them partner clients with a stub each (see [[README]]). Each client has a stub in `03-Clients/client-stubs/` ready to receive scraped/enriched data and human notes. The `03-Clients/` root holds only the folder rules ([[CLAUDE-clients]]) and `partner-client-master-list.xml`, the **master list of clients in the Partner Program** (schema 3.0). That file is a **complete machine-readable census of every partner client**, each carrying both a `<bitrix_id>` (CRM) and a `<plinth_id>` (Plinth order backend), whether pipeline-mapped or not; clients not yet in a pipeline carry `<pipelines count="0" />`. Segmentation: partner tier (`user_group` / `user_group_correct`) and outreach play (`outreach_pipelines`).
  14. ## Folder map
  15. - `01-Tiers/`: Partner Program tier notes (Dataview rollups of members).
  16. - `02-Outreach/`: outreach-play notes, email templates, call scripts.
  17. - `03-Clients/`: `client-stubs/` (all stubs, flat) + `partner-client-master-list.xml` + [[CLAUDE-clients]]. Read the folder rules before touching anything here.
  18. - `04-Working/`: in-progress drafts.
  19. - `05-Outputs/`: finished deliverables, email drafts, run artifacts, backups.
  20. - `06-Resources/`: reference material.
  21. - `07-Automation/`: the **live Weekly Partner Client Pipeline** (driver, SOP, thresholds, runbook, local order history in `data/`). **Armed and scheduled** since 2026-07-23: Mondays 06:00 America/Chicago, autonomy `through_vault`. It pulls Plinth deltas, classifies, verifies (the no-shrink guardrail halts on exit 2), writes/upgrades partner stubs, and refreshes the XML census. It does NOT enrich, and it never writes to Bitrix: routing only proposes candidates (rules in [[pipeline-routing-rules]]), and every Bitrix write stays human-gated. Don't modify the driver or config without Matt's explicit go-ahead. The local `data/order_history.json` is the LTV source of truth: never recompute lifetime totals from a raw Plinth query (the API truncates; see the SOP).
  22. - `08-Planning/`: **human-only** planning space for Matt, Hazel, and Ines. Claude may read it for context but never creates, edits, moves, or deletes anything in it. No exceptions unless Matt explicitly grants one.
  24. ## How to work here
  25. - Read [[MEMORY]] at the start of every session.
  26. - Client-facing work comes first. Outreach copy must sound like Matt, never like an AI. Use the `matt-guerra-email` skill for any client email; avoid the AI tells (no em-dashes, no "leverage/seamless/ensure/utilize", no over-structured short replies).
  27. - When enriching a client, append to the stub's `## Research` section. Never overwrite human notes. Follow [[CLAUDE-clients|the client-folder rules]].
  28. - Everything links: tier and outreach notes pull their members back via Dataview over stub frontmatter. Preserve this when adding files.
  29. - Facts must be sourced. Don't fabricate company/person detail. Use `[TBD: ...]` markers for gaps.
  31. ## Shared vault: log every change to [[LEDGER]]
  32. This vault is worked by two operators through separate Cowork projects synced over Obsidian: **Matt** and **Hazel**. The ledger is how each side sees what the other did. This is a **session requirement, not optional**:
  34. - **On any vault change** (creating, editing, enriching, moving, or deleting any file: stubs, templates, tier/outreach notes, reference files, and including any update to [[CHANGELOG]] or [[HEARTBEAT]]), append an entry to [[LEDGER]] before ending the turn. Batch one change-set into one entry; don't spam one entry per file.
  35. - **Attribute by the active session's user email:** `hello@meridiandisplay.example` → **Matt**; `accounts@meridiandisplay.example` → **Hazel**; anything else → log as `Unknown (<email>)` and flag it. Never guess the actor.
  36. - **Timestamp from the system clock** (`date`), in the operator's local time. Don't approximate.
  37. - Follow the entry format defined in [[LEDGER]]. The ledger is append-only: never rewrite or delete prior entries.
  38. - Pulling in others' synced changes? Skim [[LEDGER]] first to see what they touched.
  40. ## Map of Claude reference files
  41. - [[LEDGER]]: append-only who-changed-what log for Matt + Hazel. Update on every vault change.
  42. - [[MEMORY]]: durable project context.
  43. - [[MODEL_GUIDE]]: which model for which task.
  44. - [[SKILLS_REFERENCE]]: skills relevant to this project.
  45. - [[HEARTBEAT]]: in-flight working state.
  46. - [[CHANGELOG]]: what changed.
  47. - [[DECISIONS]]: why it changed.
  48. - [[SETUP]]: how to open and run the vault.
  49. - [[00-Index]]: human-facing navigation.
  51. ## Subdirectory reference files
  52. - [[CLAUDE-clients]] (at `03-Clients/CLAUDE-clients.md`): the client-folder rules. Covers the `client-stubs/` layout, the XML map contract (chunking, `<summary>` regeneration, stub-path sync), and the scraping-dump contract. Read before creating, editing, or enriching any client stub or touching the XML map.