Noise2blog

Noise to Blog

Take any rough input (bullet points, voice transcripts, tweet dumps, or short drafts) and produce a polished, publication-ready blog post. Every claim traces to the source material or Tavily-verified research.

Critical rule: DO NOT INVENT SPECIFICS. Every claim, metric, and example in the blog post must come from the raw input or a Tavily search result. Never fabricate data, quotes, or outcomes.

Step 1: Setup Check

Confirm required env vars are set:

echo "GEMINI_API_KEY: ${GEMINI_API_KEY:+set}"
echo "TAVILY_API_KEY: ${TAVILY_API_KEY:-not set, Tavily enrichment will be skipped}"

If GEMINI_API_KEY is missing: Stop. Tell the user: "GEMINI_API_KEY is required. Get it at aistudio.google.com → Get API key. Add it to your .env file."

If TAVILY_API_KEY is missing: Continue. Note that Tavily enrichment will be skipped. The blog post will be based entirely on the provided content. This is fine for personal stories, tutorials from experience, or opinion pieces.

Confirm input is present. The user must provide one of:

• Pasted text (bullet points, rough notes, transcript, tweet dump, short draft)
• A URL to fetch

If no input, ask: "Share your rough notes, bullet points, or transcript. Paste them directly, or give me a URL to fetch the source."

Step 2: Read and Analyze Input

If input is a URL: Fetch the page content using WebFetch. Extract: title, author, publish date, all body text, key statistics, numbered lists, subheadings, quotes.

If input is pasted text: Read it directly. Identify the input type:

• Bullet points or rough notes: fragmented ideas, incomplete sentences, stream of consciousness
• Voice transcript: conversational, repetitive, filler words (um, uh, like, you know), meandering sentences
• Tweet thread dump: short fragments, @mentions, hashtags, "1/8" numbering
• Short draft: structured but thin, needs expansion and polish

QA checkpoint: State before continuing:

1. Input type detected
2. Core thesis or main argument in one sentence
3. The 3-5 strongest insights, facts, or ideas from the raw content
4. Any claims that need external verification (benchmarks, statistics, product comparisons, research findings)

If you cannot identify a core thesis, ask: "What's the single most important thing you want readers to take away from this?"

Step 3: Choose Blog Post Style

Four styles. Auto-detect from content signals. User override always respected.

Detection logic:

• Content has numbered steps or commands → Technical Tutorial
• Content has before/after, specific metrics, or narrative arc → Case Study
• Content argues against common wisdom or makes a strong opinion claim → Thought Leadership
• Content explains a concept, tool, or trend for people unfamiliar with it → Explainer

State chosen style and reasoning. If ambiguous, pick one and note the choice.

Step 4: Enrich with Tavily Research

Skip this step silently if TAVILY_API_KEY is not set.

Search for supporting evidence for claims in the raw content that could benefit from verification or data. Good candidates:

• Product benchmarks or performance numbers
• Market statistics or industry trends
• Technical comparisons ("X is faster than Y")
• Any number the user mentioned from memory rather than a cited source

Run one Tavily search per claim that needs verification. Limit to 3 searches maximum to avoid over-sourcing:

curl -s -X POST "https://api.tavily.com/search" \
  -H "Content-Type: application/json" \
  -d '{
    "api_key": "'"$TAVILY_API_KEY"'",
    "query": "SPECIFIC_CLAIM_OR_TOPIC",
    "search_depth": "advanced",
    "max_results": 5,
    "include_answer": true
  }'

Keep results with score >= 0.65. Extract: title, url, content snippet.

Rules for using Tavily results:

• Use them to support or verify claims already present in the raw input. Never introduce entirely new claims from search results.
• Attribute sources naturally in the text: "according to [Source]", "data from [X] shows"
• If no Tavily result confirms a claim, leave the claim unverified rather than substituting an unrelated result