@agent-crm/cli 0.0.3 → 0.0.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/README.md +7 -7
  2. package/package.json +2 -2
package/README.md CHANGED
@@ -4,7 +4,7 @@
4
4
 
5
5
  </div>
6
6
 
7
- Claude is running your GTM and your leads live in CSVs. Spreadsheets fall apart around 30 deals in: you lose track of who said what, what's open, and what's next. CRMs solve that, but they were built for humans clicking through UIs, not agents writing SQL.
7
+ Claude is running your GTM and your leads live in CSVs. Spreadsheets fall apart around 30 deals in: you lose track of who said what, what's open, and what's next. CRMs solve that, but they were built for humans clicking through UIs, not agents reading and writing it on your behalf.
8
8
 
9
9
  Plug Claude into your CRM via MCP and the schema torches your context, every action is a network round-trip, and you blow through your usage limits. Salesforce and HubSpot are shipping their own CLIs, but they end at the deal record — the scrapes, enrichment runs, and half-cleaned lists that fed it live somewhere else. You can't replay how a deal moved through stages, see what your last scrape pulled in and what it didn't clean up, or pick up where last weekend's list-building session left off.
10
10
 
@@ -22,7 +22,7 @@ Agents work best on files. Agent CRM is a portable `.acrm` file your agent can q
22
22
 
23
23
  ## What's in a `.acrm` file?
24
24
 
25
- A `.acrm` file is a **SQLite database** with a change-history layer ([Lix](https://lix.dev)) on top. That means:
25
+ A `.acrm` file is a **SQLite database** with a [change-history layer](https://lix.dev) on top. That means:
26
26
 
27
27
  - **No proprietary format.** Open it with any SQLite client (`sqlite3 pipeline.acrm`) and your data is right there in standard tables.
28
28
  - **Every write is a versioned checkpoint.** Like git for your CRM — branch to run an experiment, diff to see what changed, revert if Claude mangles a row.
@@ -47,19 +47,19 @@ claude --dangerously-skip-permissions
47
47
  Create an .acrm file
48
48
 
49
49
  ```bash
50
- acrm init pipeline.acrm
50
+ ! acrm init pipeline.acrm
51
51
  ```
52
52
 
53
53
  Then import your CSVs
54
54
 
55
55
  ```bash
56
- acrm import csv ./leads.csv
56
+ ! acrm import csv ./leads.csv
57
57
  ```
58
58
 
59
- And query the file any time with:
59
+ And query the file any time:
60
60
 
61
61
  ```bash
62
- acrm execute "select * from people limit 5;"
62
+ ! acrm execute "select object_slug, count(*) as n from acrm_record group by object_slug"
63
63
  ```
64
64
 
65
65
  ## Why Agent CRM
@@ -95,7 +95,7 @@ description: Pull a Granola transcript, resolve the person in .acrm, and log the
95
95
  ## Steps
96
96
 
97
97
  1. **Resolve the person** with a SQL lookup against `pipeline.acrm`:
98
- `acrm execute "SELECT DISTINCT record_id FROM acrm_value WHERE object_slug = 'people' AND attribute_slug = 'email_addresses' AND active_until IS NULL AND normalized_key = ?" '["<email>"]' --json`
98
+ `acrm execute "SELECT DISTINCT record_id FROM acrm_value WHERE object_slug = 'people' AND attribute_slug = 'email_addresses' AND active_until IS NULL AND normalized_key = $1" '["<lowercased-email>"]' --json`
99
99
 
100
100
  2. **Find the Granola meeting** via `mcp__granola__list_meetings`. Filter
101
101
  to meetings where the person's name appears in the title or
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "@agent-crm/cli",
3
- "version": "0.0.3",
4
- "description": "Headless CRM for claude code — versioned, queryable, scriptable",
3
+ "version": "0.0.5",
4
+ "description": "Agent CRM: Headless CRM for claude code",
5
5
  "type": "module",
6
6
  "bin": {
7
7
  "acrm": "dist/bin/acrm.js"