noise2blog

Name: noise2blog
Author: Varnan-Tech

22installs59forks

How to install noise2blog?

varnan-tech/opendirectory/noise2blog

$npx -y skills add Varnan-Tech/opendirectory --skill noise2blog

Installs into the current project.

Summary

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 ar

Files · 1

View on GitHub

SKILL.md

1	# Noise to Blog
2
3	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.
4
5	---
6
7	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.
8
9	---
10
11	## Step 1: Setup Check
12
13	Confirm required env vars are set:
14
15	```bash
16	echo "GEMINI_API_KEY: ${GEMINI_API_KEY:+set}"
17	echo "TAVILY_API_KEY: ${TAVILY_API_KEY:-not set, Tavily enrichment will be skipped}"
18	```
19
20	If GEMINI_API_KEY is missing:
21	Stop. Tell the user: "GEMINI_API_KEY is required. Get it at aistudio.google.com → Get API key. Add it to your .env file."
22
23	If TAVILY_API_KEY is missing:
24	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.
25
26	Confirm input is present.
27	The user must provide one of:
28	- Pasted text (bullet points, rough notes, transcript, tweet dump, short draft)
29	- A URL to fetch
30
31	If no input, ask: "Share your rough notes, bullet points, or transcript. Paste them directly, or give me a URL to fetch the source."
32
33	---
34
35	## Step 2: Read and Analyze Input
36
37	If input is a URL:
38	Fetch the page content using WebFetch. Extract: title, author, publish date, all body text, key statistics, numbered lists, subheadings, quotes.
39
40	If input is pasted text:
41	Read it directly. Identify the input type:
42	- Bullet points or rough notes: fragmented ideas, incomplete sentences, stream of consciousness
43	- Voice transcript: conversational, repetitive, filler words (um, uh, like, you know), meandering sentences
44	- Tweet thread dump: short fragments, @mentions, hashtags, "1/8" numbering
45	- Short draft: structured but thin, needs expansion and polish
46
47	QA checkpoint: State before continuing:
48	1. Input type detected
49	2. Core thesis or main argument in one sentence
50	3. The 3-5 strongest insights, facts, or ideas from the raw content
51	4. Any claims that need external verification (benchmarks, statistics, product comparisons, research findings)
52
53	If you cannot identify a core thesis, ask: "What's the single most important thing you want readers to take away from this?"
54
55	---
56
57	## Step 3: Choose Blog Post Style
58
59	Four styles. Auto-detect from content signals. User override always respected.
60
61	\| Style \| When to use \| Signals \|
62	\|-------\|-------------\|---------\|
63	\| Technical Tutorial \| Step-by-step guide, how-to, code walkthrough \| Numbered steps, commands, code snippets, "how to" in content \|
64	\| Case Study \| Before/after story, build log, lessons learned \| Specific results, timelines, first-person journey \|
65	\| Thought Leadership \| Opinion, argument, counterintuitive claim \| "I think", "the problem with X", contrarian position, debate framing \|
66	\| Explainer \| What is X, why it matters, how it works \| Concept-first, comparison-heavy, "most people don't know" \|
67
68	Detection logic:
69	- Content has numbered steps or commands → Technical Tutorial
70	- Content has before/after, specific metrics, or narrative arc → Case Study
71	- Content argues against common wisdom or makes a strong opinion claim → Thought Leadership
72	- Content explains a concept, tool, or trend for people unfamiliar with it → Explainer
73
74	State chosen style and reasoning. If ambiguous, pick one and note the choice.
75
76	---
77
78	## Step 4: Enrich with Tavily Research
79
80	Skip this step silently if TAVILY_API_KEY is not set.
81
82	Search for supporting evidence for claims in the raw content that could benefit from verification or data. Good candidates:
83	- Product benchmarks or performance numbers
84	- Market statistics or industry trends
85	- Technical comparisons ("X is faster than Y")
86	- Any number the user mentioned from memory rather than a cited source
87
88	Run one Tavily search per claim that needs verification. Limit to 3 searches maximum to avoid over-sourcing:
89
90	```bash
91	curl -s -X POST "https://api.tavily.com/search" \
92	-H "Content-Type: application/json" \
93	-d '{
94	"api_key": "'"$TAVILY_API_KEY"'",
95	"query": "SPECIFIC_CLAIM_OR_TOPIC",
96	"search_depth": "advanced",
97	"m

People who liked this also viewed

6 picks

Type

noise2blog

22installs59forks

View on GitHub

How to install noise2blog?

varnan-tech/opendirectory/noise2blog

$npx -y skills add Varnan-Tech/opendirectory --skill noise2blog

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Noise to Blog
2
3	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.
4
5	---
6
7	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.
8
9	---
10
11	## Step 1: Setup Check
12
13	Confirm required env vars are set:
14
15	```bash
16	echo "GEMINI_API_KEY: ${GEMINI_API_KEY:+set}"
17	echo "TAVILY_API_KEY: ${TAVILY_API_KEY:-not set, Tavily enrichment will be skipped}"
18	```
19
20	If GEMINI_API_KEY is missing:
21	Stop. Tell the user: "GEMINI_API_KEY is required. Get it at aistudio.google.com → Get API key. Add it to your .env file."
22
23	If TAVILY_API_KEY is missing:
24	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.
25
26	Confirm input is present.
27	The user must provide one of:
28	- Pasted text (bullet points, rough notes, transcript, tweet dump, short draft)
29	- A URL to fetch
30
31	If no input, ask: "Share your rough notes, bullet points, or transcript. Paste them directly, or give me a URL to fetch the source."
32
33	---
34
35	## Step 2: Read and Analyze Input
36
37	If input is a URL:
38	Fetch the page content using WebFetch. Extract: title, author, publish date, all body text, key statistics, numbered lists, subheadings, quotes.
39
40	If input is pasted text:
41	Read it directly. Identify the input type:
42	- Bullet points or rough notes: fragmented ideas, incomplete sentences, stream of consciousness
43	- Voice transcript: conversational, repetitive, filler words (um, uh, like, you know), meandering sentences
44	- Tweet thread dump: short fragments, @mentions, hashtags, "1/8" numbering
45	- Short draft: structured but thin, needs expansion and polish
46
47	QA checkpoint: State before continuing:
48	1. Input type detected
49	2. Core thesis or main argument in one sentence
50	3. The 3-5 strongest insights, facts, or ideas from the raw content
51	4. Any claims that need external verification (benchmarks, statistics, product comparisons, research findings)
52
53	If you cannot identify a core thesis, ask: "What's the single most important thing you want readers to take away from this?"
54
55	---
56
57	## Step 3: Choose Blog Post Style
58
59	Four styles. Auto-detect from content signals. User override always respected.
60
61	\| Style \| When to use \| Signals \|
62	\|-------\|-------------\|---------\|
63	\| Technical Tutorial \| Step-by-step guide, how-to, code walkthrough \| Numbered steps, commands, code snippets, "how to" in content \|
64	\| Case Study \| Before/after story, build log, lessons learned \| Specific results, timelines, first-person journey \|
65	\| Thought Leadership \| Opinion, argument, counterintuitive claim \| "I think", "the problem with X", contrarian position, debate framing \|
66	\| Explainer \| What is X, why it matters, how it works \| Concept-first, comparison-heavy, "most people don't know" \|
67
68	Detection logic:
69	- Content has numbered steps or commands → Technical Tutorial
70	- Content has before/after, specific metrics, or narrative arc → Case Study
71	- Content argues against common wisdom or makes a strong opinion claim → Thought Leadership
72	- Content explains a concept, tool, or trend for people unfamiliar with it → Explainer
73
74	State chosen style and reasoning. If ambiguous, pick one and note the choice.
75
76	---
77
78	## Step 4: Enrich with Tavily Research
79
80	Skip this step silently if TAVILY_API_KEY is not set.
81
82	Search for supporting evidence for claims in the raw content that could benefit from verification or data. Good candidates:
83	- Product benchmarks or performance numbers
84	- Market statistics or industry trends
85	- Technical comparisons ("X is faster than Y")
86	- Any number the user mentioned from memory rather than a cited source
87
88	Run one Tavily search per claim that needs verification. Limit to 3 searches maximum to avoid over-sourcing:
89
90	```bash
91	curl -s -X POST "https://api.tavily.com/search" \
92	-H "Content-Type: application/json" \
93	-d '{
94	"api_key": "'"$TAVILY_API_KEY"'",
95	"query": "SPECIFIC_CLAIM_OR_TOPIC",
96	"search_depth": "advanced",
97	"m

People who liked this also viewed

6 picks

Type