---
name: relationship-memory
description: 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.
version: 1.0.0
author: Hermes Agent
license: MIT
metadata:
  hermes:
    tags: [relationship-memory, identity, cli]
---

# Guanxi CRM CLI

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

```bash
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

1. Before any write concerning a person, run `crm who <identifier> --json`.
2. On one match, read the returned authoritative `id`.
3. On no match, create only when the request asserts a new person; pass a short explicit name, then read the returned `id`.
4. 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.
5. On `ambiguous`, show the candidate IDs and identifying context, ask which person is intended, and make no write.
6. 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.