intake-relationship

---

name: intake-relationship description: Intake a contact's raw domain materials (voice notes, emails, PDFs, videos, links) and respond with a designed preview artifact that mirrors their own domain back to them as navigable structure. The first-touch onboarding motion for domain-rich human prospects — extract their materials into a Neotoma knowledge graph, render a rendered_page preview, mint a guest share link, and surface it for operator-approved sending. Owned/invoked by Sturnus. triggers: [intake-relationship, /intake-relationship, intake materials, prospect preview] user_invocable: true entity_id: ent_55b08c28fc379ceccb4f37d4

Purpose

Turn a prospect's scattered domain materials into a preview that shows them their own work transformed into navigable structure. Mirroring someone's tangle back to them as a clean, connected artifact converts far better than explaining the product — it demonstrates Neotoma's value (canonical graph + field-projection: author once, project many) on THEIR content, and activates them as a collaborator. Worked pattern (a movement-teacher pilot): 3 voice notes + 2 emails (3 PDFs, 4 videos) → ~20-entity domain graph → a designed rendered_page manual → a guest link → the prospect started sending source material to feed their manual.

When to use

• Default first-touch for domain-rich HUMAN prospects (teacher, researcher, founder, practitioner with scattered knowledge).
• NOT for developer/infra evaluators — they mirror codebase/data (use analyze / remember-codebase).
• Trigger when a contact sends materials describing their domain/needs, or when Sturnus develops a domain-rich prospect.

Procedure

1. INTAKE (any source): gws gmail (never the Gmail MCP), gws drive for attachment links, WhatsApp audio, links. Audio/video → transcribe (execution/scripts/transcribe_audio.py; for video, download + ffmpeg frame-extract to interpret before describing). PDF → download + pypdf text extract; note image-heavy pages. Store each as the right Neotoma entity (transcription/email) with provenance, REFERS_TO the contact + PART_OF the conversation. Store the contact as a person (enrich via Gmail/LinkedIn first; never a bare stub).
2. EXTRACT THE DOMAIN GRAPH: model their domain as entities + relationships (register schemas if greenfield). Edges: PART_OF (membership), DEPENDS_ON (ordering/readiness), REFERS_TO (provenance). The relationships are the product — they dissolve the tangle. Every fact traces to its source artifact.
3. RENDER THE PREVIEW (rendered_page): lead with their own organizing principle in their language; show worked depth in one area + a progress view (done/pending); include a connection map of illustrated cards (not abstract flowcharts) from real edges. Localize; warm; no brand-name concepts unless opted in. Illustrations as inline WebP data: URIs (self-contained, CSP-safe). ⚠️ REQUIRED accuracy spot-check: AI illustrations have defects (one pilot produced a three-arm pose, then a non-bound bind). Visually verify EVERY illustration before sharing; binds/twists/multi-limb poses are most error-prone — regenerate or fall back to a real video still. ⚠️ HOW TO RENDER — defer to the draft-rendered-page skill (the canonical authority for ALL rendered_page output, here and in any multi-page hub it grows into); invoke /draft-rendered-page or read its SKILL.md and follow its checklist rather than authoring CSS from scratch. Non-negotiables it enforces: light+dark mode via CSS-variable defaults + @media (prefers-color-scheme: dark) + html{color-scheme:light dark}; a pure-CSS Light/Dark/System toggle; host-template color overrides (th/pre/code/a with !important); no hardcoded inline color styles; WCAG-AA contrast in both themes; and the post-store verification fetch.
4. MINT THE SHARE LINK: served at GET /entities//html; schema is guest_access_policy: submitter_scoped, so mint a guest_access_token scoped to the page and share …/html?access_token=. Use the Neotoma publish/share tool once neotoma#1619 ships. Keep the URL un-truncated (long query strings break on copy/paste). For a multi-page set (a hub + sub-pages), every inter-page link MUST carry the TARGET page's own access_token — guest tokens are page-scoped, not a session, so a bare /entities//html link 401s for the recipient. Build an {entityId: token} map, stamp every href, and verify zero tokenless /entities/.../html links on each live page before surfacing (per draft-rendered-page).
5. SURFACE FOR OPERATOR APPROVAL — DO NOT AUTO-SEND: draft the outbound message (contact's language, warm, grounded) + the link; the operator sends (Sturnus boundary).
6. ITERATE: on response with more material/feedback, loop to step 1 and extend the graph + page. Continued sending is the activation signal.