DEV Community: J Now

The OSS tool you built deserves more than one post

J Now — Tue, 07 Jul 2026 12:46:56 +0000

You posted your tool on launch day, got a handful of upvotes, and that was it. Not because the tool was bad — because consistent distribution requires showing up weekly across Bluesky, Mastodon, X, Dev.to, and Hashnode, remembering which angle you covered last, respecting per-channel character limits (280 on X, 300 on Bluesky, 150–400 words on Dev.to), and writing copy that doesn't read like a press release. Almost nobody does that work. The tool quietly dies.

I built marketing-pipeline to handle the recurring part. You onboard a project once:

marketing onboard --name my-tool --repo owner/repo --kind mcp-server

That fetches your README, sends it to Claude, and writes problem, facts, and angles into projects.yml. From there, a daily GitHub Actions cron at 14:00 UTC cycles through projects × angles × channels, picks the least-recently-used angle per project, formats the post to the channel's constraints, and publishes.

The part I spent the most time on was preventing the output from reading like marketing copy. pipeline/antislop.py hard-rejects specific tokens before anything gets published: excited, game-changer, unlock, empower, AI-powered, emoji, hashtags, exclamation points, and rhetorical questions. If a draft contains any of them, the post is blocked and regenerated. The constraint is aggressive on purpose — most automated content fails because nobody built a gate that actually rejects the slop.

Cross-posting also handles directory listings. The kind field routes submissions to type-specific registries: mcp-server goes to MCP Registry, Smithery, Glama, and PulseMCP; claude-skill generates a payload for awesome-claude-code (human submission required — their rules); browser-extension targets Chrome Web Store, Firefox AMO, and Edge Add-ons.

You need an Anthropic API key and credentials for at least Bluesky, Dev.to, and Hashnode. Mastodon and Slack are optional.

https://github.com/robertnowell/marketing-pipeline

Nobody ever measured whether short blog posts perform better

J Now — Tue, 07 Jul 2026 11:01:39 +0000

Every content guide cites "80% of readers quit after 350 words." That stat traces to a single founder interview describing internal data — no dataset, no methodology, no third-party verification.

If you've been cutting posts to hit a word count, you've been optimizing for folklore.

This matters if you write to build an audience: you have no actual evidence that shorter is better, only a widely repeated assertion from people who also never measured it. Seth Godin, who has published a blog nearly daily for decades: "I don't keep track… I don't know how many people read my blog." 37signals/Basecamp cites brevity as a value, not an outcome. Axios's Smart Brevity framework is real and structured — but the engagement number attached to it is unverified.

The one format with a documented standard for what earns inclusion: Simon Willison, who has published 7,607 link posts since 2003, requires every entry to credit the creator by name, explain why it's worth reading, quote liberally, and "add something extra" so the reader gains value without clicking through. His weekly digest has one hard filter — external links are excluded if they carry no author-written annotation. Raw links don't get in. The gate is annotation quality, not word count.

Separately, the only rigorous taxonomy of what humans actually judge as low-quality writing (arXiv 2509.19163, built from 19 expert interviews) found that "verbose text conveying minimal content" was the strongest consistent signal across all annotators — and that automated tools are weak at detecting it.

The implication: density matters, but the brevity gospel has no data behind it. Write as long as the idea requires. Cut what's empty, not what's long.

Sources: Axios Smart Brevity framework [Tier 1]; Simon Willison link-blog practice [Tier 1]; arXiv 2509.19163 slop taxonomy [Tier 1]; Godin quote [Tier 3, direct].

Months of Claude Code sessions, no idea if I was improving

J Now — Mon, 06 Jul 2026 18:36:58 +0000

I've been using Claude Code daily for months. Fast, yes. But I started noticing I had the same three moves: ask a question, paste in an error, ask for a refactor. I had no idea whether I was actually developing any depth or just getting faster at a narrow groove.

Anthropic published a study in February 2026 (9,830 Claude conversations, 11 observable collaboration behaviors) that gave me a concrete baseline to check myself against. I built skill-tree to run that same classification on my own session history.

Here's what it does:

claude plugin marketplace add robertnowell/ai-fluency-skill-cards
claude plugin install skill-tree-ai@ai-fluency-skill-cards

The 7-step orchestration takes 30–60 seconds: it finds your local session files, extracts user messages, ships them to a remote Claude Haiku classifier on Fly.io, maps results against the 11 behaviors from the AI Fluency Index, assigns one of seven archetype cards, writes a narrative, renders a visualization, and returns a stable URL. The archetype cards are rendered as tarot cards using curated museum art — see a live example at skill-tree-ai.fly.dev/fixture/illuminator.

