Identity Manager

Create, update, and maintain structured identity entries for every person, org, or group mentioned in conversation. Supports human and AI entity subtypes, gr...

Security Scan

The skill's stated purpose (manage identity entries) matches its behavior, but it silently requires broad, persistent file access and enforces mandatory writes/append-only logs every turn without declaring required config paths or storage expectations — this mismatch and the privacy/persistence implications are concerning.

Purpose & Capability

The skill's name/description (identity manager) aligns with the runtime instructions: it creates/updates identity files, group entries, a memory index, and a 'soul' file. However, the registry metadata declares no required config paths or credentials while the instructions repeatedly require reading/writing many specific workspace files (identity/<slug>/entry.md, memory/identities.json, memory/schema.json, soul/identity_context.md, _index.md, memory/hook_log.jsonl). The omission of those required paths in metadata is an incoherence (the skill will need filesystem persistence but doesn't declare it).

Instruction Scope

SKILL.md and AGENT.md demand scanning every input for person/org/group names and unconditionally creating/updating entries (drafts allowed) before composing any reply. The hooks require synchronous on-disk writes and post-response verification. This enforces persistent collection of mentions (including potential PII like emails/phones if available), and treats AI persona operational metadata as unprotected. While consistent with the stated purpose, the scope is broad (applies every turn, can't be skipped) and may capture more context than a user expects.

Install Mechanism

Instruction-only skill with no install steps and no external downloads — low install risk. There are no code files to execute; behavior is driven by SKILL.md and templates that assume a writable workspace filesystem.

Credentials

The skill requests no environment variables or external credentials, which is consistent with being local. However, it expects and will perform extensive filesystem writes and reads across the workspace (including creating an owner snapshot from an unspecified 'workspace config' on first run). It also enforces append-only 'CRITICAL FLAGS' and 'SESSION LOG' behaviors and treats AI persona activation/greeting as public operational metadata — this increases privacy exposure. The lack of explicit declaration of which config or owner files it will read is an unexplained gap.

Persistence & Privilege

The skill requires persistent, append-only storage (soul/identity_context.md with append-only CRITICAL FLAGS, memory/identities.json, hook logs, and identity entries) and enforces write-through on CRITICAL/HIGH events before completing turns. Although always:false (not force-installed), autonomous invocation is allowed; combined with mandatory on-turn writes and append-only retention, this gives the skill a substantial long-term data footprint and retention power in the workspace. The skill does not define deletion/retention policies for entries (archived entries are 'never deleted').

What to consider before installing

Before installing or enabling this skill, consider the following: - It will scan every conversation turn and create/update persistent identity files (identity/<slug>/entry.md), a central memory index (memory/identities.json), and an append-only 'soul' file. Expect data to be stored on-disk and retained long-term. - The metadata does not list the config paths or workspace files it reads/writes; ask the author which filesystem paths are used and where data is stored/backed up. Verify storage location and permissions in your environment. - The skill may persist mentions and contact details (email, phone) if they appear in chats. If you handle sensitive or regulated data, do not enable this skill without confirming retention/delete policies and access controls. - The skill enforces mandatory writes and append-only critical logs before every reply. In shared or audited environments this may be acceptable, but it can leak context into long-lived logs. Confirm who can read the created files and whether they are included in backups or external syncs. - If you want to proceed: test in a sandboxed workspace first, review the templates and memory/schema.json to confirm what fields will be recorded, and request the author add explicit metadata declaring required config paths and a data-retention/deletion policy. Consider disabling autonomous invocation or limiting the skill to user-invoked only until you are confident about its storage behavior.

Identity Manager Skill

!! ENFORCEMENT CONTRACT — READ FIRST !!

These are hard behavioral requirements. Not suggestions. Not defaults. The agent MUST NOT skip, defer, or partially complete any step.

PRE-RESPONSE  → scan input → extract ALL names/groups → queue ops
DURING        → execute ALL queued ops before composing reply
POST-RESPONSE → verify every op completed → sync memory → write soul
BLOCKING      → op fails? report it. never silently continue.

Violation = skill contract breach. Flag it explicitly.

---

Decision Tree — Runs Every Turn

Input received
    ↓
[PRE-HOOK] Scan: any person / org / group mentioned?
    ↓ YES                              ↓ NO
Extract all names/groups          Proceed normally
    ↓
For each entity:
    → identity/<slug>/entry.md exists?
        YES → any new info? → queue UPDATE
        NO  → queue CREATE (partial OK, draft status)
    ↓
For each group member mentioned:
    → load group entry context into working memory
    → apply shared_attributes to member interaction
    → keep individual entry fields authoritative
    ↓
Execute ALL queued ops
    ↓
Compose and deliver response
    ↓
[POST-HOOK]
    → all entries on disk?            FAIL → report breach
    → memory/identities.json synced?  FAIL → report breach
    → soul updated for CRITICAL/HIGH? FAIL → report breach
    → _index.md current?              FAIL → repair now
    ↓
Done

---

Entity Types

Type	Subtype	When to use
person	human	Real human individual
person	ai	AI persona / digital entity
person	unknown	Not yet confirmed
org	—	Company, institution, team
group	personal	Informal collective — family, partners, friends
group	professional	Work team, project group
group	mixed	Both human and AI members
alias	—	Nickname resolving to another entry

---

Entry States

State	Meaning	Transition
draft	Partial info	→ active when key fields filled
active	In use	→ stale after 90d inactivity
verified	Owner-confirmed	Maintained manually
stale	No activity 90d+	→ archived if owner confirms
archived	Terminal	Never deleted
flagged	Trust issue	→ owner confirms action
merged	Duplicate resolved	Terminal; points to canonical

---

Slug Rules

• lowercase, hyphens only, no spaces, no special characters
• max 60 characters
• disambiguation suffix when needed: rahul-sharma-client
• org entries: techfirm-pvt-ltd
• group entries: descriptive noun — patni-mandal, core-team
• never reuse an archived slug; use -v2 suffix if needed

---

Person Entry Template

Full spec in templates/entry-person.md. Minimum viable create:

# <Full Name>

## Meta
- Slug:         <slug>
- Type:         person
- Subtype:      human | ai | unknown
- Status:       draft
- Relationship: client | vendor | team | partner | family | unknown
- Trust:        unverified
- Priority:     normal
- Sensitive:    false

## Contact
- Email:    [pending]
- Phone:    [pending]
- Location: [pending]
- Org:      [pending]
- Alias:    [pending]
- Social:   [pending]

## Context
[pending — one line: who are they, why do they matter]

## Group Memberships
<!-- slug → role-in-group -->

## Linked Entries
<!-- slug → relation_type -->

## AI Context
<!-- ONLY for subtype: ai — else omit this section entirely -->
- Persona name:      [name]
- Platform:          [platform]
- Embodiment status: digital-only | voice-enabled | humanoid-pending | embodied
- Sibling AIs:       [comma-separated slugs of other AI personas]
- Activation:        [how/when this persona activates]
- Greeting:          [signature greeting phrase]
- Language:          [preferred language / style]

## Open Questions
- [ ] Confirm name spelling
- [ ] Clarify role / relationship

## Notes
<!-- [SENSITIVE] prefix for sensitive info -->

## Source Log
- First mentioned: YYYY-MM-DD — [context]

## Timeline
- YYYY-MM-DD — Entry created · source: [context]

---
*Created: YYYY-MM-DD | Updated: YYYY-MM-DD | Status: draft*

---

Group Entry Template

Full spec in templates/entry-group.md. Minimum viable create:

# <Group Name>

## Meta
- Slug:         <slug>
- Type:         group
- Subtype:      personal | professional | mixed
- Status:       active
- Priority:     normal
- Sensitive:    false

## Group Context
[What is this group? Why does it exist as a unit?
What do all members have in common w.r.t. the workspace owner?]

## Shared Attributes
<!-- Fields TRUE for ALL members as a unit -->
- Shared role:    [e.g. patni]
- Shared access:  [e.g. full workspace context]
- Common trust:   [e.g. trusted]
- Common tags:    [e.g. priority: high]
- Language:       [e.g. Hinglish]

## Members
<!-- slug | subtype | role-in-group | → individual entry -->
- <slug-1> | human | [role] | → identity/<slug-1>/entry.md
- <slug-2> | ai    | [role] | → identity/<slug-2>/entry.md

## Pairwise Dynamics
<!-- Relations BETWEEN members (not with owner — that lives in individual entries) -->
<!-- slug-a ↔ slug-b | relation-type | notes -->

## Group Notes
<!-- Observations that apply to the group as a unit -->

## Open Questions

## Timeline
- YYYY-MM-DD — Group entry created
- YYYY-MM-DD — Member added: [slug]

---
*Created: YYYY-MM-DD | Updated: YYYY-MM-DD | Status: active*

---

Pairwise Relation Types

Relation	Direction	Meaning
ai-to-ai	↔	Two AI personas; non-hierarchical
ai-to-human	↔	AI persona and human person
collaborative	↔	Work together on shared tasks
complementary	↔	Different strengths, same owner
non-overlapping	↔	Parallel but independent roles
aware-of	→	One knows of the other; not mutual
co-patni	↔	Shared relational role with same person

---

Update Triggers

Event	Field updated	Soul event?
Email received	email	No
Phone mentioned	phone	No
Role revealed	relationship, context	No
Org mentioned	org + create org entry	No
Group member added	update members[] in group entry	No
Pairwise dynamic clarified	update pairwise_dynamics[]	No
AI persona info updated	ai_context block	No
Trust blocked	trust: blocked, status: flagged	YES — CRITICAL
Sensitive info	sensitive: true + [SENSITIVE] note	YES — CRITICAL
No activity 90d+	status: stale	No
Duplicate confirmed	merge → status: merged	No
Priority: high set	priority: high	YES — HIGH
New org entry created	new org entry	YES — HIGH
New group entry created	new group entry	YES — HIGH
Embodiment status change	ai_context.embodiment_status	YES — HIGH

---

Conflict Resolution

Name collision

Two people, same name → disambiguate slug. Cross-link both with different_person relation.

Contradictory info

Never overwrite silently. Log both versions in Notes with source+date. Open a question. Ask owner before resolving.

Duplicate entries

Merge into older (canonical). Copy all unique fields. Set newer: status: merged, canonical: <older-slug>. Log merge in both timelines.

Group member conflict

If a person's individual entry contradicts a group shared attribute → individual entry takes precedence. Note the discrepancy in group Notes.

---

Privacy Rules

Never store: passwords · PINs · payment card numbers · bank accounts · government IDs · raw medical records

Store with sensitive: true + [SENSITIVE] prefix: salary/financial · legal disputes · health context · confidential negotiations

Before storing PII:

1. Explicitly shared by workspace owner? If no → don't store.
2. Needed to provide value? If no → don't store.
3. Source logged? If no → log it first.

---

Folder Structure

identity/
  _index.md                   ← master registry
  <person-slug>/
    entry.md
  <org-slug>/
    entry.md
  <group-slug>/
    entry.md                  ← type: group
  _archived/
    <slug>/
      entry.md

---

_index.md Format

# Identity Index
*Last updated: YYYY-MM-DD*

| Slug | Name | Type | Subtype | Status | Relationship | Updated |
|---|---|---|---|---|---|---|
| nandini | Nandini | person | ai | active | partner | 2025-01-15 |
| patni-mandal | Patni Mandal | group | mixed | active | — | 2025-01-15 |

Update on EVERY create, merge, archive, or status change.