dev.nakodo/nakodo

Put a short update about what the user built or worked on today onto their private record, improving future matches. Draft the snippet yourself from the session (2-4 sentences, concrete: what was built, what it shows they can do, what they struggled with), PII-free like the profile — no names, links/URLs, @handles, emails, phone numbers, or identifying company/product names; describe the work. Show it to the user, and ONLY call this after they explicitly approve that exact text. The snippet joins their anonymous card — searching agents see the work described, never who did it.

Connect Telegram so the user hears about introductions on their phone, between sessions. Only call when the user asks for phone/Telegram notifications, or accept their decline of an offer — connecting is their choice. Returns a t.me link: give it to the user EXACTLY as returned and tell them to open it ON THEIR PHONE — that is where the Telegram app lives; a desktop browser with no Telegram app installed cannot open it. They tap it and press Start in their own Telegram app, which is what completes the connection (the link expires in 30 minutes — mint a fresh one if it lapses). What the bot sends, and all it ever sends: an introduction is waiting (no card content, no names — those stay on the private page), you both said yes, and a message is waiting. The Telegram connection is notification-only, never shared, never on the anonymous card, and never used for matching — same law as the notification email. The user can disconnect any time by sending /stop to the bot or asking here (disconnect=true), and delete_me removes it with everything else.

Register the user with the matching network: their agent-drafted, human-approved profile. ONLY call this after the user has explicitly approved the exact profile text — never with unapproved or inferred content. The profile must carry no identity (no names, links/URLs, @handles, emails, phone numbers, or company identifiers; city-level location at most) — it is the anonymous card itself, and the service lint-rejects identifying text. Usually called during the onboarding flow started by find_collaborator.

Permanently delete the user's entire record from the matching network: profile, all snippets, all asks, email, name — everything. Irreversible. Confirm with the user before calling; only call with confirm=true after they have explicitly said yes.

Get the user an outside perspective on what they are building — a warm introduction to the right person, matched on their actual work. Use this when the user wants to: get an outside perspective, honest feedback, or a second pair of eyes on what they are building; find someone to help with design, code, marketing, or distribution strategy; find a collaborator, co-founder, or teammate for their project; get feedback from someone building something similar; or meet other builders working on related problems. This registers their need with a private matching network and hands you the anonymous pool to match against yourself. The user's profile carries no identity — agents match on the work, not the person; identity and contact are revealed only when both sides say yes. There is no feed and no browse surface: agents search so humans don't scroll, and the only human-visible output is an introduction. Declines are invisible — and so is being considered: anyone an agent passes over never knows. If the user has no profile yet, this returns onboarding steps.

Show the user everything the network has on record about them — their profile, all approved snippets, and open asks. Shows nothing about anyone else, because nothing about anyone else is ever visible.

Propose an introduction between the user and the person behind one anonymous pool card (from find_collaborator). Call this only after the user has looked at the card and said to go ahead. The person receives an anonymous card — no identity — assembled from the user's own profile, their ask, and your why_for_them, and they accept or decline. why_for_them must state what the OTHER person gains: an introduction that only serves the user gets declined. Declines are invisible: if they pass, the user never learns it was them, and no one the user passed over ever knows they were considered. Contact details are exchanged only by the two people themselves, after both say yes — never by the platform.

Reopen the conversation with someone the user has ALREADY been introduced to — a prior-connection card from find_collaborator — by posting a short message into the thread the two of them already share. Use this instead of propose_intro when find_collaborator surfaced a prior connection that fits the new ask: there is no new introduction and no re-acceptance, you are picking a relationship back up. Draft a message that carries the user's new ask, show it to them, and ONLY call this after they approve the exact text (approved=true) — nothing is ever sent unapproved. The other person is notified the normal way, as with any thread message. If the user would rather not, do not call this — passing on a reconnection tells the other person nothing.

File a short piece of the user's feedback about a NAKODO moment — their reaction to how Nakodo itself worked. Use it ONLY for reactions to Nakodo's own moments: onboarding, an anonymous card, an introduction's quality, the reveal, the message thread, or waiting for a match. NEVER use it to monitor or report on the user's own work, mood, or session in general — only their reaction to Nakodo. How it works, identical to how snippets work: when the user reacts to one of those moments you may ask one or two gentle questions, then draft a short note and show it to them; it is filed ONLY after they approve the exact text (call with approved=true). Nothing about their reaction is ever captured without their explicit approval. Honest framing to give the user: this feedback is drafted by your agent, approved by you, read by the humans building Nakodo, never shared beyond them, never used for matching.

Update the user's private notification email and/or the reveal name a match sees after a mutual yes. Both are PII-store only — never shared, never shown on the anonymous card, never used for matching. Use it to add an email later so the user is notified of introductions between sessions, change it, change the reveal name, or remove the email entirely. Nothing here touches the matching profile.