@rubytech/create-realagent 1.0.826 → 1.0.828

package/payload/platform/plugins/whatsapp-import/skills/whatsapp-import-enrich/SKILL.md

@@ -1,333 +0,0 @@
----
-name: whatsapp-import-enrich
-description: Operator-driven semantic enrichment pass over an already-loaded WhatsApp Conversation. Owns the LLM half of the WhatsApp ingest pipeline — first runs `mcp__memory__whatsapp-export-insight-pass` (chunkSize=50, overlap=5, server-side confidence>=0.8 gate) to lay down `:Observation {observationStatus:'auto-extracted'}` rows, then walks `:Person {participantStatus:'auto-created'}` and the auto-extracted observations, surfaces evidence per row, and writes operator-confirmed wiring (participant promotion/merge, `:MENTIONS` / `:RELATED_TO` edges, `:Task` and `:Preference` nodes). Triggers on operator phrases like "enrich the X chat", "promote the auto-created participants from Y", "wire the observations from yesterday's import". Runs against a Conversation already imported by `whatsapp-import` Phase 1; never re-runs parse.
----
-
-# WhatsApp Import — Enrich
-
-Phase 2 of the two-phase WhatsApp ingest contract. Phase 1 (`whatsapp-import`) is the deterministic, LLM-FREE Bash entry that lands raw shape: Conversation + Messages + chronological NEXT chain + auto-created `:Person` participants. Phase 2 (this skill) owns the LLM half: it runs the chunked Haiku insight pass on demand to lay down `:Observation` nodes, then operator-driven semantic resolution disambiguates participants, wires observations to typed entities, and reattributes the operator's own messages from the auto-Person to their `:AdminUser`.
-
-The split exists because the inline insight pass on Phase 1 (1500 msgs/chunk, no operator gate) polluted the parent's tool_result with `:Observation` enumeration prose and blew operator context. Phase 1 is now mute on insights; this skill triggers them consciously with `mcp__memory__whatsapp-export-insight-pass` when the operator asks.
-
-## When this applies
-
-The operator triggers this skill against a single, already-loaded `:Conversation:WhatsAppConversation`. Acceptable phrases include any reference to enriching, promoting participants from, or wiring observations against a conversation the operator can name (display name, recent timestamp, conversationId). When the conversation reference is ambiguous, list the recent WhatsApp conversations and require operator selection before any walk begins. Never run against a conversation whose `whatsapp-import` Phase 1 has not completed (`MATCH (c:WhatsAppConversation {conversationId:$cid}) WHERE c.lastImportedAt IS NULL` is a blocker — surface "Phase 1 has not completed for <cid>; run whatsapp-import first" and yield).
-
-## Step 0 — run the chunked Haiku insight pass (Phase 2a)
-
-Phase 1 writes ZERO `:Observation` rows. Before any walk, lay them down via `mcp__memory__whatsapp-export-insight-pass`:
-
-```json
-{ "conversationId": "whatsapp-export:<sha>:<accountId>" }
-```
-
-The tool walks the Messages of the conversation in chronological order, chunks them at **chunkSize=50** with **overlap=5** (the prior 1500 msgs/chunk implementation lost per-message attention), runs Haiku per chunk, applies a server-side `confidence>=0.8` gate, and MERGE-keys `:Observation` rows. Returns `{conversationId, chunks, chunkSize, overlap, confidenceThreshold, totals:{mentions, tasks, preferences, observedRelationships, rejectedLowConfidence, written}, ms}`.
-
-Surface to the operator as one chat message — counters only, no enumeration:
-
-> Insight pass complete on `<conversationId>`: `<chunks>` chunks at chunkSize=50 / overlap=5 / confidenceThreshold=0.8. Wrote `<written>` observations (`<mentions>` mentions, `<tasks>` tasks, `<preferences>` preferences, `<observedRelationships>` relationships); rejected `<rejectedLowConfidence>` low-confidence items.
-
-Idempotent — re-running collapses identical `(conversationId, sourceMessageRef, kind, contentHash)` tuples into one row. Re-runs are safe; the operator can tune the conversation by re-importing extra rows in Phase 1, then re-running the pass here.
-
-## Bulk preview (mandatory, before any walk)
-
-Before walking a single row, count the work and offer a yield. Two read-only Cyphers via `mcp__graph__maxy-graph-read_neo4j_cypher`:
-
-```cypher
-MATCH (p:Person {accountId:$acct, source:'whatsapp', participantStatus:'auto-created'})
-      -[:PARTICIPANT_IN]->(:Conversation {conversationId:$cid})
-RETURN count(p) AS autoParticipants
-```
-
-```cypher
-MATCH (o:Observation {accountId:$acct, observationStatus:'auto-extracted', insightPass:true})
-      -[:OBSERVED_IN]->(:Conversation {conversationId:$cid})
-RETURN count(o) AS autoObservations,
-       sum(CASE o.kind WHEN 'mention' THEN 1 ELSE 0 END)               AS mentions,
-       sum(CASE o.kind WHEN 'task' THEN 1 ELSE 0 END)                  AS tasks,
-       sum(CASE o.kind WHEN 'preference' THEN 1 ELSE 0 END)            AS preferences,
-       sum(CASE o.kind WHEN 'observed-relationship' THEN 1 ELSE 0 END) AS relationships
-```
-
-Surface one chat message: `"<N> auto-participants and <M> auto-observations to review (<a> mentions, <b> tasks, <c> preferences, <d> relationships). Proceed?"`. Yield on no. On yes, persist `$preParticipantCount` and per-kind `$preObservationCount` for post-walk verification (Cypher silent-no-op detection — see "Status-update verification").
-
-Emit one chat line: `[whatsapp-import-enrich] start conversationId=<cid> auto-participants=<N> auto-observations=<M>`.
-
-## Walk 1 — Auto-created participants
-
-For each `:Person {participantStatus:'auto-created'}` `PARTICIPANT_IN` the conversation, surface evidence and ask the operator to choose an action.
-
-Per-row evidence Cypher:
-
-```cypher
-MATCH (p:Person)-[:PARTICIPANT_IN]->(c:Conversation {conversationId:$cid})
-WHERE p.participantStatus = 'auto-created' AND p.accountId = $acct AND p.source = 'whatsapp'
-WITH p, c
-OPTIONAL MATCH (p)-[:SENT]->(m:Message {conversationId:$cid})
-WITH p, count(m) AS messageCount,
-     min(m.dateSent) AS firstSeenAt, max(m.dateSent) AS lastSeenAt,
-     [m IN collect(m)[..3] | substring(m.body, 0, 80)] AS bodySamples
-RETURN elementId(p) AS elemId, p.name AS displayName,
-       messageCount, firstSeenAt, lastSeenAt, bodySamples
-```
-
-Operator choices per row:
-
-| Action | Effect |
-|--------|--------|
-| **promote-to-existing** | Operator names an existing `:Person` or `:AdminUser` (resolved via `mcp__memory__memory-search` against `displayName`). Skill writes the merge below. |
-| **mint-new-Person** | Operator names a new contact identity. Skill calls `mcp__contacts__contact-create` with `givenName` / `familyName` / at least one of `email` / `telephone`, then merges the auto-Person into the new contact's `:Person` node. |
-| **merge-same-person** | Two auto-Persons that are the same person under different display names (e.g. phone-then-name). Operator names the survivor; skill merges the other into it. |
-| **skip** | Leave `participantStatus='auto-created'`. Re-running the skill surfaces it again. |
-
-### Merge Cypher (load-bearing — read carefully)
-
-Every promote-to-existing, mint-new, and merge-same-person uses `apoc.refactor.mergeNodes` with **non-default** property-merge mode:
-
-```cypher
-MATCH (survivor) WHERE elementId(survivor) = $survivorId
-MATCH (duplicate:Person) WHERE elementId(duplicate) = $autoPersonId
-CALL apoc.refactor.mergeNodes([survivor, duplicate], {properties:'discard', mergeRels:true})
-YIELD node
-SET node.participantStatus = 'operator-confirmed',
-    node.mergedFromAutoPerson = $autoPersonId,
-    node.mergedAt = datetime(),
-    node.mergedFromAgent = 'whatsapp-import-enrich',
-    node.mergedFromSession = $sessionId
-RETURN elementId(node) AS survivorId, count(node) AS affected
-```
-
-`{properties:'discard'}` keeps the survivor's value when both nodes have the same property — the survivor (first array element) wins on conflict. The duplicate's properties that the survivor does NOT have are still copied onto the survivor; this is desirable here (auto-Person's `firstSeenAt`/`lastSeenAt` enrich the `:AdminUser` if absent). **Do not switch to `'overwrite'`** — that mode hands the conflict to the duplicate, silently replacing `:AdminUser.name` (e.g. "Joel Smalley") with the auto-Person's WhatsApp display name (e.g. "Joel S."), which is identity corruption with no error. `'combine'` would coerce conflicting scalars into arrays (`name=["Joel Smalley","Joel S."]`), which breaks downstream callers that expect string scalars. **`discard` is the only safe mode here.**
-
-`mergeRels:true` reparents every `:SENT` / `:PARTICIPANT_IN` / `:MENTIONS` edge from the duplicate onto the survivor in the same transaction.
-
-### Owner reconciliation — first row of Walk 1
-
-Phase 1 takes `--owner-element-id` as argv but does not stamp it on the Conversation node — the owner pointer is implicit (the `:SENT` edges from `:AdminUser` → `:Message` are the only structural link). The skill therefore re-asks the operator who owns this conversation, the same way Phase 1's anchor-confirmation flow does. List candidate `:AdminUser` rows:
-
-```cypher
-MATCH (u:AdminUser)
-OPTIONAL MATCH (u)-[:SENT]->(m:Message {conversationId:$cid})
-WITH u, count(m) AS senderMessageCount
-RETURN elementId(u) AS elementId, u.name AS name, u.userId AS userId,
-       senderMessageCount
-ORDER BY senderMessageCount DESC, name
-```
-
-Surface: `"Who exported this conversation? Pick from: <:AdminUser rows with senderMessageCount>"`. The `senderMessageCount` is a hint — an :AdminUser already SENT-edged to messages in this conversation is the most likely owner — but the operator confirms verbatim. Echo the chosen owner back (`:AdminUser <name> (<elementId>) — confirm yes/no`) before any write.
-
-On confirm, find auto-Persons whose display name might match the owner. Surface ALL candidates — string equality alone is not safe (owner display names drift across re-exports):
-
-```cypher
-MATCH (auto:Person {participantStatus:'auto-created', accountId:$acct, source:'whatsapp'})
-      -[:PARTICIPANT_IN]->(:Conversation {conversationId:$cid})
-RETURN elementId(auto) AS elemId, auto.name AS displayName,
-       size([(auto)-[:SENT]->(:Message) | 1]) AS sentMessageCount
-ORDER BY sentMessageCount DESC
-```
-
-Operator picks zero or more auto-Persons to merge into the owner. For each picked auto-Person, run the merge Cypher above with `survivorId = ownerElementId` and `autoPersonId = picked-auto-elemId`. `mergeRels:true` reparents SENT and PARTICIPANT_IN onto the `:AdminUser`; the auto-Person is consumed.
-
-### After each row — emit one log line
-
-`[whatsapp-import-enrich] participant action=<promoted-existing|minted-new|merged-with-id|reattributed-to-owner|skipped> name=<displayName> elementId=<survivorId-or-autoId>`.
-
-## Walk 2 — Auto-extracted observations
-
-For each `:Observation {observationStatus:'auto-extracted', insightPass:true}` `OBSERVED_IN` the conversation, dispatch by `kind`. Field mapping is non-obvious (see ingest.mjs:459-505) — get this exactly right:
-
-| kind | entity name | evidence | from | to |
-|------|-------------|----------|------|-----|
-| `mention` | `o.summary` | `o.snippet` (≤80 chars verbatim) | — | — |
-| `task` | task body in `o.summary` | `o.snippet` | — | — |
-| `preference` | `o.summary` (preference statement) | — | — | — |
-|  | `o.subject` (whose preference) | | | |
-| `observed-relationship` | `o.summary` (verb) | — | `o.from` | `o.to` |
-
-`o.summary` is the load-bearing field for mention disambiguation — `o.subject` is `null` on mentions (verified ingest.mjs:462).
-
-### kind = 'mention'
-
-Run `mcp__memory__memory-search` against `o.summary` (the mention text — e.g. "Sarah", "Sarah Chen at Acme"). Three branches:
-
-1. **Single high-confidence match AND `o.summary` contains whitespace OR matches a unique disambiguator (email, phone, role context).** Wire the edge and mark wired.
-2. **Single match BUT `o.summary` is single-token (e.g. "Sarah") with no disambiguator.** Surface: `"Mention: 'Sarah' — found one :Person <fullName> (<elemId>). Confirm wire to this person?"` (mirrors the Gate 2 pattern in [whatsapp-export-insight-write.ts](../../../memory/mcp/src/tools/whatsapp-export-insight-write.ts) — operator IS the disambiguator). On yes wire; on no mark `observationStatus='rejected'`.
-3. **Multiple matches OR zero matches.** Surface candidates (or the absence) and let the operator pick or reject.
-
-### Wire Cypher — `:MENTIONS` edge with messageId recovery
-
-The load phase does NOT stamp `messageId` on `:Observation` (the chunked Haiku has no per-message provenance). To respect the `(:Message)-[:MENTIONS]->(:Person)` semantics, recover `messageId` from `snippet`:
-
-```cypher
-MATCH (m:Message {conversationId:$cid})
-WHERE m.body CONTAINS $snippet
-RETURN m.messageId AS messageId, m.dateSent AS sentAt
-ORDER BY m.dateSent ASC
-LIMIT 1
-```
-
-Three outcomes:
-
-- **Unique or first-by-chronology match** → write `(:Message)-[:MENTIONS]->(:Person|:AdminUser)`:
-
-  ```cypher
-  MATCH (m:Message {conversationId:$cid, messageId:$messageId})
-  MATCH (target) WHERE elementId(target) = $targetElementId AND (target:Person OR target:AdminUser)
-  MERGE (m)-[r:MENTIONS]->(target)
-  ON CREATE SET r.source='whatsapp', r.evidenceSnippet=$snippet,
-                r.createdByAgent='whatsapp-import-enrich', r.createdAt=datetime(),
-                r.createdBySession=$sessionId
-  WITH r
-  MATCH (o:Observation) WHERE elementId(o) = $observationElementId
-  SET o.observationStatus = 'wired', o.wiredEdgeKind = 'MENTIONS-from-Message',
-      o.wiredAt = datetime(), o.wiredBySession = $sessionId
-  RETURN elementId(r) AS edgeId, count(o) AS affected
-  ```
-
-- **Zero match** (snippet was paraphrased / normalised by Haiku) → fall back to `:Conversation`-anchored mention:
-
-  ```cypher
-  MATCH (c:Conversation {conversationId:$cid})
-  MATCH (target) WHERE elementId(target) = $targetElementId AND (target:Person OR target:AdminUser)
-  MERGE (c)-[r:MENTIONS]->(target)
-  ON CREATE SET r.source='whatsapp', r.evidenceSnippet=$snippet,
-                r.createdByAgent='whatsapp-import-enrich', r.createdAt=datetime(),
-                r.createdBySession=$sessionId
-  WITH r
-  MATCH (o:Observation) WHERE elementId(o) = $observationElementId
-  SET o.observationStatus = 'wired', o.wiredEdgeKind = 'MENTIONS-from-Conversation-fallback',
-      o.wiredAt = datetime(), o.wiredBySession = $sessionId
-  RETURN elementId(r) AS edgeId, count(o) AS affected
-  ```
-
-The `wiredEdgeKind` property is the audit anchor — operator can grep wired observations to see which path the skill took. Surface one chat line per wire: `[whatsapp-import-enrich] observation kind=mention action=wired-mention edge=<edgeKind> elementId=<observationElementId>`.
-
-### kind = 'task'
-
-Surface a one-line proposal: `"Task: '<o.summary>' — evidence: '<o.snippet>'. Mint as :Task affecting this conversation?"`. On yes, call `mcp__tasks__task-create` with the task text and `affects=$conversationElementId` (the conversation elementId is the required adjacency — `:Task` requires ≥1 typed edge at creation per project-manager.md:44). Then mark wired:
-
-```cypher
-MATCH (o:Observation) WHERE elementId(o) = $observationElementId
-SET o.observationStatus = 'wired', o.wiredEdgeKind = 'task-created',
-    o.wiredTaskElementId = $taskElementId,
-    o.wiredAt = datetime(), o.wiredBySession = $sessionId
-RETURN count(o) AS affected
-```
-
-On no, mark `observationStatus='rejected'`. Log line: `action=task-created` or `action=rejected`.
-
-### kind = 'preference'
-
-Write a `:Preference` node with `:OBSERVED_IN` edge to the conversation. The `mcp__memory__memory-write` tool is schema-aware and the wrapped writer enforces `≥1 typed edge`. Pass:
-
-```json
-{
-  "type": "Preference",
-  "properties": {
-    "subject": "<o.subject>",
-    "preference": "<o.summary>",
-    "source": "whatsapp",
-    "scope": "<conversation scope>"
-  },
-  "relationships": [
-    { "type": "OBSERVED_IN", "targetElementId": "<conversationElementId>" }
-  ]
-}
-```
-
-Then mark the observation wired (`wiredEdgeKind='preference-written', wiredPreferenceElementId=<id>`). Log line: `action=preference-written`.
-
-### kind = 'observed-relationship'
-
-Surface: `"Relationship: <o.from> --[<o.summary>]--> <o.to>. Confirm?"`. The endpoints (`o.from`, `o.to`) are participant display names from the chat — they may be auto-Persons (now possibly merged into existing `:Person` / `:AdminUser` after Walk 1). Resolve each endpoint via `mcp__memory__memory-search` against the display name AND scoped to participants of this conversation. Branches:
-
-1. **Both endpoints resolve uniquely.** Operator-confirms; write the edge:
-
-   ```cypher
-   MATCH (a) WHERE elementId(a) = $fromElementId
-   MATCH (b) WHERE elementId(b) = $toElementId
-   MERGE (a)-[r:RELATED_TO {relationship: $relationship}]->(b)
-   ON CREATE SET r.source='whatsapp', r.operatorConfirmed=true,
-                 r.evidenceMessageIds=$evidenceMessageIds,
-                 r.createdByAgent='whatsapp-import-enrich', r.createdAt=datetime(),
-                 r.createdBySession=$sessionId
-   WITH r
-   MATCH (o:Observation) WHERE elementId(o) = $observationElementId
-   SET o.observationStatus = 'wired', o.wiredEdgeKind='RELATED_TO',
-       o.wiredAt = datetime(), o.wiredBySession = $sessionId
-   RETURN elementId(r) AS edgeId, count(o) AS affected
-   ```
-
-   `evidenceMessageIds` is best-effort — recover via `MATCH (m:Message {conversationId:$cid}) WHERE m.body CONTAINS $relationship OR m.body CONTAINS $fromName OR m.body CONTAINS $toName RETURN collect(m.messageId)[..5]` (cap at 5).
-
-2. **Endpoint does not resolve.** Surface the candidate options or the missing-Person; operator decides whether to mint via `contact-create` first or reject the observation.
-
-3. **Operator answers no.** Mark `observationStatus='rejected'`. Log line: `action=rejected`.
-
-`operatorConfirmed=true` is mandatory for every `:RELATED_TO` write — the brief's anti-hallucination doctrine (mirrors [whatsapp-export-insight-write.ts](../../../memory/mcp/src/tools/whatsapp-export-insight-write.ts)). Never write `:RELATED_TO` without explicit operator yes.
-
-## Status-update verification (Cypher silent-no-op trap)
-
-`MATCH (n) WHERE elementId(n) = $id SET n.foo = $val` against a missing node returns zero rows and zero mutations, but the query SUCCEEDS — Neo4j Community read-committed isolation does not protect co-transactional writes. Every status-update Cypher in this skill ends `RETURN count(<bound-var>) AS affected`. The skill code path:
-
-- Captures pre-walk counts (`$preParticipantCount`, `$preObservationCount` per kind) from the bulk-preview Cyphers.
-- After each transition (`participantStatus='operator-confirmed'`, `observationStatus IN {'wired','rejected'}`) records `affected` from the result.
-- Post-walk re-runs the bulk-preview Cyphers. Asserts the new counts equal `pre - count(operations-that-claimed-affected=1)`. Mismatch is a hard blocker — surface `"Status-update silent-no-op detected: pre=<n> ops=<n> post=<n>; aborting before further writes"` and yield. Never claim done with a count mismatch.
-
-## Idempotency
-
-The walk filters on `participantStatus='auto-created'` and `observationStatus='auto-extracted'`. Re-running surfaces only items still in those states. Already-wired observations (`'wired'` / `'rejected'`) and operator-confirmed participants are skipped naturally — no skill-side bookkeeping needed.
-
-This means the skill is safe to re-run at any time. Operators can enrich incrementally (one ten-row session, then another) and re-imports of the same archive (which add only the message delta per Phase 1's idempotency contract) leave existing wired state untouched.
-
-## Done — emit one chat line
-
-After both walks complete, emit `[whatsapp-import-enrich] done conversationId=<cid> wired=<n> skipped=<n> rejected=<n> ms=<n>` and return a structured summary to the admin agent in the database-operator output contract shape (see [database-operator.md](../../../../templates/specialists/agents/database-operator.md#output-contract)):
-
-> WhatsApp enrichment complete for conversation `<displayName>` (`<cid>`):
-> Participants: `<promoted>` promoted to existing, `<minted>` minted new, `<merged>` cross-displayname merged, `<reattributed>` reattributed to operator, `<skipped>` left as auto-created.
-> Observations: `<wiredMentions>` mentions wired (`<msgEdge>` from :Message, `<convoEdge>` from :Conversation fallback), `<wiredTasks>` tasks created, `<wiredPrefs>` preferences written, `<wiredRels>` relationships confirmed, `<rejected>` rejected.
-> Status-update verification: pre=`<preCount>` ops=`<opCount>` post=`<postCount>` (mismatch=`<0|N>`).
-
-## Verification (post-write — for operator audit)
-
-Run via `mcp__graph__maxy-graph-read_neo4j_cypher`:
-
-- `MATCH (o:Observation {accountId:$acct, observationStatus:'auto-extracted'})-[:OBSERVED_IN]->(c:Conversation {conversationId:$cid}) RETURN count(o)` — should be 0 after a complete enrich.
-- `MATCH (p:Person {participantStatus:'auto-created', accountId:$acct, source:'whatsapp'})-[:PARTICIPANT_IN]->(c:Conversation {conversationId:$cid}) RETURN count(p)` — equals the count of skipped rows from the chat summary.
-- `MATCH ()-[r:MENTIONS {createdByAgent:'whatsapp-import-enrich'}]->() WHERE r.evidenceSnippet IS NOT NULL RETURN count(r)` — equals `wiredMentions` from the chat summary.
-- Re-run the skill against the same conversation immediately. Bulk preview should report `auto-participants=<skippedCount>` and `auto-observations=<rejectedAndUnwiredCount>` — never duplicate edges, never duplicate `:Task`/`:Preference`.
-
-## Observability — log lines
-
-Every line emitted to chat is mirrored into the per-conversation agent-stream log (greppable via `ssh neo@<host> "grep -nE '\[whatsapp-import-enrich\]' ~/<install>/data/accounts/<accountId>/logs/<conversationId>-claude-agent-stream.log"`):
-
-- `[whatsapp-import-enrich] start conversationId=<id> auto-participants=<n> auto-observations=<n>`
-- `[whatsapp-import-enrich] participant action=<promoted-existing|minted-new|merged-with-id|reattributed-to-owner|skipped> name=<name> elementId=<id>`
-- `[whatsapp-import-enrich] observation kind=<mention|task|preference|observed-relationship> action=<wired-mention|task-created|preference-written|relationship-confirmed|rejected> elementId=<id>` (mention rows append `edge=MENTIONS-from-Message` or `edge=MENTIONS-from-Conversation-fallback`)
-- `[whatsapp-import-enrich] done conversationId=<id> wired=<n> skipped=<n> rejected=<n> ms=<n>`
-
-**Confirms correct behaviour:** one `start … done` pair per enrich run; every `:Observation` row transitions out of `auto-extracted`; every `participant` log line cites a real `elementId`; the `done` line's wired/skipped/rejected sum equals the `start` line's `auto-observations` count.
-
-**Indicates failure:** post-run grep `'observationStatus="auto-extracted"'` non-zero (silent SET no-op); duplicate `participant action=promoted-existing` for the same elementId across reruns (idempotency violation); `done` line missing from a run that emitted `start` (mid-walk crash, no rollback).
-
-## Tools this skill uses
-
-Every prescribed tool resolves on database-operator's frontmatter `tools:` list. The pre-publish gate `platform/scripts/verify-skill-tool-surface.sh` asserts this statically:
-
-- `mcp__memory__whatsapp-export-insight-pass` — Phase 2a chunked-Haiku insight extraction (chunkSize=50, overlap=5, confidence>=0.8). Lays down `:Observation` rows the rest of this skill walks. Owns the LLM half of WhatsApp ingest — Phase 1 has none.
-- `mcp__graph__maxy-graph-read_neo4j_cypher` — bulk preview, evidence reads, messageId recovery, owner-reconciliation lookup.
-- `mcp__graph__maxy-graph-write_neo4j_cypher` — `apoc.refactor.mergeNodes`, `:MENTIONS` and `:RELATED_TO` MERGEs, status-update SETs.
-- `mcp__memory__memory-search` — entity disambiguation for mentions and observed-relationship endpoints.
-- `mcp__memory__memory-write` — `:Preference` node creation with `:OBSERVED_IN` edge.
-- `mcp__contacts__contact-create` — mint-new-Person path.
-- `mcp__tasks__task-create` — `:Task` node creation with `affects=$conversationElementId`.
-
-Raw Cypher and `cypher-shell` are forbidden in this skill (per [database-operator's LOUD-FAIL prerogative](../../../../templates/specialists/agents/database-operator.md#prerogatives)). Every write goes through the MCP tool surface above. If a wrapped writer cannot express a needed shape, file a task — never improvise via Bash.
-
-## What this is not
-
-- **Not** Phase 1. Parse and archive-write live in `whatsapp-import` (the deterministic Bash entry, LLM-FREE). This skill never re-parses. The Haiku insight pass lives here — Step 0 above is the one sanctioned LLM entry for WhatsApp ingest, and it is invoked consciously by the operator, not silently on archive-write.
-- **Not** automatic. Every transition out of `auto-created` / `auto-extracted` requires an operator action — no auto-promotion, no auto-mention-acceptance, no batch confirmation. Compress-at-ingest doctrine requires per-row operator judgement.
-- **Not** cross-conversation. The walk is scoped to one Conversation. Cross-conversation participant deduplication (the same person under two conversations) is operator-driven graph hygiene via [database-operator.md §Dedup merges](../../../../templates/specialists/agents/database-operator.md#dedup-merges), not this skill.
-- **Not** a backfill tool. This skill assumes the Phase 1 contract and refuses to walk a conversation without `c.lastImportedAt`.