/noise2blog

name: noise2blog
description: Turns rough notes, bullet points, voice transcripts, or tweet dumps into a polished, publication-ready blog post. Optionally enriches with Tavily research to add supporting data and credibility to claims. Use when asked to write a blog post from notes, turn rough ideas into an article, expand bullet points into a full post, clean up a voice transcript into a blog, or repurpose a tweet thread as an article. Trigger when a user says "write a blog post from this", "turn these notes into a post", "expand this into an article", "make this publishable", "I have rough notes write a blog", or "clean up this transcript".
compatibility: [claude-code, gemini-cli, github-copilot]
author: OpenDirectory
version: 1.0.0

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.

| Style | When to use | Signals | |-------|-------------|---------| | Technical Tutorial | Step-by-step guide, how-to, code walkthrough | Numbered steps, commands, code snippets, "how to" in content | | Case Study | Before/after story, build log, lessons learned | Specific results, timelines, first-person journey | | Thought Leadership | Opinion, argument, counterintuitive claim | "I think", "the problem with X", contrarian position, debate framing | | Explainer | What is X, why it matters, how it works | Concept-first, comparison-heavy, "most people don't know" |

**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

---

Step 5: Generate the Blog Post

Read `references/blog-format.md` in full. Select the matching template from `references/output-template.md`. Internalize all rules before generating.

Write the Gemini request to a temp file to handle special characters safely:

cat > /tmp/noise2blog-request.json << 'ENDJSON'
{
  "system_instruction": {
    "parts": [{
      "text": "You are a tech writer who sounds like a real person. Rules: Active voice only. Short paragraphs, 1-3 lines max, then a b