The part I built for myself specifically: a growth quest. After classification, it identifies which of the 11 behaviors are absent or underrepresented in your sessions and surfaces one as a concrete thing to try in your next session. That quest persists across sessions via a SessionStart hook (~/.skill-tree/ in Claude Code).

The behavior taxonomy comes from Dakan & Feller's 4D AI Fluency Framework — three axes are observable in chat logs (Description, Discernment, Delegation); the fourth (Diligence) isn't captured from logs alone.

Also available as an MCP server (npm package skill-tree-ai) for Cursor, VS Code, and Windsurf if you're not on Claude Code.

https://github.com/robertnowell/ai-fluency-skill-cards

Klein blue is invisible as text — here's how I worked around it

J Now — Mon, 06 Jul 2026 17:00:34 +0000

I use Claude Code for hours every day, and most of what I read is prose — tool output, reasoning traces, permission prompts. Terminal themes are built for syntax highlighting: dark backgrounds with fine-tuned keyword colors. That's the wrong optimization when your screen is 80% English paragraphs.

I wanted a theme tuned for body-size prose legibility over long sessions, anchored to a single color I actually cared about: Yves Klein's IKB, the ultramarine pigment he mixed himself and patented in 1960. Pure IKB is hex 002FA7.

First thing I found: pure IKB fails as text on a dark background. APCA Lc score of -12 — effectively invisible. You can use it as decoration, borders, highlights. You cannot use it as readable text.

Claude Code maps its permission-prompt text to the terminal's ansi:blue slot. If I dropped IKB into ansi:blue, the prompts would disappear. So I split the role across two slots:

ansi:blue       = 002FA7   // pure IKB — decorative borders, structural chrome
ansi:blueBright = A8BEF0   // lifted Klein-family blue — permission-prompt body text

The bright slot carries the readable text. The base slot carries the pigment. Neither lies about what it is — one is the color as an object, one is the color as legible language.

The theme ships in four variations. Klein Void Prot is the one where every color role passes strict APCA gates: body text >= Lc 90, subtle >= 75, muted >= 45, accents >= 60. The others trade some strictness for warmth or brand character — Klein Void Sand & Sea accepts Claude's ansi:redBright sand color as a second hero instead of neutralizing it.

One implementation detail worth noting: none of this works unless you set Claude Code's /theme picker to dark-ansi. Claude Code ships with a hardcoded RGB palette and will ignore your terminal's ANSI colors entirely unless you explicitly switch it off.

Built as macOS Terminal.app .terminal profile files. Includes install.sh and restore.sh — fully rollback-able. CommitMono-Regular on the Prot variation, IBM Plex Mono on Gallery.

https://github.com/robertnowell/klein-void

I wanted Wikipedia on every page — so I built it

J Now — Mon, 06 Jul 2026 15:02:54 +0000

Every article I read has words I half-know. Terms I skipped past in undergrad, concepts that would open up the whole paragraph if I just knew what they meant. Opening a new tab to look them up works once. By the third detour I've lost the thread of what I was reading entirely.

So I built rabbitholes — a Chrome extension that turns any highlighted text into an inline explanation next to your cursor, without leaving the page.

The tooltip renders in a shadow DOM, so it doesn't touch the host page's styles or layout. Explanations come from Claude Haiku 4.5 directly — requests go from your browser straight to api.anthropic.com, no intermediary server, zero telemetry.

The part I use most: every explanation ends with two suggested rabbit-hole topics. Click one and you're one hop deeper. The extension tracks how many hops you've taken — hit 'philosophy' and you get a shareable trail of where you went.

There are a few other entry points worth knowing:

Click any word in the explanation to explore it further, or drag across words to pick a phrase
Pencil icon opens a free-form follow-up that inherits the current context as background
Globe icon re-runs the query enriched with Brave Search results, with source chips you can click through

The API key lives in chrome.storage.sync (encrypted, never leaves the browser). Manifest V3.

// Nothing installs on the server side.
// You supply your own Anthropic API key.
// Requests: browser → api.anthropic.com
// That's the whole data path.

The thing that surprised me building this: the rabbit-hole counter makes you want to go deeper rather than feel guilty about it. It reframes the tangent as the point.

https://github.com/robertnowell/rabbitholes

