Relationship memory

Skill clawmama-run/guanxi-crm/skills/relationship-memory

Local-first relationship memory vault with a headless crm CLI and installable agent skill

Install

npx -y skills add clawmama-run/guanxi-crm --skill relationship-memory

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

3 things to look at

11 days oldThe repository was created 11 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when operating a Guanxi CRM vault through the crm CLI; resolve identities, map CLI errors to the next action, and use authoritative IDs for every write.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.7 KB, 515 tokens by cl100k_base, as published. Nobody here has run it

Guanxi CRM CLI

Use crm only through its live Click interface (crm --help). Generate command help when needed:

skills/relationship-memory/scripts/command-reference
skills/relationship-memory/scripts/command-reference person add

Do not maintain a command list here. Locate and read this repository's FORMAT.md; do not recreate format rules.

Identity resolution

Before any write concerning a person, run crm who <identifier> --json.
On one match, read the returned authoritative id.
On no match, create only when the request asserts a new person; pass a short explicit name, then read the returned id.
On identity_conflict, decide only from the user's assertion:
- same person: use the candidate authoritative ID with --same;
- different person: use --distinct;
- unclear: ask the user and make no write.
On ambiguous, show the candidate IDs and identifying context, ask which person is intended, and make no write.
To add a newly learned identifier, resolve the person first, then attach it to the selected authoritative ID.

Error to action

Result	Next action
success with `id`	Continue using that exact ID
not found	Create only if the user asserted a new person; otherwise ask
`identity_conflict`	Ask or apply explicit `--same <id>` / `--distinct`
`ambiguous`	Stop, present candidates, ask the user
invalid input / usage error	Read live Click help, correct arguments, retry
transaction or internal failure	Report failure; do not assume any write succeeded

权威 ID write rule

Every write uses an authoritative ID obtained from JSON output. This includes identity updates, aliases, interactions, attachments, and any later write targeting an existing entity.

Never derive an ID from a filename, path, display name, truncated text, or search snippet. Never guess between candidates. After a write, verify with a JSON query and compare its returned ID to the ID used.

For a meeting with several participants, resolve each participant separately and pass only their authoritative IDs. If any participant is ambiguous, stop before creating the interaction.

Completion check

Every existing target was resolved through JSON.
Every write used the returned authoritative ID.
No ambiguity was guessed through.
The final JSON verification points to the intended IDs.

Gives 0 of the 12 instructions most memory context skills give in 515 tokens

Counted across 674 of the 847 authors here whose files we hold, read 2026-08-07

inform the user when setup is completein 21 of 674, across 6 files
confirm the draft with the user before writingin 21 of 674, across 7 files
update the agent skills block in place if it existsin 21 of 674, across 6 files
present findings to the userin 20 of 674, across 5 files
ask the user about each decision one at a timein 20 of 674, across 5 files
write the three docs files from seed templatesin 20 of 674, across 5 files
edit CLAUDE.md if it existsin 18 of 674, across 3 files
explore current repo statein 18 of 674, across 3 files
do not overwrite user edits to surrounding sectionsin 18 of 674, across 3 files
keep the memory index under 200 linesin 18 of 674
back up the original file before overwritingin 16 of 674, across 8 files
provide actionable steps and verificationin 13 of 674, across 2 files

Said here and by no other author read

resolve every person before writing
run json query before any person write
use authoritative id for every write
create person only when explicitly asserted
resolve identities separately for multiple participants
verify writes with a json query

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.