Presales meeting prep

Generic for any company, industry or person. Never hard-code a client, sector, regulation or name into this skill. Everything specific is discovered by the agents and written to the client folder.

1. Inputs

If deal-context.json exists (written by presales-ai), read account, persona, competitor and lane from it and do not ask for them again. Add your output paths under outputs.meeting_prep.

Use what the user already gave. Ask once, in one message, only for what is missing and needed:

• Company (name or URL), plus the person and role. Either can be optional.
• Priorities, background, meeting date.
• Known rivals the user wants included (optional).
• Product URLs to deep dive (optional, else the agents pick the main products).
• Stakeholder LinkedIn URLs (optional) and client data files (optional).
• Depth: quick, standard (default) or deep.
• Our side: default Ciklum offers (engineering, AI, modernization, data, delivery pods).
• Save location: default ~/Documents/Pre Sales/<Company>/ unless memory names another. State the folder in the first message.

2. Waves

Waves run in sequence. Agents inside a wave run in parallel in ONE message. Build prompts from references/agent-prompts.md. Every agent writes its own file under <folder>/research/ and returns 10 lines or fewer. Never read agent transcripts. After each wave give the user 4 to 6 takeaways.

Notes:

• Wave 0 first, always. A wrong premise poisons every later file. Later agents read 00-facts.md first and update it when they correct a fact. The checkers in wave 3 spread corrections to every file.
• Walled sites. If LinkedIn or another source is login-walled, say so and offer to read it through the user's logged-in browser, read only. Never like, follow, connect or message.
• Weekly reports. Before wave 2, follow references/routine-hook.md to find the user's own industry reports and feed them to file 19.
• Stakeholder mode. With LinkedIn URLs, 02-people adds conversation openers per person, framed around AI and their remit.
• Client data. With files, add 20-client-data.md: what the data shows and what we could solve with it.

3. Brief

Write 00-meeting-brief.md from references/brief-template.md.

• Grep the research files for conflicting numbers and dates, settle them from 00-facts.md or flag them.
• Keep the core to about 2 pages, with deeper sections after.
• Tag anything inferred.

4. Optional outputs

Offer these early, build only on a yes:

• HTML brief as an Artifact. Load artifact-design first, then follow references/html-template-notes.md.
• Visual style: when the user says yes to the HTML brief, deck or architecture diagram, ask once for a style from references/visual-styles.md (A Duotone line, B Isometric, C Solid glyph tiles, D Blueprint, plus 1 or 2 extras, recommended first) and use it for every visual in the pack.
• Pitch deck via Artifact quickstart intent: slides, outline in references/deck-outline.md. List every slide number and title on delivery.
• Technical primer (07-technical-primer.md): glossary of every term of art, why each discovery question is asked, what good and bad answers sound like, pains in plain English.
• Discovery plan (08-discovery-plan.md): open questions per persona, depth set by the lane in deal-context.json (lane 1 is a short qualification check, lane 2 is full discovery that ends in agreed technical success criteria). Template: references/scripts-and-discovery.md.
• Scripts (09-scripts.md): call opener, a 3-email sequence (first touch, follow-up, after the demo) and a voicemail line, each tied to one pain and one data point from the research. Drafts only, a person sends them.
• Others: leadership deck, exec memo, talk track, stakeholder map, KPI dictionary, capability or feature catalogue (top N with user stories, value and ROI), bid gap register, ROI page, architecture diagram (draw.io), objection drill, follow-up email draft.

5. Close

Ask "what did we miss and why", list open gaps and [placeholders], and offer a better reusable prompt for the next run.

Rules

• Public professional information only. Never personal, family or home details.
• Every claim gets a URL, a date and a [verified] or [inferred] tag.
• Never invent metrics, quotes or our case studies. Use [placeholders] and list them.
• Outages, complaints and third-party data are things to ask about, never facts to state to the client.
• Dates. Today bounds the window, weighted to the last 3 months. Convert relative dates (2w, 1mo) to approximate dates.
• Style gate. No em dashes and no semicolons in any generated text. Grep every file before delivery and fix hits.
• Diagrams. Icons at least 80px, glyphs at least 64px, short labels.
• Pages. Check the rendered layout and every toggle state before saying done.
• Tokens. Full output goes to files, summaries stay short, waves are sequential.