The AI tool landscape has fragmented. Where a year ago you had ChatGPT and Claude as general assistants, today you have a dozen specialized tools: Claude Code and Cursor for engineering, v0 for React components, Lovable and Bolt for full-stack apps, Figma Make for UI prototypes, Perplexity for research, Notebook LM for source-grounded analysis, and Obsidian for durable markdown notes and linked knowledge bases. Each tool is dramatically better at its specialty than a general assistant. Each, used well, can produce real artifacts that previously required a specialist. The catch is the same as the general-purpose case, amplified: these tools are starved of good context. They’re excellent at producing artifacts from well-shaped prompts; they’re mediocre at producing artifacts from thin prompts. The quality of what you get out is determined by what you put in. The marginal cost of producing an artifact has dropped to near-zero; the marginal cost of producing a good artifact is still dominated by the human time spent shaping the prompt. And the prompts that produce the best artifacts share a recognizable property: they encode context from conversations you’ve had — strategy discussions, technical reviews, customer calls, project planning sessions. The best prompt for Claude Code explains the codebase, the problem, the constraints, and the approach the way the engineering team discussed it. The best prompt for Perplexity frames the research question the way you’d frame it for a colleague already in your context. The best prompt for v0 describes the UI the way the design discussion described it. That context is in your head — sometimes — and otherwise in meetings whose substance has already faded. The result is AI work that’s significantly worse than it could be — sometimes 70% there with manual fixes filling the gap, sometimes 30% there with the human giving up and doing the work the slow way. This guide is a specific instance of the workflows pattern, applied to the AI tool stack. It generalizes what the meeting-to-prototype workflow does for visual prototyping tools — extending the meeting-to-prompt pattern across every category of specialized AI tool you use.Documentation Index
Fetch the complete documentation index at: https://docs.tryearmark.com/llms.txt
Use this file to discover all available pages before exploring further.
The strategic frame
Worth being explicit about up front: as the AI tool ecosystem fragments into specialists, the value of a unified contextual substrate increases. Whatever AI tools you use today, you’ll use more of them tomorrow. The meeting → prompt workflow is how you make each new tool immediately useful instead of requiring weeks of prompt-craft learning. The compounding effect: a modern PM using Claude Code well produces engineering output that previously required ticketing the engineering team. A modern designer using v0 well produces React components that previously required engineering collaboration. A modern founder using Perplexity well produces market research that previously required hiring an analyst. The constraint on this expansion is not the AI tools — they’re capable enough. The constraint is the contextual translation: each tool needs specific, well-shaped prompts. The translation happens either in the user’s head (lossy, memory-limited) or in a manual prompt-writing process (slow, competes with the actual work). Earmark closes the translation gap. Conversations get captured; templates shape them into prompts each tool can use; the tools produce artifacts that are usable on the first attempt rather than after heavy editing.Foundation
Map your AI tool stack
Before standing this up, inventory what you actually use and what each tool is good at:| Tool category | Tools | Best for |
|---|---|---|
| Code generation | Claude Code / Cursor / Aider | Code generation, refactoring, multi-file changes |
| UI components | v0 by Vercel | React components, Tailwind UI |
| Full-stack apps | Lovable, Bolt.new | Web apps with backend |
| UI prototypes | Figma Make | UI prototypes with design-system context (see meeting-to-prototype) |
| Coded engineering tasks | Codex | Engineering tasks shaped by architecture docs |
| Engineering tickets | Linear | Tickets that flow from architectural decisions |
| General analysis | Claude / ChatGPT (Projects mode) | Analysis, writing, structured thinking |
| Web research | Perplexity | Web research with citations |
| Source-grounded analysis | Notebook LM | Analysis across uploaded documents |
| Slide deck generation | Gamma, Beautiful.ai | First-draft slide design from structured content |
| Knowledge vault / linked notes | Obsidian | Meeting-derived notes, analyses, and prompt libraries in markdown; wikilinks and tags for retrieval |
| Persistent assistants | Custom GPTs, Claude Projects | Persistent assistants for specific recurring tasks |
Tool-specific prompt format expectations
Each AI tool has prompt patterns that work better than others: Claude Code, Cursor, Aider — concrete file paths and language/framework specifics; existing code patterns to follow; acceptance criteria (what “done” means); style conventions; for multi-file changes, the scope and interaction explicitly. v0 by Vercel — component name and shape; design system context (Tailwind, shadcn/ui, or named tokens); states to include (loading, empty, populated, error); behavior (interactivity); copy/labels (real, not placeholder). Lovable, Bolt.new — user-story-anchored (what the user does in the app); backend requirements (data, auth, persistence); specific UI states and flows; stack constraints. Claude / ChatGPT for analysis — the question stated clearly; the data or context (paste or attach); the reasoning approach you want; the output format (table, list, prose, structured); the audience. Perplexity — a research question, not a search query; context for why you’re asking; source quality preferences (academic, recent news, primary sources); output format. Notebook LM — pre-uploaded source documents; the question framed against the sources; citations expected. Obsidian — markdown-native output;[[wikilinks]] to related notes where cross-referencing helps; YAML frontmatter when metadata matters (meeting date, project, tags); folder or MOC structure the vault already uses. For AI plugins in the vault (Copilot, Smart Connections, and similar), paste shaped prompts the same way you would into Claude or ChatGPT — the vault is the context layer; Earmark supplies the meeting-grounded prompt.
The templates below produce prompts that match these expectations. The accuracy of the match is what determines tool output quality.
Prompt conventions
A few conventions worth establishing:- Provenance. Every prompt notes the source meeting. When the artifact comes back, you can trace it to the conversation that informed it.
- Constraint blocks. Standard constraints (tone, length, format, do-not patterns) live in reusable blocks you append to prompts of a given type.
- Output format specification. Always explicit. “Output as markdown with H2 sections” beats hoping the AI picks the right format.
- Length limits. Tools have context windows; longer isn’t always better. Most prompts work best in the 300–1500 word range.
Ownership
The simplest ownership model in the workflow series: the user owns their own prompts. Prompts don’t typically need cross-team review — they’re personal productivity artifacts. When a prompt is worth sharing (particularly well-shaped, applies to a recurring use case), it can graduate to a shared prompt library. But the default is personal.The four templates
Template A — Code generation prompt
For Claude Code, Cursor, Aider, v0, Copilot. The prompt produces code; the tool runs it.Template B — Analysis or research prompt
For Claude, ChatGPT, Perplexity, Notebook LM when used for analytical or research tasks.Template C — Document generation prompt
For Claude, ChatGPT, or specialized writing tools used to draft long-form documents.Template D — Agent / persistent system prompt
For AI tools that maintain state across conversations — Claude Projects, Custom GPTs, persistent assistants you’ve configured for ongoing work. The prompt primes the AI for an entire ongoing relationship.Save them as workspace templates
Start with the AI tool you use most
Most users start with Template A (code generation) if they’re engineering-focused, Template B (analysis) if they’re operating-focused, or Template C (document generation) if they’re communications-focused. Save the most-relevant first.
Tune each template to your most-used downstream tool
The template structure is generic; the specific prompt-format-expectations vary by tool. Adjust the saved template to match your specific tool’s conventions.
Save with Private visibility (most often)
Prompts are typically personal. Save with Private visibility unless you’re standing up a team prompt library. See Custom templates.
Running the workflow on a single meeting
Decide what you'll produce with the downstream AI tool
“I want Claude Code to refactor this module” → Template A. “I want Perplexity to research this market segment” → Template B. “I want Claude to draft this memo” → Template C. “I want a Custom GPT for ongoing architecture discussions” → Template D.
Attach the right template
Match the template to the downstream tool category. See Before a meeting for pre-seeding meetings where you anticipate generating prompts.
The 10-to-15-minute curation pass
The curation is lighter than for most workflow artifacts because the artifact is a prompt, not a final document. But it’s not trivial — the prompt’s quality determines the downstream tool’s output quality.
- Read the prompt as if you were the downstream AI tool. Is the task clear? Are the constraints unambiguous?
- Check tool-specific conventions. Does the prompt match how the target tool expects to be prompted?
- Cut what the tool doesn’t need. Meeting transcripts contain conversational noise; not all of it helps. Cut.
- Add what the model didn’t capture. Sometimes context is relevant but wasn’t said explicitly.
- Verify the output format specification. Specify explicitly.
- Scrub for sensitive content. The prompt goes to a third-party AI service. Customer names, financial data, confidential strategy — handle per your team’s external-AI policy.
Paste into the downstream tool
The prompt is ready. Paste into Claude Code, Cursor, v0, Claude, Perplexity, Obsidian (or an Obsidian AI plugin), or whichever tool the prompt was shaped for.
The chain: tool/task matching
The workflow is a chain: meeting → meta-prompt → tool → artifact. Each link matters. The chain’s quality is limited by its weakest link. Match the tool to the task. Mismatches are common and costly:- Using a general assistant for code generation when Claude Code or Cursor would work much better
- Using a code-gen tool for analysis it isn’t suited for
- Using Perplexity for analysis of content you already have, when Notebook LM would work better
- Using Figma Make for a flow that v0 would handle better
- The task is simple enough that writing the prompt would take longer than doing the work
- The task requires judgment the AI tool can’t make
- You don’t have meeting source material relevant to the task
- The output requires verification more carefully than the task itself
Iteration and refinement
Prompts that work well are usually iterated, not first-drafted. The first draft tells you whether the prompt made sense to the downstream tool, whether the tool produced something useful, and what the prompt failed to specify clearly. Refinement patterns based on common first-output issues:- Output too generic → add more specific examples, more concrete acceptance criteria, more anti-patterns
- Output missed a constraint → make the constraint more prominent; sometimes restate at both start and end
- Output went in the wrong direction → tighten the goal statement; add “focus on X, not Y” clarification
- Output was confidently wrong → add “if you’re not sure, say so”; ask for citations or reasoning
- Output too long / too short → specify length more precisely; show an example
- Output used the wrong tone → add specific tone instructions; reference a positive example
Routing into systems of record
The workflow has its own version of systems of record — different from documentation-focused workflows but no less important. The prompt library. A maintained library of prompts that have worked well. Tools:- Obsidian — markdown vault with tags, wikilinks, and Dataview; strong for personal libraries and small teams syncing a shared vault
- Notion / Coda database — flexible; tag-rich; supports both personal and team libraries
- A dedicated prompts repo (Git) — for engineering teams; version-controlled; reviewable
- Specialized prompt management tools (PromptHub, Latitude, PromptLayer) — for teams managing many prompts at scale
- A simple Google Sheet or Airtable — sufficient for personal use
Closing the loop
Three habits. Evaluate output against meeting intent. When the downstream tool produces an artifact, ask: does this match what the source meeting actually intended? Sometimes the chain produces something plausible that drifts from the original conversation. If drifted, refine the prompt. If matched, ship. Learn from chain failures. When output is substantially worse than what you’d have produced manually, debug. Was the meeting source actually rich enough? Was the prompt template the right shape? Was the downstream tool the right tool? Was the curation pass thorough enough? Most chain failures are diagnosable; the diagnostic improves the workflow over time. Build the prompt library deliberately. Don’t let prompts ephemeralize. After every successful chain run, ask “is this prompt worth saving?” If yes, save with metadata. Over time, the library becomes a meaningful productivity asset.Common pitfalls
- Pasting the meeting transcript instead of generating a shaped prompt. Transcripts are too noisy and unstructured for most AI tools. The shaped prompt is the workflow’s whole point.
- Skipping the curation pass. The template produces a first-pass prompt; the curation makes it actually work with the target tool.
- Wrong tool for the task. Using Claude Code for analysis, Perplexity for code generation, or v0 for backend logic. Match tool to task.
- One-shot expectation. Treating the chain as “run once, get the answer.” Real use is iterative.
- Skipping the source link. Prompts without provenance can’t be traced back to the conversations that informed them. The traceability is what makes the workflow durable.
- Inventing context the meeting didn’t actually contain. Models can fill in plausible-sounding context that wasn’t discussed. The curation pass catches this.
- Confidential content in prompts to third-party AI. Customer names, financial data, sensitive strategy. Scrub before sending; follow your team’s external-AI policy.
- Building a prompt library no one uses. A library that isn’t searchable, tagged, or in a tool you open isn’t a library. Pick a tool you’ll actually use.
- Letting system prompts go stale. System prompts for persistent assistants need refresh as your work evolves. Update.
- Mixing what each AI tool is for. Using the same general approach for code-gen, analysis, and writing produces mediocre output. Each category has different prompt patterns; honor the differences.
- Treating the AI tool’s output as final. Always review. AI outputs are first drafts even when they look polished.
- Forgetting that AI tools improve. The prompt that worked well six months ago may underperform the simpler prompt that today’s tool can handle. Periodically revisit.
- Over-templating. Trying to capture every possible meeting type with a perfectly-shaped template creates overhead exceeding the benefit. Four templates cover most cases.
- Workflow fatigue. Trying to run every task through the chain when some tasks are faster to do manually. The workflow has a sweet spot — substantial tasks where meeting context exists. Use it there; not everywhere.
Where to go next
- Workflows — the general shape this is an instance of
- Meeting-to-prototype workflow — the focused version of this workflow for visual prototyping tools
- Meeting-to-tickets workflow — for the engineering tickets that follow from architecture decisions
- Meeting-to-PRD workflow — for product specs that motivate AI-tool work
- Architecture documentation workflow — for the technical documentation that often grounds engineering AI prompts
- Cursor integration — for coded implementation
- v0 integration — for UI components
- Codex integration — for engineering tasks
- Linear integration — for tickets that flow from AI-tool work
- Custom templates — visibility, sharing, and edit permissions
- Composer — for tuning the prompt before saving as a workspace template
- Before a meeting — pre-seeding the template on meetings expected to produce AI prompts
- Local transcripts — for export when you want to use the transcript with an external tool directly