When one translation isn't enough: building konid for real language use

J Now — Mon, 06 Jul 2026 13:12:22 +0000

I wanted to tell my girlfriend 'I missed you today' in Farsi — her first language. Google Translate gave me one answer, no context, no sense of whether it sounded tender or clinical or weird. I had no way to know if it would land the way I meant it.

That's the gap konid fills. For any phrase you want to say, it returns three options ordered casual to formal, with the register explained and cultural context on what separates them. Audio pronunciation plays directly through your speakers — no API key, no copying text into a separate tab — using node-edge-tts under the hood.

The example that made me build this: 'I missed you today' in Farsi has options that range from something you'd text a close friend to something that reads more poetic and deliberate. A single literal translation gives you none of that. Knowing which to pick — and why — is the actual thing you need.

Konid works as an MCP server, so it runs inside Claude Code, Cursor, VS Code Copilot, Windsurf, Zed, JetBrains, and Claude Cowork. Install in Claude Code with:

claude mcp add konid-ai -- npx -y konid-ai

It also works as a ChatGPT app via Developer mode using the endpoint https://konid.fly.dev/mcp.

The tool supports 13+ languages: Mandarin, Japanese, Korean, Spanish, French, German, Portuguese, Italian, Russian, Arabic, Hindi, and more. MIT licensed.

I named it after the Farsi word كنيد — 'do,' as in take action.

https://github.com/robertnowell/konid-language-learning

Why your email designs fail silently (and a scorer that catches it first)

J Now — Mon, 06 Jul 2026 11:31:40 +0000

Every email tool I've used hands you a blank canvas, a template library, and silence. You build the campaign, it looks fine on your 27-inch monitor, you send it, and the open rate is fine but the click rate is not. You never find out why.

The problem isn't the blank canvas. It's that there's no feedback loop between design choices and measurable quality — until the campaign is already out.

I built kopi to close that loop before send. Every email gets an automated design critique that scores layout hierarchy, mobile readability, CTA contrast, and 12 other criteria on a 0–100 scale. The score isn't decoration: a 93/100 email typically has a single dominant CTA with surrounding whitespace, a font-size stack that scales to 375px without horizontal scroll, and a contrast ratio on the primary button that clears WCAG AA. A 70/100 email usually has two competing CTAs, body text that wraps awkwardly on mobile, or a hero image that pushes the first button below the fold on phone screens.

You can see the distribution yourself — the public gallery at trykopi.ai/emails shows 400+ emails that scored 80 or above.

Generation side: you write a prompt describing the campaign (product, offer, tone, audience), and kopi returns a complete HTML email in under 5 minutes. It can learn your brand's fonts, colors, and layout preferences so you're not resetting defaults every session. Direct export to Klaviyo, and it runs as an MCP server if you're working in Claude Code, Cursor, or ChatGPT.

The part I found most useful building this: the scoring surfaces decisions you didn't realize you made. You dragged a button to the bottom of a long section because it felt natural — the scorer tells you the CTA contrast is 3.2:1 and mobile users are scrolling past it. That's the feedback loop that was missing.

https://trykopi.ai

I built a skill-tree for Claude Code because I couldn't tell if I was improving

J Now — Thu, 02 Jul 2026 18:30:23 +0000

I've used Claude Code daily for months. At some point I noticed I was faster — but faster at the same handful of moves: ask, review, iterate. I had no idea if I was actually developing fluency or just automating my existing habits.

In February 2026, Anthropic published a study of 9,830 Claude conversations measuring 11 observable collaboration behaviors. I wanted to know what mine looked like against that baseline, and more importantly, which behaviors I never touch.

