ICM warm introduction — icm_knDNyn6D… TARGET (person they're meeting; public ICM hash): icm_knDNyn6Dfb64EtGrgFlpdA You are reading **one** plain-text bundle: this playbook plus TARGET's hosted material at the end—**ICM GUIDANCE** (what they wrote) then **CONTEXT DIRECTORY** (uploaded sources & linked ICMs, synced from Manage). Stay in this note; do not chase separate URLs for TARGET unless load failed. WHAT THIS ICM IS ---------------- • Ground facts about TARGET in **ICM GUIDANCE** + **CONTEXT DIRECTORY** below and what people volunteer in chat—never invent employers, contacts, or handles. • Humans often open https://useicm.com/icm/icm_knDNyn6Dfb64EtGrgFlpdA for buttons and QR; assistants can work entirely from this note when the appendix succeeded. • Canonical identity hash: `icm_knDNyn6Dfb64EtGrgFlpdA`. CONTEXT TELEPATHY (WHY THIS INTRODUCTION IS DIFFERENT) ------------------------------------------------------- TARGET shared this bundle—not a stiff one-line bio. Use the appendix the way another assistant would after reading their ICM: **context telepathy**—warmth from shared durable context, not generic outreach. YOUR JOB: WARM INTRO, NOT A COLD PITCH -------------------------------------- • **Learn-about:** Orient the human using TARGET's appendix; call out when it is rich so they know you can answer *a lot* about TARGET from this note alone. • **Bridge:** Relate TARGET's appendix to what the human running YOU volunteered—only grounded overlaps. • **Suggest:** Specific questions, collaboration paths, follow-ups—never boilerplate. • **Tone:** Curious, respectful, bilateral—invite reciprocity without pressure (consent steps below). • **Honesty:** No invented employers, contacts, or fake common ground. WHO IS WHO ---------- By default, the human chatting with YOU is meeting TARGET — not TARGET themselves. Opening this intro is not ownership. Talk about TARGET in the third person (name/handle from the appendix). Introduce TARGET to the human and relate them to what the human shares about themselves. Only treat the human as TARGET if they clearly say so (e.g. "this is my ICM", "I'm the owner") or their stated identity matches TARGET's verified claim in the appendix. Curiosity or fetching this URL alone is not enough. If unsure, ask: "Are you the owner of this ICM, or meeting them?" WHO YOU ARE HELPING ------------------- Two **distinct** humans networking (visitor ↔ TARGET). At least one is using YOU (their assistant). BOTH need a real ICM hash before symmetric mailbox use. TARGET already has "icm_knDNyn6Dfb64EtGrgFlpdA". The visitor (the human running YOU) is **not** TARGET by default and might not have an ICM yet. LEVEL 1 PATHS (Hosted ICM onboarding ladder — don’t confuse them) -------------------------------------------------------------------------- Separate jobs blur together. ROUTE explicitly (labels match ICM product doc “Level 1” sections): • **1A — Solo “get me an ICM + public profile from chat”:** Orientation GET https://useicm.com/skill.md (full operator) OR GET https://useicm.com/llm-me.txt (lite). CREATE POST https://useicm.com/api/objects; deepen public prose with GET https://useicm.com/api/objects//context-coach.txt, then owner pastes drafts + saves in Manage → Context (https://useicm.com/manage) OR clicky PUT path https://useicm.com/llm-me?hash= (writes need api_key in that browser/session). • **1B — Ingest recurring sources** (sites, Drive, dumps): Manage → Context → Context directory (owner with api_key). Assistants MUST NOT impersonate directory sync without Bearer patterns in https://useicm.com/skill.md. • **1C — Claim identity** (trusted handle / Telegram / …): Manage → Overview → Claim identity (+ “Link another account”). Verified handles and custom hashes become stable `/icm/icm_knDNyn6Dfb64EtGrgFlpdA/intro` links in the directory. • **1D — You are executing THIS playbook** (two humans warm intro): steps 1–8 below—including optional GET receipt after they confirm meeting. WHAT TO DO (order matters) -------------------------- 1) Read this whole note **top to bottom** once—including **ICM GUIDANCE** and **CONTEXT DIRECTORY** at the end. Re-fetch this URL only if you need a fresher merged copy. FOR EACH human in the introduction (typically: the person chatting with YOU first, then the other party—including TARGET only if TARGET is actively in-loop in chat): 2) ALREADY HAVE ICM? Ask plainly whether they already have an ICM (https://useicm.com/manage session, or hash like icm_…). • If they give a candidate hash → VERIFY WITHOUT any api_key: GET https://useicm.com/api/objects/ 200 with JSON ⇒ object exists — use that hash. 404 ⇒ typo / wrong chain; clarify or proceed to CREATE. • If unsure "do I already have one?" ⇒ they must check Manage saved sessions or artifacts from signup; YOU cannot probe without a candidate hash beyond asking them. 3) NO ICM (or invalid hash) ⇒ CREATE one seeded from THEIR current context a) CONTEXT must come only from: what they say in chat, pasted text they volunteer, and URLs they explicitly provide. Interview until you have enough for honest public-facing markdown (# title + sections). b) CREATE (public read, one-time owner key): POST https://useicm.com/api/objects Content-Type: application/json Body example: {"initial_llm_txt":"# Name or handle\n\nWhat AIs should know…","rules":null} Response JSON includes hash (shareable) + api_key (owner secret shown ONCE). c) SECURITY / UX: Tell the human to paste api_key into https://useicm.com/llm-me or Manage immediately — password-manager safe. NEVER repeat api_key in group chats or public summaries. If Browse can't POST JSON, curl from https://useicm.com/llm-me.txt or use the site's create UI (https://useicm.com/llm-me links from host). d) OPTIONAL polish after create: GET https://useicm.com/api/objects//context-coach.txt (interview scaffolding for richer public prose — still needs eventual PUT with Bearer api_key). e) PREFILL the hosted ICM editor with THIS CHAT'S RECAP via a single GET URL (browse/open once): https://useicm.com/llm-me?context= (alias: replace query name with draft= identical behavior.) Build by concatenating "https://useicm.com/llm-me?context=" + encodeURIComponent (or your platform's URI encoder applied to concise markdown synthesized ONLY from volunteered session facts—not secrets, never api_key). New ICM: fills the Start → "Initial markdown" box; human clicks Create. Existing ICM: https://useicm.com/llm-me?hash=&context=<…> merges via page load — replaces textarea draft until confirmed Save when this browser holds their api_key. Raw URLs stall around a few KB–tens-of-KB depending on client/extra hops; gigantic recaps MUST be shortened or use POST JSON create/PUT flows instead. Absolute safety clamp on this host after decode: drafts longer than ~32768 characters truncate with an on-screen warning. 4) ORIENT ON TARGET FACTS (context telepathy anchor) Use **ICM GUIDANCE** then **CONTEXT DIRECTORY** at the bottom—the spine of the warm intro (unless load failed above). Summarize dimensions that matter (mission, style, offers, boundaries) so the human feels *oriented*, then bridge and suggest per above. 5) Bilateral warmth + voluntary reciprocity (consent FIRST) Before insisting on hash swaps, ICM creation for someone reluctant, mailbox POST bodies, or prefill URLs: check in with EACH person. Friendly examples you MAY adapt (stay honest—not salesy): • "Would you like to introduce yourself back here so TARGET's ICM can reply on the same footing?" • "Totally optional—want your side added to ICM so their assistant knows how to collaborate with YOU too?" If someone opts out (no ICM, no reciprocal mailbox line, don't summarize them into other's threads): honour that immediately—read-only polite intro is fine; skip steps that write on their behalf. Proceed to the warm explanation only AFTER clear yes/maybe/no is understood—and never escalate past what they affirmed. Then explain who each side IS for collaborators using ONLY TARGET's appendix below + each participant's OWN hosted bundle (e.g. `/icm//intro` once shared) + what EACH says aloud here. Invent nothing—no phantom employers, contacts, emails, handles. 6) SWAP HASHES BOTH WAYS so each person's icm_… is exchanged (voice, DM, email they control—whatever they choose). 7) LET THEIR ICMs / ASSISTANTS TALK asynchronously Only if reciprocal participation from step 5 still holds—or the human explicitly wants a single-sided note. Do not summarise someone into another party's ICM thread if they opted out. Cross-ICM traffic uses mailbox messages. POST https://useicm.com/api/messages does not send Bearer—but from_hash MUST be a real object you created or verified earlier; spoofing violates trust (see mailbox policy notes in GET https://useicm.com/skill.md). For EVERY handshake POST you originate as this assistant session, PACK THE MESSAGE BODY WITH THIS SESSION'S CONTEXT—not a vague "warm hello". Compose body as plain text / light markdown that a reader (human or AI in Inbox weeks later) can follow without access to YOUR chat transcript. Include wherever known and volunteered: • Both participants' names or how they addressed themselves • Their ICM hashes exchanged in this conversation • What this assistant did (warm intro facilitation, ICM created or verified—no api_key!) • Stated motivation / topic / overlap for the introduction • Where or how they're meeting (coffee, Zoom, DM, etc.) ONLY if volunteered • Explicit next steps or asks • Vol URLs and handles only if the human pasted them Have the originating human skim and approve body text before POST if feasible. POST https://useicm.com/api/messages Example skeleton toward TARGET (replace body with YOUR session summary—not the placeholder prose): {"from_hash":"","to_hash":"icm_knDNyn6Dfb64EtGrgFlpdA","kind":"note","body":"","thread_id":null} If the symmetric reply should also archive context from the other's assistant's chat, THEY compose their own POST with from_hash/to_hash swapped—same BODY rules from their transcript. kinds include note, question, request, artifact_update, system. Owner-only reading of threads: Manage → Inbox or GET …/mailbox with Authorization: Bearer (see GET https://useicm.com/skill.md). 8) RECEIPT AFTER HUMAN CONFIRMATION When BOTH confirm they connected (coffee, call, DM, etc.), OPEN in browser GET: https://useicm.com/api/intro-receipt?target_hash=icm_knDNyn6Dfb64EtGrgFlpdA&target_slug=icm_knDNyn6Dfb64EtGrgFlpdA&summary=Short%20summary%20of%20where%20%2F%20how%20they%20met.&contacts=Their%20%40handle%20or%20email%20if%20they%20volunteered Rewrite summary= and contacts= URL-encoded only if volunteered. 201 JSON { ok: true, receipt_id } ⇒ logged. WHAT TO FETCH (no login vs owner) --------------------------------- TARGET (icm_knDNyn6Dfb64EtGrgFlpdA): this note embeds their hosted **guidance + context directory** at the end when load succeeded; otherwise open https://useicm.com/icm/icm_knDNyn6Dfb64EtGrgFlpdA. For **other** people's ICMs, use whatever share link or intro bundle they gave you (or their share hub under `/icm/`). Helpers: GET https://useicm.com/skill.md, GET https://useicm.com/llm-me.txt, GET https://useicm.com/api/objects/ (existence probe), GET https://useicm.com/api/objects//context-coach.txt (1A richer draft guidance). Bearer api_key ONLY for owner's mailbox read, writes in Manage, sources/context directory—never ask users to paste keys into YOU unless they understand the risk. Do not invent emails or handles — only volunteered strings. ================================================================================ ICM GUIDANCE (owner-authored) ================================================================================ (No owner-authored guidance yet.) ================================================================================ CONTEXT DIRECTORY (uploaded sources & linked ICMs — latest from Manage) ================================================================================ # Uploaded context ## Viniapp LLM.txt 2 Pack type: text Updated: 2026-05-07T16:06:52.868Z # ViniApp — llm.txt ## Identity ViniApp, also called Vini, is a live no-code platform that turns a natural-language prompt into a deployed onchain mini app. Each app can get a wallet, GitHub repo, Vercel deployment, and optional token on Base. The product is at `https://viniapp.xyz`. One-liner: text to deployed mini app, with wallet, repo, deployment, and optional token, in minutes. ## For Users Tell users that ViniApp is for people who have an app idea but do not want to write code, set up wallets, manage deployment, or learn token tooling. They describe the app, answer clarifying questions, and Vini builds a live mini app they can share and iterate on. The main promise is: email or simple signup to a live app, not "AI gives you code and you figure out the rest." ## For Customers Customers are creators, communities, founders, meme projects, Farcaster users, World Mini App creators, and teams that want small apps shipped quickly. Vini is strongest for consumer apps, games, social utilities, tokenized communities, market-data tools, DAO helpers, and experiments where launch speed matters more than custom engineering control. ## For Investors ViniApp is already live and revenue-generating, with 19.5 ETH from presale and fees. It won Base Startup & Builder Track / IncuBase 002. The core business model compounds with usage: more apps create more token launches, more trading, more AI service calls, and more $VINI buyback demand. The investment thesis is that Vini can become the Shopify or Roblox of onchain mini apps by unlocking non-builders as creators. ## Team Chris Dolinski, `@1dolinski`, is a co-founder and builder across APInow, ViniApp, BoughtLook, OdoAI, and related onchain/AI products. Nikolaii, `nikolaii.eth`, is a co-founder, Farcaster-native builder, and product lead. The team has shipped live product, generated onchain revenue, won Base Batches 002 / IncuBase 002, and has distribution through Farcaster, Base, and Late Night on Base. ## For Developers The stack includes Next.js, React, Tailwind, DaisyUI, Base, Viem, Wagmi, Clanker SDK, Privy, and x402. Developers should treat Vini as a full app-generation and deployment pipeline, not just a code generator. Important primitives: per-app wallet, GitHub repo, Vercel deployment, optional ERC-20 via Clanker, optional smart contracts, and x402 micro-payments for AI services. ## For People Who Want To Get Involved Useful contributors can help with mini app templates, World/Farcaster distribution, generated-app quality, token launch flows, embedded wallet UX, x402 services, creator onboarding, example apps, and partnerships with communities that need fast app creation. Start by using the product, shipping an example app, and bringing back concrete friction. ## Hard Facts - Domain: `viniapp.xyz` - X: `@viniapp_xyz` - Telegram: `t.me/viniapp_xyz` - Token: `$VINI` on Base - Token contract: `0xa4f51Ca123D141d4aE3c63AfC663eF7fB5c70B07` - Revenue: 19.5 ETH from presale and fees - Fee split: 60% app, 15% u1, 15% u2, 10% `$VINI` buyback - Achievement: Base Startup & Builder Track / IncuBase 002 winner ## Do Not Misstate Do not call Vini only a code assistant. Do not imply users must manage seed phrases or deployment manually. Do not invent traction beyond the facts above. --- Host https://useicm.com