Skip to main content
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.

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: Earmark has direct integrations with Cursor, v0, Codex, and Linear (linked above). The rest are paste targets — Earmark generates the prompt; you paste into the tool. For each tool you use, know: what is it good at, what is it bad at, what does a good prompt for it look like?

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.
Two things in this template are load-bearing. “What NOT to do” is explicit. Code generation tools follow what you tell them. If you don’t tell them what to avoid, they sometimes do it. The anti-patterns section is the part most prompts skip and most need. Acceptance criteria are testable. “It should work” isn’t an acceptance criterion. “When a user clicks the button, the form submits and shows a success state without a page reload” is.

Template B — Analysis or research prompt

For Claude, ChatGPT, Perplexity, Notebook LM when used for analytical or research tasks.
The “what to leave out” and “what to do if you don’t have enough information” sections distinguish analysis prompts that produce useful output from those that produce confident-sounding noise. AI tools default to filling gaps with plausible content; explicit guidance about how to handle uncertainty produces more honest analysis.

Template C — Document generation prompt

For Claude, ChatGPT, or specialized writing tools used to draft long-form documents.
The “must NOT include” section matters as much as what to include — particularly for documents that touch on sensitive topics or that need to avoid drift into adjacent territory.

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.
System prompts are the most strategically valuable category. They establish persistent context that makes every future interaction more productive. Once configured well, they eliminate the need to re-explain context at the start of each conversation. Configure deliberately; revisit quarterly as your work evolves.

Save them as workspace templates

1

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.
2

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.
3

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

1

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.
2

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.
3

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.
4

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.
5

Evaluate the output and iterate

Does it match what you wanted? If yes, use the artifact. If no, refine the prompt (see iteration section below). Real use is iterative; expect two to four rounds for substantive outputs.
Treating the chain as one-shot — “ran it once, output wasn’t great, gave up” — is the most common failure mode. Treating it as iterative — “ran it three times with specific refinements between each” — is what produces results that outperform manual work.

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
Each tool has a sweet spot. The template choice is partly determined by this match. When to drop down to manual. Don’t force the workflow on tasks it doesn’t fit:
  • 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
The workflow’s value is on tasks where meeting context exists, the downstream tool is actually capable of the task, and shaping a good prompt is cheaper than doing the work manually.

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
The feedback prompt. After getting unsatisfying output, the natural next step is a feedback prompt — telling the tool what was wrong and asking for a refined version. “The component you generated has these issues: [specific issues]. Refine to address them while keeping [specific things that worked].” Faster than re-prompting from scratch because the tool already has context loaded. System prompt iteration is different. The system prompt governs many future conversations, not only one. After every conversation with the assistant, note: did it have the context it needed? Did it behave as you wanted? Periodically — weekly at first, then monthly — refine. When your work changes, update the system prompt to match. A well-tuned system prompt makes a Custom GPT or Claude Project feel like an assistant who’s been working with you for months.

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
Per prompt, capture: the prompt itself, the target tool, the use case, a quality note, related prompts, the source meeting context. The library compounds — after a year, 100–300 prompts make search and reuse high-leverage activities. The system prompt store. For persistent system prompts (Template D), the destination is the tool itself. But maintain a backup in a doc repo so the prompts you’ve invested in are portable when you migrate between tools. The artifact archive. Outputs from downstream tools go to their normal destinations — code into the codebase, analyses into project docs, long-form writing into Notion or Confluence, durable markdown into an Obsidian vault. Capture which prompts produced which artifacts. Tag the artifact with the prompt that generated it. When you want to “do something like that again,” you can find both. The source link. Every prompt should retain a link back to the source meeting in Earmark. The chain is: meeting → meta-prompt → tool output → artifact. Each step links backward; future you can trace any artifact back to the conversation that informed the prompt that produced it. Team prompt sharing. If you’re on a team running this workflow, sharing strong prompts is high-leverage. The pattern: personal prompt library for personal use; shared team library for prompts worth distributing; periodic review where strong personal prompts get nominated to the team library. The team equivalent of the demo-script library — but for AI prompts.

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