skill-tree analyzes your Claude Code session history, classifies those same 11 behaviors using the Dakan & Feller 4D AI Fluency Framework (three axes are visible in chat logs: Description, Discernment, Delegation — Diligence isn't), assigns one of seven archetype cards, and picks a growth quest for your next session.

The archetype cards are rendered as tarot cards with curated museum art. You can see a live example at skill-tree-ai.fly.dev/fixture/illuminator.

The 7-step orchestration — find session files, extract user messages, remote classifier (Claude Haiku on Fly.io), archetype assignment, narrative synthesis, render, return URL — takes about 30–60 seconds end-to-end.

The interesting design constraint

The growth quest needs to persist across sessions so Claude Code picks it up at the start of your next chat via a SessionStart hook. In Claude Code that's straightforward: write to ~/.skill-tree/ and the path is stable.

Cowork was the problem. Cowork's $HOME is ephemeral — it resets between sessions. A state file written to ~/ just disappears. The fix was a dual-state-path design: Claude Code uses ~/.skill-tree/, Cowork uses $CLAUDE_PLUGIN_ROOT/.user-state/ which is durable because it lives inside the plugin root rather than the user home.

This meant every read and write in the orchestration had to resolve the right base path at runtime depending on which host it was running in. Not complicated, but worth knowing if you're building anything stateful for Cowork.

# Claude Code install
claude plugin marketplace add robertnowell/ai-fluency-skill-cards
claude plugin install skill-tree-ai@ai-fluency-skill-cards

# Cowork: upload skill-tree-ai.zip via plugin manager

# Also available as MCP server for Cursor, VS Code, Windsurf
npm install skill-tree-ai

Repo and full install docs: https://github.com/robertnowell/ai-fluency-skill-cards

"# APCA per-role contrast gates and why WCAG lies on dark terminals\n\

J Now — Thu, 02 Jul 2026 16:35:24 +0000

"# APCA per-role contrast gates and why WCAG lies on dark terminals\n\nReading paragraphs of tool output for hours through a syntax-highlighting theme is the wrong pairing. Syntax themes optimize for token-level scanning; prose at body size needs different contrast targets. I kept noticing eye strain before I named the problem.\n\nI built four Terminal.app themes (klein-blue) around Yves Klein's IKB pigment, verified with APCA contrast gates per text role rather than a single WCAG ratio.\n\n## The asymmetry WCAG misses\n\nWCAG 2.1's contrast ratio is symmetric — same math for dark-on-light and light-on-dark. APCA is asymmetric because perception is. The same luminance delta reads differently depending on polarity, and terminal themes are always light text on dark ground.\n\nIKB on dark ground is the concrete case. The pigment's hex value produces APCA Lc -12 against near-black: effectively invisible. Some WCAG configurations pass this. APCA fails it, correctly.\n\nThe design fix: split blue across two ANSI slots by function, not aesthetics.\n\n

\nansi:blue pure IKB (Lc -12) # decorative only — Claude Code uses this for borders\nansi:blueBright A8BEF0 (passes Lc 60) # Claude Code uses this for permission-prompt text\n

\n\nBorders don't need to be read. Prompts do. Keeping the split means IKB stays unmixed where it's display-only, lifted only where it carries information.\n\n## Gate structure across four variations\n\n

\nbody >= Lc 90\nsubtle >= Lc 75\nmuted >= Lc 45\naccent >= Lc 60\n

\n\nKlein Void Prot (V3) passes all gates strictly. Klein Void Gallery trades some accent slots for maximum visual void. Klein Void Sand & Sea accepts the ansi:redBright brand color as a second hero; Klein Void Refined neutralizes it to keep a single-color interface.\n\nInstalls via bash install.sh to macOS Terminal.app, fully reversible via bash restore.sh. Requires the /theme picker set to dark-ansi — otherwise the ANSI palette is bypassed entirely.\n\nhttps://github.com/robertnowell/klein-void",

No server in the middle: how rabbitholes handles your API keys

J Now — Thu, 02 Jul 2026 14:45:03 +0000

Most Chrome extensions that call external APIs route requests through the developer's backend. You're asking users to trust that their queries — what they're reading, what they don't understand — don't get logged or sold. That's a promise made in a privacy policy, not enforced by architecture.

I built rabbitholes to highlight any text and get an inline explanation without opening a new tab. The usage pattern is ambient: you're mid-article, you highlight a phrase you half-know, an explanation pops up next to your cursor in a shadow-DOM tooltip. Then you click a word in the explanation to go deeper, or hit the rabbit-hole counter to see how many hops you've taken. That pattern produces a granular record of what you read and what confused you. I didn't want that record to exist on my end.

So the architecture skips the intermediary entirely. Requests go directly from your browser to api.anthropic.com (for explanations via Claude Haiku 4.5) and api.search.brave.com (for the globe-icon web-enriched mode, which appends Brave Search results and source chips). Your API keys live in chrome.storage.sync — Chrome encrypts them and syncs them to your account; they never hit a server I control because there is no server I control.

// Full outbound call — no proxy layer
const res = await fetch('https://api.anthropic.com/v1/messages', {
  method: 'POST',
  headers: {
    'x-api-key': userKey,  // retrieved from chrome.storage.sync
    'anthropic-version': '2023-06-01',
    'content-type': 'application/json',
  },
  body: JSON.stringify(payload),
});

Manifest V3 host_permissions are scoped to exactly those two domains. No analytics SDK, no Sentry, no telemetry pipeline. Zero.

The cost of this design: you need your own API keys. For personal reading use, Claude Haiku 4.5 runs cheap enough that it's a rounding error. Brave Search has a free tier that covers light use.

The benefit: your reading habits stay yours. What you looked up, what confused you, how far down a rabbit hole you went — none of that transits my infrastructure, because there isn't any.

https://github.com/robertnowell/rabbitholes

When one translation isn't enough: building a language coach as an MCP server

J Now — Thu, 02 Jul 2026 12:37:51 +0000

I wanted to tell my girlfriend 'I missed you today' in Farsi and have it land naturally, not like I'd copy-pasted it from Google Translate. Every tool I tried gave me one answer, no register, no sense of whether it was formal or intimate or accidentally weird. For a language you're still learning, that single flat translation teaches you nothing — it just gets you through the moment.

So I built konid: a language coach that returns three options for anything you want to say, ordered casual to formal, each one with the register explained and the nuances between them compared. It also plays audio pronunciation directly through your speakers using node-edge-tts, no external API key needed.

The interesting design constraint was the MCP server architecture. I wanted the same tool available everywhere I'm already working — not a separate app to switch to. One install, four clients:

claude mcp add konid-ai -- npx -y konid-ai

That gets you konid inside Claude Code and Claude Cowork. The same server runs in Cursor, VS Code Copilot, Windsurf, Zed, and JetBrains via their respective MCP config blocks. For ChatGPT, it also works as a Developer mode app pointing at https://konid.fly.dev/mcp — same logic, no extra code.

The write-once-run-anywhere part matters because context switching is what kills language learning in a workflow. If I'm translating a work email in Cursor and want to know whether 'I look forward to hearing from you' should be formal or whether there's a warmer register that's still professional in Japanese, I want the answer inline, not in another tab.

A query against konid in any of those clients returns three ranked options with the cultural context and register difference explained. For 'I missed you today' in Farsi, those three options are genuinely different sentences — not rewording of the same translation — because the intimate/casual/formal split in Farsi operates at the verb level, not just politeness particles.

konid supports 13+ languages including Mandarin, Japanese, Korean, Spanish, French, German, Portuguese, Italian, Russian, Arabic, and Hindi.

MIT licensed.

https://github.com/robertnowell/konid-language-learning

When you post once and get silence, distribution is the bug

J Now — Thu, 02 Jul 2026 10:53:57 +0000

The first time I shipped an open source tool, I wrote a good README, posted to Hacker News, got three upvotes, and concluded the project wasn't useful. It was useful. I just never showed up again.

Distribution for OSS isn't a one-day task. It's submitting to directories, writing posts across four platforms, rotating angles so you're not repeating yourself, and doing all of that every week without burning out on it. Most people don't have the time or the inclination, so the project dies.

I built marketing-pipeline to run that recurring work without daily intervention. One command onboards a project:

marketing onboard --name my-tool --repo owner/repo --kind mcp-server

That fetches the README, sends it to Claude, and writes problem statements, factual claims, and rotation angles to projects.yml. From there, a GitHub Actions cron at 14:00 UTC on weekdays picks the least-recently-used angle per project, drafts posts for Bluesky, Mastodon, X, Dev.to, and Hashnode, enforces per-channel length limits (Bluesky 300 chars, X 280, Dev.to 150-400 words), and publishes.

The part I want to highlight here is the anti-slop gate in pipeline/antislop.py.

LLM-drafted marketing copy has a fingerprint: "excited to share," "game-changer," "unlock," "empower," "AI-powered," rhetorical questions, emoji, hashtags, exclamation points. These tokens don't just read badly — they signal that nobody with actual opinions wrote this. The antislop gate hard-rejects any draft containing them before it ever reaches a publish step. This is a regex blacklist, not a prompt instruction. Prompting Claude to "sound natural" doesn't hold over time; a regex gate does.

Directory submission is also automated by project kind: mcp-server routes to MCP Registry, Smithery, Glama, and PulseMCP; claude-skill to awesome-claude-code (payload generated, but their rules require a human to submit via GitHub issue — that one step can't be scripted out); browser-extension to Chrome Web Store, Firefox AMO, and Edge Add-ons.

https://github.com/robertnowell/marketing-pipeline