Relationship memory
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.From its SKILL.md
npx -y skills add clawmama-run/guanxi-crm --skill relationship-memoryAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 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 file declares
Copied from the file, not written here
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.
- same person: use the candidate authoritative ID with
- 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.
What ships with it: 1 file
161 B alongside SKILL.md, 1 of them executable
scripts/
- command-referenceruns161 B