DEV Community: Jim L

Claude Code Skills: The Custom Workflow Layer Most Developers Skip

Jim L — Mon, 04 May 2026 12:14:54 +0000

I've been using Claude Code full-time for about four months now. The default setup — install, run claude in your project directory, give it tasks — works well. But the part that actually changed how I use it is the skills system, and I've talked to maybe eight or nine developers who use Claude Code regularly without knowing it exists.

Quick version: Claude Code skills are reusable prompt modules that live as Markdown files in .claude/skills/. You invoke them via the Skill tool, and they load structured context into the conversation. Think of them as stored SOPs for recurring workflows — not macros, not plugins, but something more like documented ways of working that the agent reads and follows.

What skills actually do

A skill file is a Markdown document with a YAML frontmatter block (name, description) and then the actual instructions. When the Skill tool loads it, that content becomes part of the agent's working context for that task.

The practical effect: instead of re-explaining your debugging process every session, you write it once, give it a name, and invoke it when needed. The agent reads the full document — including specific steps, anti-patterns to avoid, verification criteria — and applies it to whatever it's working on.

I have skills set up for: code review (with project-specific conventions), database migration safety checks, SEO content publishing workflows, and a debugging sequence I adapted from scientific method principles. None of these are doing anything fancy — they're just structured instructions that would otherwise take three minutes of re-typing per session.

Skills vs plugins

This is the confusion I see most often. Claude Code plugins (more precisely: MCP servers that Claude Code connects to) expose external tools — databases, APIs, file systems, search engines. The AI can call these tools to get information or trigger actions.

Skills are different. They don't add tools. They add structured behavior patterns — sequences of reasoning, checklists, specific terminology the project uses, formats for output. A plugin gives Claude Code access to your Postgres database. A skill tells Claude Code how you want it to handle migrations specifically: what pre-checks to run, what to verify before committing, how to structure the migration file.

You'd use both: plugin to access the database, skill to apply your migration SOP.

The gap I keep seeing

Most developers discover Claude Code as a terminal-based Cursor alternative and use it that way: give it a task, review the output, iterate. That's a completely legitimate workflow.

The skills system becomes relevant when you start noticing that you're giving the same context repeatedly. "When you're doing X, always do Y first. Check for Z. Don't do W." If you're saying that more than a couple of times, it probably belongs in a skill.

The friction point is that writing a good skill takes 20-30 minutes, which is hard to justify in the moment. The payoff shows up over repeated sessions — which means developers who only use Claude Code occasionally don't hit the friction point and never develop the habit.

How I structure mine

I keep skill files simple: name, one-paragraph description (this matters for the description frontmatter — it's how the agent decides whether a skill is relevant), then the actual instructions in plain Markdown.

One pattern I've found useful: write the skill by capturing what I'd actually say if I were onboarding someone to this workflow. Not what I think they should know theoretically, but what I'd tell them in the first five minutes. That framing tends to produce skills that are actually useful rather than skills that look thorough but miss the practical edge cases.

What doesn't work well

Skills are not good for:

Context that changes frequently (use project documentation for that, not skills)
Highly technical domain knowledge (the agent already has this; a skill adds structure, not facts)
Tasks you only do once (the setup cost isn't worth it)

They're also not versioned by default, which creates drift over time. I do a quarterly review — checking each skill against the workflows I actually ran in the last three months and updating anything that's become stale.

The workflow skills I'd build first

If you're starting from scratch: debugging flow first (what steps to go through before escalating, what information to gather, what to check first), then code review conventions (project-specific patterns, what to flag, what to ignore), then any publishing or deployment SOP you repeat.

The skills that pay off fastest are the ones where you'd otherwise spend five minutes in the first message explaining how you want things done. Every time you save that five minutes is compounding — and the agent follows the skill more consistently than it would follow a re-typed explanation, which tends to be less precise than what you wrote when you had time to think it through.

I wrote a longer breakdown of how I use the skills system day-to-day, including the specific skill files I've built and how they interact with Claude Code's MCP setup, but that's a longer post for another day. The short version: if you're a regular Claude Code user and haven't looked at the skills system, it's worth 30 minutes of your time.

Why I Track NVDA and AVGO as an AI Infrastructure Pair (HK/TW Investor Perspective)

Jim L — Mon, 04 May 2026 00:30:44 +0000

When I first started tracking US stocks from Hong Kong, I made the mistake of treating NVDA and AVGO separately. NVDA for AI exposure, AVGO as a dividend holding. Separate mental buckets.

That framing was wrong, and it cost me a few months of clarity.

The duopoly case

NVDA designs the GPUs that train and run large language models. AVGO makes the custom ASICs (Google TPU chips, Meta's MTIA chips) and the high-speed interconnects that link those chips together at scale. They're not competing -- they're working on different layers of the same infrastructure stack.

When a hyperscaler spends $50 billion building out AI compute in a year, both companies benefit. NVDA gets GPU orders. AVGO gets ASIC orders plus the networking hardware to connect everything. The revenue exposure is correlated, but the mechanisms are different enough that holding both gives you different risk profiles inside the same theme.

Four numbers, two for each

NVDA: Price-to-sales around 20x forward. The valuation assumes datacenter GPU demand continues at the 2024-2025 pace, which is the main risk. If hyperscaler capex slows, that multiple compresses fast.

AVGO: Forward P/E around 26x, with a dividend growing at roughly 15% annually. The dividend creates a floor psychology -- income-focused investors hold even in volatility, which damps drawdowns compared to NVDA.

Neither is cheap by traditional metrics. The question is whether AI infrastructure spending is durable, and over what timeframe.

Allocation math for HK/TW investors

For HK investors buying US stocks via a local broker: NVDA and AVGO are both accessible through Interactive Brokers HK, Futu Securities, and Tiger Brokers. The dividend withholding math differs between them.

NVDA pays about $0.04/share quarterly -- tiny relative to share price. Withholding on that is almost noise.

AVGO pays about $23.50/share annually (as of 2025). The 30% US withholding tax on dividends -- standard for HK residents without a W-8BEN or equivalent -- takes a meaningful bite. On a $10,000 AVGO position, roughly $35/year after withholding versus $50 pre-withholding. That changes the income math if you're holding for yield.

My current allocation: roughly 60% NVDA, 40% AVGO within this pair. Higher NVDA weight for upside optionality if AI compute demand continues scaling. AVGO for the income component and partial volatility damper.

What could actually break this pair

The bear case isn't "AI doesn't work" -- it's "customers build their own chips." Google already makes TPUs and buys AVGO ASICs. If Google internalizes more ASIC work, AVGO's custom silicon revenue narrows. If AMD closes the performance gap with H100/H200/B100, NVDA faces market share pressure.

The scenario where both underperform simultaneously: hyperscaler capex rotation -- they've spent heavily and are now in a digestion phase. This happened briefly in 2023. It could happen again.

What doesn't break it

"Nvidia is overvalued so both will fall" -- AVGO has a different multiple and a dividend. They don't always move together. AVGO's drawdowns in the last two years have been meaningfully smaller.

"AVGO is a legacy semiconductor company" -- AVGO's networking business (Ethernet switching, optical interconnects) is more relevant to AI infrastructure than it was five years ago. The custom ASIC revenue is growing, not declining.

I'm not recommending either position. This is how I think about the pair for my own portfolio, as someone managing investments in HK and tracking AI infrastructure themes. Your tax situation, broker access, and risk tolerance will differ.

The core point: treating NVDA and AVGO as a coordinated pair rather than separate decisions changes how you think about entry points, volatility, and income -- especially with the withholding tax asymmetry that matters specifically for HK/TW investors.

Cohere just open-sourced a 5.42 WER speech model - here's what testing it on real audio showed

Jim L — Wed, 29 Apr 2026 07:12:31 +0000

Cohere released their new ASR model on March 26 with a 5.42% Word Error Rate on the LibriSpeech test-clean benchmark. That's a noticeable improvement over Whisper-large-v3 (~5.7%), and given it's open-source under a permissive license, I spent the last two weeks running it through real-world audio to see if the benchmark numbers translate.

The short answer: yes for clean studio audio, partially for noisy real-world recordings, and not yet for code-switched conversations.

What's actually new

Cohere's transcribe model is built on a different architecture than Whisper (encoder-decoder transformer with a lighter decoder). Key claims from the release notes:

5.42% WER on LibriSpeech test-clean
Roughly 30% faster inference than Whisper-large-v3 at similar batch sizes
Released with weights + inference code (not API-only)
Supports streaming via chunked inference

The "30% faster" caveat: this assumes you're running on the same hardware Cohere benchmarked. Real-world speedup on consumer GPUs (RTX 4070, M-series Macs) varied from 1.1x to 1.6x in my tests, mostly due to memory bandwidth differences.

What I tested

I built a small benchmark suite of audio files split across four categories:

Studio podcast clips (clean, single speaker, professional mic) - 12 files, 60 sec each
Zoom meeting recordings (multi-speaker, occasional crosstalk, average mic) - 8 files, 90-120 sec each
Phone call recordings (8kHz, compression artifacts, mobile mic) - 6 files, 30-60 sec each
Code-switched audio (English-Mandarin, English-Spanish) - 5 files, 60-90 sec each

Ground truth transcripts came from a mix of human transcription (paid) and existing high-quality automatic transcripts that I manually corrected.

Results

Numbers below are WER percentages, lower is better:

Category	Cohere Transcribe	Whisper-large-v3	Margin
Studio podcast	4.1%	5.2%	-1.1%
Zoom meeting	7.8%	8.6%	-0.8%
Phone call (8kHz)	14.2%	13.5%	+0.7%
Code-switched	19.6%	12.4%	+7.2%

Two takeaways:

Studio + meeting audio: Cohere wins by 0.8-1.1% absolute WER. Noticeable but not transformative.

Phone audio: Cohere is slightly worse. The training data appears to skew toward 16kHz+ recordings, so 8kHz phone audio degrades faster than Whisper, which has explicit phone-quality augmentation in its training mix.

Code-switched audio: Cohere is significantly worse. Whisper-large-v3 was trained on multilingual data with code-switching; Cohere's training emphasis seems heavier on monolingual English. If your use case involves bilingual speakers, Whisper still wins.

Latency comparison

Inference speed mattered for me because I'm building a small note-transcription tool. Average wall-clock time to transcribe 60 seconds of audio on RTX 4070 (12GB):

Cohere Transcribe (default chunking): 4.2 seconds
Whisper-large-v3 (CTranslate2): 6.1 seconds
Whisper-large-v3 (vanilla PyTorch): 11.8 seconds

Cohere with the streaming API was further down to about 1.8 seconds for the first usable token, vs Whisper-streaming at around 2.5 seconds. The "30% faster" claim is roughly accurate for batched inference; streaming gap is closer to 25-30%.

Where it fits in the OSS speech stack

A practical framework for picking a model in April 2026:

Studio podcasts, audiobooks, clean single-speaker audio: Cohere Transcribe wins on accuracy + speed
Multi-speaker meetings (Zoom/Meet/Teams): Cohere has slight edge but both work; pick based on infra preference
Phone audio, telephony, voicemail: Whisper-large-v3 still has the edge from telephony augmentation
Code-switched / multilingual / bilingual conversations: Whisper, no question
Real-time streaming UX (sub-2-sec first token): Cohere's streaming is meaningfully better

If you only have one model deployed, Whisper-large-v3 is still the safer default for general use because of the multilingual coverage. If you can deploy two, swap to Cohere for clean English audio paths.

Quick implementation notes

Running Cohere Transcribe locally took about 30 minutes from clone to first transcription. Notes from setup:

The default inference script assumes CUDA. CPU fallback works but is roughly 8-12x slower
Batch size affects memory more than throughput in my testing - I got best throughput at batch_size=4 on a 12GB GPU
Streaming mode requires an explicit chunk_length parameter; defaults to 30 seconds, can go down to 5 seconds for lower latency at the cost of slightly higher WER

Compared to integrating Whisper via OpenAI's Python package (~10 minutes to first transcription), Cohere's setup is more manual but doesn't require an API key for self-hosting. I've been tracking similar open-source AI model deployments at OpenAI Tools Hub if you want a broader comparison.

What I'm watching next

A few open questions I'd want to test if I have time:

Long-form audio (30+ min): Both models drift on long audio without explicit chunking. Cohere's streaming mode might handle this better but I haven't measured.
Domain-specific fine-tuning: Cohere's open weights make fine-tuning easier than Whisper if you have labeled audio in your vertical (legal, medical, technical podcasts).
Distillation: Whisper has community distilled variants (Distil-Whisper, faster-whisper). If Cohere's community produces similar distilled versions, that closes the size/speed gap further.
Voice activity detection (VAD) integration: Whisper has well-tested integrations with Silero VAD and pyannote. Cohere's ecosystem is younger. (Related: Gemma 4 GGUF deployment notes — similar ecosystem maturity issues when working with newer open-source model weights.)

Closing thought

Cohere's transcribe is a solid drop-in replacement for Whisper in clean-audio paths, with meaningful inference speed gains. It's not a Whisper killer because the multilingual and telephony coverage isn't there yet, but it's the first OSS speech model in a while that competes with Whisper-large-v3 on the dimensions that matter for production deployment.

If you're shipping anything that touches audio, it's worth running your own benchmark on your actual audio distribution. The benchmark numbers vendors report are useful but rarely match your domain.

Allocating Bitcoin via Hong Kong spot BTC ETFs - small account math from April 2026

Jim L — Wed, 29 Apr 2026 07:11:01 +0000

Hong Kong's three spot Bitcoin ETFs (3517 ChinaAMC, 3439 Bosera, 3008 HashKey) crossed the two-year mark this month. I've been tracking allocation math for retail HK investors since launch, and most of the "how much BTC should you hold" content is still written by US crypto-Twitter — which ignores nearly every constraint a HK retail account actually has.

Writing this as a small-account perspective, not advice. If you're managing 8-figure portfolios, none of this applies.

What's actually different about HK spot BTC ETFs

Same underlying BTC exposure as a Coinbase wallet, but the wrapper changes the math:

HKD-denominated vs USD spot. Currency drift is small over short holds; matters more for 5+ year buy-and-forget.
Trading hours: HK 9:30-12:00 + 13:00-16:00, weekdays only. BTC moves 24/7, so weekend gaps can cost you on Monday open.
Brokerage fees: 0.05-0.15% per trade through Futu/HSBC vs 0.5-1.0% on spot crypto exchanges (after spread). Round-trip cost saving compounds.
No SFC margin on crypto ETFs in HK retail accounts (as of writing). You can margin Hang Seng index but not these.
Daily creation/redemption - basically irrelevant unless you're trading 100+ lots.

The interesting one is that HK has no capital gains tax. Holding spot BTC has the same tax treatment as the ETF for HK residents, so the tax angle US guides obsess over doesn't translate.

The retail allocation math

Standard portfolio theory says some BTC allocation improves a 60/40 (60% equities, 40% bonds) Sharpe ratio. The hard part is "how much."

I ran a quick backtest on a HKD-denominated 60/40 (Hang Seng + HK government bond proxy) plus various BTC allocations from May 2024 (when 3517 launched) through April 2026:

0% BTC: ~7% annualized, 14% volatility
2% BTC: ~7.8% annualized, 15% volatility
5% BTC: ~9.5% annualized, 17% volatility
10% BTC: ~12% annualized, 22% volatility

The 2-5% range buys you maybe 2 percentage points of annual return at the cost of meaningfully more volatility. Past performance won't repeat, and BTC has a history of -50% drawdowns. A retail HK investor who panics out of a 10% BTC sleeve at -40% lost more than they would have skipping crypto entirely.

I land at 1-3% as the sane range for someone using BTC for diversification rather than maximalist conviction.

(I cover the full allocation breakdown in my Hong Kong Bitcoin ETF allocation guide, including broker comparisons for Futu vs Tiger.)

A few mistakes I've made or watched friends make

Yo-yo rebalancing. Every time BTC moved 5% I'd buy or sell a tiny lot to "stay at target." The transaction costs (even at Futu's 0.05%) ate maybe 30% of the alpha across a year. Quarterly rebalance with a +/-50% band around target is plenty.

Treating allocation as static. A friend set 5% target in May 2024. By Q4 2024 BTC was up 80%, his sleeve was 9% of portfolio. He didn't rebalance. By Q1 2026 the position was 14% and his stomach gave out. He sold the entire sleeve at a 20% drawdown from peak.

ETF concentration. The three HK spot BTC ETFs charge different mgmt fees (3517 ~0.85%, 3439 ~0.99%, 3008 ~1.99% as of latest filings — verify current numbers). The fee gap matters over 5 years. I split between 3517 and 3439 to avoid tracking risk on the cheapest.

Treating it as a yield play. Some HK influencers compare 4-5% USD savings rates to "expected BTC return." This isn't an apples comparison. Savings is a return-of-capital instrument; BTC is a return-on-volatility instrument. They live on different rows of the spreadsheet.

A simple framework I actually use

Three rules, written down once and then ignored most of the year:

Define your loss tolerance in dollars, not percent. "If this entire sleeve goes to zero, what changes?" Mine: 2% of liquid net worth. Below that, I sleep through drawdowns. Above that, I do not.
Set a rebalance band, not a target line. Target 2% means rebalance only when sleeve goes above 3% or below 1%. That's a 50% band each side.
Quarterly only. First trading day after each quarter end. Set a calendar reminder, ignore the rest of the year.

The behavioral discipline is the hard part. The math is not.

Why HK-specific guides matter

US-centric crypto content treats Coinbase as default and worries about IRS basis tracking. None of that applies to HK retail. A HK guide should cover:

Which broker (Futu vs Tiger vs HSBC) has the lowest all-in cost for ETF trades
Fee schedule comparison across the three spot BTC ETFs
HK margin rules (you can't margin BTC ETFs but you can margin index ETFs that fund the BTC sleeve)
Behavior frameworks calibrated to HK trading hours (no after-hours panic-selling possible, which is actually a feature)
Tax treatment for HK residents holding ETFs vs spot

I haven't seen all of this in one place yet, which is part of why I've been writing about it. My Hong Kong Bitcoin ETF guide covers the broker and fee comparison side.

Closing thought

The hardest part of crypto allocation isn't picking the percentage. It's pre-committing to a rule and not breaking it when BTC goes 2x or -40%. The wrapper (spot BTC vs HK ETF) doesn't change that; it just changes the friction of executing the rule.

Two years of HK spot BTC ETF data is still a tiny sample. Treat any framework (mine or anyone else's) as a starting point, not a backtest gospel.

What I Got Wrong About ChatGPT Pricing — And Why I Wrote a Picker For It

Jim L — Mon, 20 Apr 2026 01:25:12 +0000

I've watched roughly twenty developers pick the wrong ChatGPT tier in the past six months. I was one of them. So I finally sat down and mapped out every scenario where someone on my team had guessed wrong and why.

The short version: the pricing page answers the wrong question.

The pricing page lies by omission

Open the ChatGPT pricing page and you see four tiers: Free, Plus ($20/mo), Team ($25/user/mo), Enterprise (contact sales). The natural reading is bigger number = more serious user. So if you use it for work, Team. If you're a team, Enterprise.

That's almost always wrong. Here's what the page doesn't tell you.

Free covers more than you think in 2026

I kept seeing teammates upgrade to Plus because "I use it for work daily." Then I'd ask how often they hit rate limits, and most of them couldn't remember the last time. GPT-4 class access on Free in 2026 is real (with caps). If you're not seeing the "you've reached your limit" message more than twice a week, you are paying $240/year for something you don't need.

Upgrade signal: rate limit hit 2+ times per week. Not "I use it a lot." Not "I'm a power user." Actual measured rate limit hits.

Team economics fail below 4 people

This is the one that surprised me most. ChatGPT Team is $25/user/mo annually. For a 2-person team, that's $50/mo. Two individual Plus subs? $40/mo. You pay the Team premium for admin controls and data-exclusion from training — and at 2 people, the admin controls do nothing for you.

Team makes sense around 4+ people, or when data-exclusion is a hard business requirement (most employers with compliance mandates will require it). Below that, two or three Plus subs are cheaper.

Enterprise is a negotiation, not a price

The $60/user/mo rate you see cited is a public benchmark. Real Enterprise deals happen around 150+ seats and the per-seat rate moves. What you're actually buying: SSO/SAML, audit logs, dedicated support, HIPAA BAAs, custom data retention. If none of those words matter to you, Enterprise is wrong.

Shared Plus is a real option for personal use

GamsGo sells Plus slots for about $6/mo. They buy the subscription and give you your own credentials with a private slot — it's not password sharing. Your chat history is yours; they can't read it.

It sits in ToS gray area because OpenAI's terms expect single-user accounts. 5M+ people use the service and there's a refund policy for the cancellation risk. Not appropriate for business data. Fine for personal use if your budget is tight.

The decision isn't about budget

The framing I settled on is different from the pricing page. The relevant axes are:

Are you hitting rate limits? If yes, you need Plus-level access or higher. If no, stay on Free.
Is this for personal or business? Business use with data-exclusion = Team minimum. Personal = Free, Plus, or shared Plus.
How many people share this account? Solo stays on tier 1. 2-3 people prefer individual subs over Team unless they need shared workspace. 4+ people justify Team. 100+ or compliance = Enterprise.
What's the budget priority? If minimizing cost is the top constraint, the shared-Plus path beats retail Plus by ~70%.
Do you need compliance? SOC2/HIPAA audit requirements = Enterprise, no alternative.

Most of the wrong picks I saw came from people skipping step 1 and jumping to budget or team size first. If you're not hitting rate limits, none of the other axes matter — stay on Free.

I built a picker to stop answering this in DMs

After the fourth "which plan should I get" conversation in a week, I wrote a small React tool that walks through the five questions and spits out the matching plan. Five dropdowns, no signup, no email. It's not doing anything clever — it's encoding the decision tree I wish I'd had six months ago.

The interesting part for me wasn't the tool itself. It was realizing how much the pricing page obscures the decision. Free tier actually beats Plus for most casual users. Team is a bad middle tier below 4 people. Shared Plus is a real option that OpenAI doesn't officially acknowledge but 5M+ users rely on.

If you're picking a plan and stuck, the five questions above are the actual decision tree. If you want the tool that encodes it, that's a future post — I haven't published the URL yet because I want to see how many people land here first.

What I'd do differently on the tool itself

Three things I'd change if I were rebuilding it:

Start with the rate-limit question, not the usage frequency. Usage is fuzzy. Rate-limit hits are concrete. The tool currently asks about usage first, which is the wrong signal to lead with.
Surface the annual cost, not monthly. $240/year vs $0 is more motivating than $20/mo vs $0.
Show the GamsGo shared-Plus option earlier. I currently only surface it when budget is set to "cheapest possible." But a lot of users don't know it exists and wouldn't volunteer "cheapest" as their primary filter.

Still debating whether to add a "team size gradient" slider instead of the 4-bucket dropdown. The reality is the economics flip hard between 3 and 4 people, and a slider might make that cliff easier to see.

If you're currently on the wrong plan and want to double-check — the five questions are above. No tool required. The pricing page isn't going to help you; the questions will.

5 + 1 Indie Web Projects I Built Solo in 2026 (AI Tools, Finance, Pet Care)

Jim L — Sat, 18 Apr 2026 02:23:29 +0000

5 + 1 Indie Web Projects I Built Solo in 2026

I'm Jim Liu, an independent developer based in Melbourne. Here are six side projects I've shipped solo over the last twelve months. None of them are VC-funded, all of them live under my own domain, and most were written on nights and weekends after day-job hours.

1. OpenAI Tools Hub — honest AI tool reviews

OpenAI Tools Hub is an opinionated review site for the current wave of AI coding and writing tools: Claude Code, Cursor, GitHub Copilot, ChatGPT, Windsurf, Warp, and a few dozen more. Each review has a "how we tested" section, a pricing table pulled monthly, and a short "who should skip this" paragraph — because not every tool is worth its ticket price.

It also ships ~36 free developer tools (LLM latency comparator, Claude-skills marketplace comparison, prompt cost calculator) at openaitoolshub.org/tools. Next.js 16, Cloudflare Workers, and a heavy bias against AI-generated listicles.

2. SubSaver — save money on subscriptions

SubSaver compares subscription prices across 30+ services (Netflix, Spotify, ChatGPT Plus, YouTube Premium, NordVPN, Adobe Creative Cloud) and shows how to get them cheaper through family plan sharing, annual billing, promo codes, and verified shared plans.

The core hypothesis: most people overpay for streaming and SaaS subscriptions by 40–70%. My job is to show the math, not to sell anyone a scheme.

3. LowRiskTradeSmart — low-risk trading research

LowRiskTradeSmart focuses on covered calls, LOF premium arbitrage, and Hong Kong bond yield analysis. Its HK bond yield comparator calculates 2026 iBond, Silver Bond, and Green Bond interactive yields from HKMA data. Multi-locale (EN / zh-CN / zh-HK).

4. AlphaGainDaily — covered-call and yield ETF insights

AlphaGainDaily tracks high-yield ETFs (YBTC / BCCC / BTCI / BAGY) and the newer wave of Bitcoin covered-call funds, including the Goldman Sachs Bitcoin Premium Income ETF (filed April 14, 2026). Plain-English weekly alpha analysis, no crypto moon-speak.

5. LevelWalks — puzzle game walkthroughs

LevelWalks is my lightest project — step-by-step walkthroughs and level guides for mobile puzzle games. Aimed at casual players who want a nudge, not a full solution leaked. Fun to build, occasionally catches a small burst of Google traffic when a new game trends.

+1: PawAI Hub — free AI tools for pet owners

Separately, I also run PawAI Hub — a free hub of honest pet-care tools for dog and cat owners. It has a dog food calculator (calories by breed / weight / activity), a cat age in human years calculator that drops the "× 7" myth in favor of the actual biological curve, an AI breed identifier (photo → top 3 guesses), an emotion reader that parses body language from a photo, and a training Q&A backed by an LLM with cited sources.

Built solo in the same stack (Next.js, Cloudflare Workers, D1, R2). No signup, no dark patterns.

Why post this here?

Because I see a lot of "portfolio indie hackers" posts on DEV and I've never written one for mine. If anything here resonates — especially the "review site with downsides admitted" approach from OpenAI Tools Hub, or the D1-runtime blog pipeline powering PawAI Hub — I'm happy to write a follow-up that goes deep on stack choices and what broke. Leave a comment and I'll pick the most-requested topic.

Not looking for traffic. Just putting names to projects.

5 Small Web Projects I Built as an Indie Developer in Melbourne

Jim L — Fri, 17 Apr 2026 02:35:18 +0000

I'm Jim, a Melbourne-based indie developer. Over the last year I've shipped five small web projects across AI tools, subscription management, Hong Kong investing, crypto research, and daily puzzle games. Here's a quick walkthrough of each, what problem it solves, and what stack it uses.

1. OpenAI Tools Hub

A free directory of AI tools with honest reviews and head-to-head comparisons. Covers ChatGPT, Claude, Cursor, GitHub Copilot, Midjourney, and 50+ other tools. Built as a Next.js 15 app on a VPS, with a Supabase-backed blog pipeline so I can publish new comparisons without redeploying.

Link: openaitoolshub.org

2. SubSaver

A subscription manager that shows you how to save on Netflix, Spotify, ChatGPT Plus, YouTube Premium, NordVPN, and 30+ other subscriptions through family plans, annual billing, and verified shared plans. Runs on Cloudflare Workers via OpenNext, with Supabase Postgres for the content tables.

Link: subsaver.click

3. Low Risk Trade Smart

Hong Kong ETFs, HK IPO strategies (打新), LOF premium arbitrage, and low-risk trading guides for Asia-Pacific investors. Trilingual (English, Simplified Chinese, Cantonese). Also a Next.js site, with a DB-driven catch-all route for the multi-locale blog.

Link: lowrisktradesmart.org

4. AlphaGain Daily

Daily crypto news, DeFi updates, macro research, and long-term portfolio insights. Covers Bitcoin, Ethereum staking, Solana, and the major L1/L2 ecosystems. Prisma + Postgres for the news feed, and a lightweight editorial workflow so I can post while reading my feeds in the morning.

Link: alphagaindaily.com

5. LevelWalks

A free daily puzzle and brain training platform featuring logic grid puzzles, word games, sudoku, nonogram, and a MindSort solitaire variant I built for seniors in my family. Cloudflare Pages + static JSON for levels and blog posts. Zero runtime server, which keeps latency and cost low.

Link: levelwalks.com

I'd love feedback on any of these — especially from other indie builders. What stacks are you running, and what do you wish I'd built differently?

How I Fixed 3 Cannibalizing Blog Pages — Real GSC Data + Next.js Fix

Jim L — Fri, 17 Apr 2026 01:41:22 +0000

Google Search Console flagged something odd on one of my Next.js blogs this week: three different pages were all ranking for the same keyword at positions 5 to 8 — but not one of them had a single click.

That is textbook keyword cannibalization, and it took me about thirty minutes to fix. The part I found interesting is that the fix is almost entirely at the content layer, not the technical layer. Next.js already gives you the tools you need — the question is whether your frontmatter and internal linking are doing what they should.

Here is the full walkthrough with the actual data.

What GSC Actually Showed

Pulling the queries report for the last 28 days and filtering to the problematic term, I got something like this:

URL slug	Position	Impressions	CTR
page-a	5.1	14	0%
page-b	5.2	12	0%
page-c	5.6	11	0%

For the same four-word query, Google was seeing three pages it thought were roughly equally relevant and none of them were clearly best. Searchers got confused, none of them clicked.

Meanwhile the same three pages had different keyword wins elsewhere:

URL slug	Winning KW	CTR
page-b	"X vs Y"	9.1%
page-c	"Z vs Y"	22.2%

So the pages themselves were fine. Each had a specific comparison angle that was working. The problem was the shared, broader keyword — they were all undifferentiated on it, and Google could not decide which to rank.

The Diagnosis (5 minutes)

Open each page's frontmatter. Look at the title and description. Do any of them look nearly identical?

Mine looked like this:

# page-a
title: "X Tools Hong Kong: Y vs Z vs W"
description: "X tools in Hong Kong compared. Y, Z, W fees, returns..."

# page-b
title: "X Tools Hong Kong — Y vs Z vs W Fees and Returns Compared"
description: "Hong Kong X tools comparison. Y 0.2-0.8%, Z 0.35-0.65%..."

# page-c
title: "Y vs Z Hong Kong: Which One Fits Your Style"
description: "Y vs Z vs W Hong Kong comparison. Fees 0.1-0.8%, honest downsides..."

Page A and B were nearly identical. Both listed Y, Z, and W in the title. Google saw them as the same intent page. Page C was doing better on its specific 2-way compare term (9.1% CTR) but the description still mentioned W, which pulled it into the broader three-way competition.

The Fix: Differentiate Intent, Don't Canonicalize

The first instinct is to add canonical meta pointing everything at one page. I decided against that for two reasons:

The pages have different specific-term wins (9.1% and 22.2% CTR on their own terms). Canonicalizing everything to page B would lose those.
Once you canonical a page, Google treats it like a duplicate and may stop crawling it meaningfully. Reversible but not cheap.

Instead: differentiate the titles and descriptions to match different search intents, and let internal linking consolidate topic authority on a pillar.

Page A became beginner-focused (new to the space):

title: "X for Beginners: Y's $0 Minimum, Z Core, and W Fund Smart"
description: "First-time X in Hong Kong? Y's $0 min, Z Core, W Fund Smart compared for beginners — plus when DIY is actually cheaper."

Page B became the pillar (canonical target for the broad term):

title: "X Hong Kong Comparison: Y vs Z vs W Fees, Returns, and MPF"
description: "Hong Kong X comparison, April 2026. Y 0.2-0.8%, Z 0.35-0.65%, W 0.25-0.6% — full fee stack, MPF integration..."

Page C stayed narrow (the 2-way compare winner):

title: "Y vs Z Hong Kong: Which One Fits Your Investment Style"
description: "Y vs Z Hong Kong head-to-head, April 2026. Fees from 0.1-0.8%, real portfolio allocations, ERAA vs Core philosophy..."

Notice the description change on page C — I removed vs W from the description. That single change narrowed the search-intent match so the page stops competing for the broad term.

The Internal Linking Piece

Differentiated titles are only half. The pillar page (B) needs to accumulate topical authority from the satellite pages (A and C). So I added a Related Reading callout at the top of A and C:

> **Want the full Hong Kong X landscape?** This article is a head-to-head between Y and Z only. For W added to the mix, see our [X Hong Kong Comparison](/en/blog/pillar-slug) pillar.

In Next.js markdown/MDX, this is just a standard link — remark-gfm handles blockquotes, and the <Link> component in your layout picks up internal URLs. No special config.

Two reasons this matters more than most people think:

It signals pillar intent to Google. When satellite pages consistently link to a specific page as the "full" version, Google consolidates ranking signals there.
It improves UX. Someone landing on page C who actually wanted the three-way compare now has one click to the pillar.

What I Did Not Do

I did not:

Change slugs (costs 301 redirects and rankings).
Add rel=canonical across pages.
Touch the sitemap.
Request reindexing manually (IndexNow handled it automatically — more on that below).

The fix is title frontmatter + description frontmatter + one markdown callout per satellite page. That is a 10-line diff per file.

Pushing the Fix Live

Next.js blog, deployed via GitHub Actions to a VPS. The commit was three file edits. CI ran in 5 minutes 36 seconds. Page built, deployed, verified with curl.

curl -s https://mysite.example.com/en/blog/pillar-slug | grep -oE "Hong Kong Comparison"

Returns the new title. Good.

IndexNow for Fast Re-crawl

One thing I did want: fast re-crawl, because Google's existing cached version of those three pages still showed the old titles. If a searcher saw the stale cached result, they would click based on old framing. I wanted Google to refresh those specific URLs today, not in two weeks.

IndexNow does this. It is a simple API supported by Bing, Yandex, and others (Google still does not endorse it but rumor has it they read the signals). The request is one POST with a key file at your root.

import requests

payload = {
    "host": "mysite.example.com",
    "key": "YOUR_KEY",
    "keyLocation": "https://mysite.example.com/YOUR_KEY.txt",
    "urlList": [
        "https://mysite.example.com/en/blog/page-a",
        "https://mysite.example.com/en/blog/pillar",
        "https://mysite.example.com/en/blog/page-c",
    ],
}

for endpoint in [
    "https://api.indexnow.org/indexnow",
    "https://www.bing.com/indexnow",
    "https://yandex.com/indexnow",
]:
    r = requests.post(endpoint, json=payload, timeout=20)
    print(f"{endpoint}: {r.status_code}")

Three endpoints, three 200/202 responses, done in under a second. Bing typically re-crawls within 24-48 hours. In my experience, Googlebot follows Bingbot traffic spikes surprisingly closely, so the effect often shows up indirectly within a week.

The Thing I Almost Missed

Before shipping, I triple-checked one thing: the page with the 22.2% CTR on its specific 2-way compare term. That was the best-performing page on the whole site for that angle. Canonical-ing it, changing its slug, or even over-editing its title could destroy that win.

So that page got zero changes except the Related Reading callout at the top. Description stayed the same. Title stayed the same. I only changed the other two pages' titles to deflect the broad-term competition away from it.

It is easy to over-engineer an SEO fix. Find the page that is working and leave it alone. Change the pages that are stealing its share.

Results Timeline

Position re-calibration on cannibalization fixes typically takes 2 to 4 weeks for Google to settle on which page wins for which intent. I will know by early May whether the pillar consolidates or whether the three pages re-split.

What I am watching in GSC:

Pillar page (B) impressions on the broad term — should go up
Beginner page (A) and specific compare (C) impressions on the broad term — should go down (by design)
Specific compare (C) on its 2-way term — should stay flat or go up slightly
Clicks on the pillar's CTR — should be the biggest win, from 0% to 2-5% range

If all four move that direction, the fix worked. If the pillar's impressions drop instead, something else is wrong — either the title is too narrow now, or the internal links need stronger anchor text.

The Takeaway for Next.js Devs

Keyword cannibalization is almost always a content-layer problem masquerading as a technical one. Most stacks give you what you need:

title and description in frontmatter
Internal linking via <Link> or markdown
Canonical URLs derived automatically from file path

The work is in the audit and the differentiation, not in the code. Read your own descriptions out loud — if two of them are answering the same question with the same words, Google is going to think the same thing.

Ten minutes of honest editing and your GSC report starts looking different in a month.

If you want to audit your own pages faster, a couple of tools I keep open while doing this kind of review: Meta Tag Analyzer for catching title/description conflicts across similar URLs, and Schema Generator for making sure the right page is winning the Article rich result. Both are free and I built them after hitting exactly the situation above.

If you're tracking cannibalization across more than one site, picking the right tool stack matters. The AI SEO Tools Comparison on OpenAI Tools Hub goes through which tools surface query-overlap and which only flag duplicate-title cases — useful before you commit to a workflow. And as more search traffic shifts to AI surfaces (ChatGPT, Perplexity, Google AI Overviews), AI Search Visibility Tools Comparison walks through the trackers worth running alongside GSC.

I Switched from LangGraph to Mastra for My TypeScript Agents — 18 Hours vs 41

Jim L — Thu, 16 Apr 2026 02:31:29 +0000

I spent three weekends in February trying to get a LangChain/LangGraph agent working in a Next.js app. By Sunday night of the third weekend, I had 41 hours logged, a mass of Python-to-TypeScript bridge code, and an agent that completed about 87% of what I threw at it.

Then a friend sent me a link to Mastra. Four days later, I had the same agent running natively in TypeScript. 18 hours total. No bridge code. No subprocess spawning. No serialization headaches between Python and my frontend.

I want to talk about what actually changed and where the rough edges still are.

The problem with Python agents in a TypeScript stack

My project is a multi-step research agent — it takes a topic, searches several sources, cross-references findings, and produces a structured summary. Standard stuff. The architecture is Next.js frontend, Vercel deployment, Postgres for state.

LangGraph is excellent software. The graph abstraction for agent workflows makes sense. But here's what nobody tells you upfront: if your entire stack is TypeScript, using a Python agent framework means you're now maintaining two runtimes, two dependency trees, two deployment pipelines, and a serialization layer between them.

I tried the LangChain.js port first. It's always a few versions behind the Python original. Some features exist in docs but not in the npm package. I filed two issues that turned out to be "not yet ported from Python." The community examples are 90% Python. Stack Overflow answers are Python. The mental overhead of translating between the two languages while debugging agent logic was genuinely draining.

So when I saw Mastra — TypeScript-native, built by the team that made Gatsby, YC-backed, sitting at around 22K GitHub stars — I figured it was worth a weekend experiment.

What switching actually looked like

Mastra's mental model is closer to how I already think about TypeScript applications. You define agents as objects with tools, instructions, and a model. Tools are just typed functions. Workflows (their equivalent of LangGraph's graphs) use a step-based API that chains with .then() and .branch().

Here's what surprised me: I didn't need to learn a new paradigm. The agent definition reads like a regular TypeScript module. The tools have Zod schemas for input/output validation — something I was already using everywhere else in the app. Type inference flows through the entire chain.

Rewriting my research agent took about 12 hours. The remaining 6 hours were spent on the retrieval pipeline (Mastra has a built-in RAG module with chunking and embedding support) and testing.

The part I dreaded most — the multi-step workflow where the agent decides which sources to query based on initial results — turned out to be simpler than the LangGraph version. In LangGraph, I had conditional edges between nodes, a state schema in TypedDict, and a routing function. In Mastra, it's a workflow with .branch() that returns the next step name. Both work. The Mastra version is about 60% less code and doesn't require me to think in graph theory.

The numbers that actually mattered

After running both implementations against my test suite of 200 research queries:

Task completion rate: Mastra agent hit 94.2% vs 87.4% with LangGraph. Some of this is probably down to me writing better tool definitions the second time around, so take the comparison with appropriate skepticism. But the type safety caught several edge cases during development that I'd missed in the Python version — malformed tool outputs that would silently pass in Python but threw compile-time errors in TypeScript.

P95 latency: 1,240ms (Mastra) vs 2,450ms (LangGraph). The LangGraph number includes the Python subprocess overhead and JSON serialization round-trips. Not a fair comparison of the frameworks themselves — more a reflection of what happens when you eliminate a language boundary. If you're running LangGraph in a pure Python backend, the gap would narrow considerably.

Deployment: This is where I felt the biggest quality-of-life jump. vercel deploy and you're done. 90 seconds. No Docker container for a Python runtime. No Lambda layer for dependencies. No cold start penalty from spinning up a Python process. It's just a Next.js app with some extra API routes.

Where Mastra is still rough

I'd be dishonest if I didn't mention the gaps.

The ecosystem is young. LangChain has integrations with seemingly everything — obscure vector databases, every LLM provider, dozens of document loaders. Mastra covers the major ones (OpenAI, Anthropic, Google, Pinecone, PGVector) but if you need something niche, you're writing a custom integration.

Documentation has improved a lot since I started, but there are still areas where I had to read the source code. The workflow error handling section, in particular, could use more examples.

The community is growing fast but it's a fraction of LangChain's. When I hit a problem at 11pm, there were maybe three relevant GitHub discussions. With LangChain, there would have been a dozen Stack Overflow threads.

And the agentic patterns — reflection, planning, multi-agent orchestration — are less battle-tested. LangGraph has been used in production by hundreds of companies. Mastra is getting there, but the edge cases in complex multi-agent setups are still being discovered.

Who should actually consider switching

If you're running a Python backend and LangGraph works for you, I see no reason to switch. The framework is mature and well-supported.

But if you're in the situation I was in — TypeScript stack, deploying to Vercel or Cloudflare, tired of maintaining a Python sidecar just for your agent logic — Mastra removes a real and ongoing source of friction. The 23 hours I saved on initial setup will compound every time I add a new tool or modify a workflow, because I'm working in one language instead of two.

I'm three months in now. The agent handles roughly 400 queries per day in production. I haven't regretted the switch.

Running TypeScript agents in production? I'm curious what framework you landed on and whether you hit similar Python-bridge problems. Drop a comment — genuinely want to compare notes.

A couple of related things I've written up separately if you're going deeper on this stuff: my notes on Claude Code memory layouts for large codebases which is how I keep the Mastra agent's context budget in check, and a benchmark I ran last week on GPT Image 1.5 vs DALL-E 3 that uses the same "measure actual prompts, not vendor demos" methodology I used here.

For more on the TypeScript-native agent landscape, I found the Mastra AI Framework Review on OpenAI Tools Hub useful reading — it goes deeper into the architecture tradeoffs than most quickstarts do. And if you're weighing Mastra against DeerFlow specifically, the direct comparison at Mastra vs DeerFlow covers the workflow model differences well.

How I built a LOF arbitrage monitor for HK/CN ETFs (and what I learned about 'free' alpha)

Jim L — Tue, 14 Apr 2026 01:22:05 +0000

I keep seeing the same question in HK/SG investor chats: "the S&P 500 QDII ETF is trading 5% above NAV again — is this free money?"

Short answer: not really. But the idea — that on-exchange ETF prices can drift from their net asset value — is real enough that I wanted a dashboard that just told me, every 15 minutes, which Chinese LOF/QDII ETFs were trading most disconnected from the underlying. So I built one.

This is the boring-but-useful write-up: what a LOF is, why premiums happen, what the pipeline looks like, and the three things I got wrong on the first try.

What's a LOF, quickly

LOF = Listed Open-Ended Fund. It's a mutual fund wrapper that also trades on-exchange. QDII LOFs are the ones that hold offshore assets — S&P 500, Nasdaq, HK tech, gold miners, etc.

The premium/discount mechanic:

NAV is published once a day (T+1 for offshore QDII — you get yesterday's value tomorrow morning).
On-exchange price moves live during the trading day.
When retail piles into, say, 华夏纳斯达克 after a big US overnight rally, the price can float well above the last-known NAV. That gap is the premium.
In theory, the fund house can issue new units to arb it down. In practice, QDII quotas are capped, so premiums can persist for days.

So: premium ≠ free profit. It's mostly "the market is front-running tomorrow's NAV update." But unusual premiums are worth watching, because that's where forced-selling and fat-finger trades show up.

The pipeline

Stack ended up boringly simple. Four moving parts:

Eastmoney REST  ─┐
                 ├─► Python collector (every 15 min, cron)
Tencent REST  ──┘          │
                           ▼
                     SQLite (append-only)
                           │
                           ▼
                Next.js /tools/lof-premium (ISR 15min)

No Kafka, no Redis, no Airflow. It's a 200-line Python script and a static-ish Next.js page.

Collector

The collector is two functions:

def fetch_realtime(code: str) -> dict:
    # 东财 push2 API, returns last price + bid/ask
    url = f"https://push2.eastmoney.com/api/qt/stock/get?secid={secid(code)}&fields=f43,f60,f169,f170"
    ...

def fetch_nav(code: str) -> dict:
    # 天天基金 fundgz API, returns "估值" (intra-day NAV estimate)
    url = f"https://fundgz.1234567.com.cn/js/{code}.js"
    # returns JSONP; strip the wrapper, json.loads the middle

One gotcha that cost me an afternoon: fundgz returns HTML on weekends and holidays (a friendly "市场休市" page) instead of the usual JSONP. First version crashed on every Saturday at 09:15 until I added a content-type check.

Why not just use one source?

East Money gives you price but not intra-day NAV estimate. Tiantian gives you NAV estimate but not L2 price. So you have to join them on the fund code. Cross-check also catches the case where one API starts returning stale data, which happens more than you'd think.

Storage

Single SQLite file, one row per (code, timestamp). Append-only. ~300 funds × 26 snapshots/day × 365 days = ~3M rows/year. SQLite eats that for breakfast.

I briefly tried Postgres. Moved back to SQLite after two weeks because the entire deploy is a file copy and backups are cp lof.db lof.db.bak.

Frontend

Next.js 15, ISR with revalidate: 900. The page is essentially a table sorted by absolute premium, with a tiny sparkline of the last 48 hours per fund.

The sparkline was the part I over-engineered. First I pulled in a charting library (120KB), then I swapped it for a 40-line inline SVG component. Same visual, 3% of the bundle size.

Three things I got wrong on the first try

1. I trusted the "premium" column on 东财

The portal shows a premium column. It's computed off yesterday's official NAV, not the intra-day estimate. For a QDII holding US stocks that rallied 2% overnight, "yesterday's NAV" understates the fund by 2% before the market even opens, so the premium column is systematically inflated on up days and depressed on down days.

Using the estimated NAV instead (the one Tiantian publishes intra-day) cut the noise dramatically. The high-premium list used to be "whatever went up last night in the US." Now it's actually unusual positioning.

2. I assumed 15-minute cadence was fine

It mostly is. But around 09:30 and 14:57 (CN market open / close auction) the price moves 0.5–2% in a single minute. A 15-minute snapshot misses those.

Compromise: 15-min during the day, 1-min windows around open/close auctions. cron with two schedules.

3. I forgot time zones, twice

Tiantian returns Beijing time with no tz marker.
East Money returns Unix timestamps in ms.
My server runs UTC.
My browser renders in Sydney time.

First bug: charts were off by 8 hours. Second bug: I "fixed" it by hard-coding +8, then flew to Sydney, and everything shifted again.

Final rule: store UTC in SQLite, tag Beijing explicitly at the API boundary, format to the browser's locale in the client. Boring, but it's the only approach that survives moving.

Does the data actually give you alpha?

Honestly — mostly no. Here's what a month of logs looks like in practice:

80% of the top-premium funds on any given day are just "US market gapped up overnight, retail is buying the reopen." By the time you see it, the arb is gone.
15% are chronic premium funds — usually QDII with exhausted quota. You can't subscribe at NAV even if you wanted to. The premium is a structural access-fee, not mispricing.
Maybe 5% are genuinely odd: a small-cap sector LOF that jumped on news nobody else was tracking, or a fund where the manager announced something that moved NAV estimate but not price yet.

That 5% is the reason the dashboard exists. Not as a trading signal on its own, but as a "huh, why is this one weird?" attention filter.

What I'd do differently if I rebuilt it today

Push notifications instead of pull. I still refresh the page. A Telegram bot that pings me when premium > 2σ would be 10x more useful.
Historical NAV backfill. My DB starts from the day I deployed. If I'd backfilled 2 years from Tiantian's archive, regime comparisons ("is this premium unusual for this fund?") would actually work.
Skip the live sparkline. Nobody looks at it. A single "premium now vs 7-day avg" number would convey more.

Summary for the impatient

LOF premium = on-exchange price minus intra-day estimated NAV. Don't use the portal's published premium column; it's anchored on T-1 NAV.
Two APIs, join on fund code, cross-check. SQLite is enough. 15-min cadence + 1-min around auctions.
Most "premiums" are just timezone artifacts or quota constraints. The signal you want is the ~5% of funds that are genuinely priced weird today.
Store UTC, tag at the boundary, format at render. Every time.

If you end up building something similar and hit a case I didn't cover — especially around holiday calendars for A-shares vs HK vs US simultaneously — I'd love to compare notes in the comments.

If you want to see the live tool this post is about, I put it up on TradeSmart's A-Share LOF Premium Dashboard. For the savings-side of the same strategy (AU bond ladder vs HK equivalents) I wrote a separate breakdown under best AU savings accounts 2026.

Karpathy's LLM Knowledge Base SEO: I applied the pattern for 12 months and here's what I learned

Jim L — Mon, 13 Apr 2026 02:48:41 +0000

Karpathy's LLM Knowledge Base × SEO: I applied the pattern for 12 months and here's what I learned

On April 3, 2026, Andrej Karpathy posted a short but influential note about using LLMs to build personal knowledge bases. The premise: instead of RAG pipelines and vector databases, you manually clip raw sources into a raw/ folder, let an LLM distill them into structured wiki pages, and query the graph later with your LLM CLI of choice.

No SaaS lock-in. No embeddings. No subscription. Just markdown and an LLM that knows the schema.

I'd been drowning in scattered SEO research for a year — running openaitoolshub.org, an AI tools directory that's gone from DR 0 to DR 30 in 12 months, 126 articles, 130+ earned backlinks. My notes were spread across Notion, Kagi Assistant, local markdown files, a neglected Readwise Reader queue, and a thousand unread tabs. Karpathy's pattern gave me the discipline to consolidate everything into a single Obsidian vault that an LLM could maintain.

This article walks through what I built, the key design decisions, and the one contradiction-preservation trick that changed how I think about personal knowledge bases entirely.

The five-step pattern

Karpathy's original framing was simple:

Set up raw/ — every source you encounter, unedited
Set up wiki/ — structured concept pages the LLM maintains
Distill with an LLM — run a pass where Claude/Codex/etc reads raw sources and updates wiki pages
Cross-link with [[wikilinks]] — let the LLM suggest relationships between concepts
Query the graph with your CLI — ask questions months later, get synthesized answers from the vault

The genius is in step 3 — the LLM does the hard work of synthesis, contradiction detection, and cross-referencing. You do the reading and judgment calls.

How I adapted it for SEO

SEO is a moving target. What worked in Q4 2024 is wrong by Q2 2025. Google's March 2026 Core Update just rewrote half the playbook. I needed a system that could absorb new evidence and propagate updates without me manually re-reading every page.

My vault structure:

seo-obsidian/
├── Home.md                    # glassmorphism dashboard
├── CLAUDE.md                  # LLM operations guide
├── wiki/
│   ├── schema.md              # the concept-page template rulebook
│   ├── concepts/              # 12 SEO concept pages
│   ├── tools/                 # 3 tool profiles
│   ├── people/                # 1 person profile (Karpathy)
│   └── indexes/               # alphabetical catalogs
├── raw/
│   ├── README.md              # explains the three-layer architecture
│   ├── articles/              # long-form sources
│   └── practitioner-notes/    # curated short-form observations
└── maps/
    └── SEO-Domain-Map.canvas  # 21-node mind map

Every concept page follows a strict schema: ## TLDR, ## Key Points, ## Details, ## Applied Example, ## Related Concepts, ## Sources. The rigidity felt annoying at first, but it pays off at query time because Claude knows exactly where to look for each piece.

Three design decisions worth discussing

1. Preserve contradictions instead of resolving them

On April 10, Zhang Kai published a 602-prompt study claiming structured content (H2/bullets/tables) correlates with AI citation. On April 11, a Japanese SEO practitioner published experiments claiming structured data does NOT help AI understanding.

In a traditional wiki I'd have to pick one. In the Karpathy pattern, both claims live in the vault. The Zhang Kai finding is in the main section of geo-generative-engine-optimization.md. The Suzuki counter-evidence is in a ⚠️ Counter-Evidence callout right below it. When I query the vault with Claude, I get both cited.

This is the single most important insight I took from applying the pattern: honest knowledge > confident answers. The vault is a snapshot of the field's current state of confusion, not an attempt to pretend the confusion doesn't exist.

2. The ripple effect as the compounding mechanism

When I add a new raw source, I don't manually update related concept pages. I tell Claude:

$ claude
> Ingest raw/practitioner-notes/zhang-kai-602-prompt-geo-study.md 
> following wiki/schema.md. Update all related concepts with the new 
> evidence and flag any contradictions.

Claude then:

Reads the new source
Decides which of the 12 existing concept pages it affects
Updates each one with the new evidence
Flags contradictions against existing claims
Updates the concept index
Writes a log entry

One source → 5-15 pages updated → all in 45 seconds.

This is what makes it compound. Most note-taking systems are linear (you add, you rarely re-read). This one is multiplicative — every new source makes the whole wiki incrementally smarter.

3. Strict concept-page schema > flexible notes

I experimented with both. Flexible concept pages were easier to write but hell to query. Strict ones were slightly annoying to fill out but let Claude parse them reliably.

The schema:

aliases: []
tags: []
sources: []
cssclasses: [seo-brain-concept]

# Concept Title

## TLDR
One paragraph, 200-250 words. This is what AI engines cite.

## Key Points
5-8 bullet points.

## Details
The main content, 800-1500 words. Can have sub-sections.

## Applied Example
A concrete worked scenario.

## Related Concepts
- [[concept-a]] — why it's related
- [[concept-b]] — why it's related

## Sources
- External URLs
- raw/... paths

Every single concept page follows this. It's like a database schema — restrictive, but queryable.

Three concrete SEO insights that came out of the exercise

Insight 1 — Mean AI-cited content length is 1,375 characters

Zhang Kai's study measured the length of every fragment cited by ChatGPT, Perplexity, and Google AI Overview across 602 prompts. The mean was 1,375 characters — roughly 200-250 words, or about 10 sentences.

Practical implication: write TL;DR blocks of 200-250 words near the top of every article. Break the body into H2-bounded sections of 1,000-1,500 characters. That's the GEO sweet spot for citation.

Insight 2 — Google's March 2026 Core Update targets 7 specific AI writing patterns

Kill these and your content survives:

"Not just X, but Y" constructions
Em-dash overuse
Triad lists ("powerful, elegant, and fast")
Formulaic openers ("In today's fast-paced world...")
Breathless enthusiasm ("game-changing")
False-authority hedging ("It's worth noting that...")
Broad-to-narrow openings

I went through every article on openaitoolshub.org and stripped these patterns. Traffic stabilized. Articles that failed the update all shared these tells.

Insight 3 — Free dofollow directories above DR 55 exist

Conventional wisdom says free directories are DR 0-10 and useless. Actual: I found at least 12 free dofollow directories above DR 55. A field study in early April showed that adding 50 such backlinks moved a DR 46 site to DR 50 in one week.

The misconception comes from the early 2010s when directory submission was spammed to death. Post-2024, curated directories (Navs Site, Acid Tools, Ben's Bites, ShowMySites, NextGen Tools) are legitimate editorial sources.

What tools I used (and didn't use)

Used:

Obsidian (free) for the vault UI
Claude Code for the distillation + query layer
Ahrefs (~$99/month, but sem.3ue.com mirror for specific lookups)
Google Search Console (free) — the most important SEO tool for indie devs

Explicitly NOT used:

No SEO course (they go stale)
No paid link-building service (PBNs are a DMCA landmine)
No vector database (the whole point of the Karpathy pattern is avoiding this)
No subscription SaaS tools beyond Ahrefs

The goal was to keep the tool budget under $100/month and replace expensive tools with LLM-assisted workflows. Mostly worked.

What's next

I packaged the vault as "SEO Brain" for other indie devs. Free 5-concept starter kit is at openaitoolshub.org/en/seo-brain (canonical source, no Medium paywall). Full 12-concept Starter Edition is on Gumroad, $19 launch week, $29 regular.

More importantly — if you're doing personal research in any domain, I think Karpathy's LLM KB pattern is the right structure for 2026. Try it with your own domain (investing research, game dev, climate science, whatever) and let me know what you learn.

The compounding is real. The contradictions-preserved discipline is the trick.

About the author

Jim runs openaitoolshub.org (DR 30, 126 articles, solo) and four sister sites covering trading, SaaS, AI tools, and game directories. He writes about applying indie dev patterns to SEO at his main site.

This article's canonical version lives at openaitoolshub.org/en/seo-brain. Dev.to is a syndication copy.

I Tried Microsoft Agent Framework 1.0 — Three Days In, Here Is What I Think

Jim L — Fri, 10 Apr 2026 03:39:54 +0000

The Merge Nobody Asked For But Everyone Needed

Microsoft released Agent Framework 1.0 on April 7. The pitch: one SDK that fuses Semantic Kernel (enterprise middleware, telemetry, type safety) with AutoGen (multi-agent chat orchestration). No more stitching two libraries together with duct tape.

I spent three days testing it on real work instead of toy examples. Here is what I found.

What Actually Works

The graph-based workflow engine is the star. You define agent relationships as a directed graph — orchestrator hands off to researcher, researcher passes to coder, coder sends to reviewer. Each agent keeps its own session state.

I built a four-agent pipeline that parsed GitHub issues, drafted code, ran tests, and generated PR descriptions. Total setup: around 120 lines of Python. The DevUI debugger runs locally and shows real-time message flows between agents. I caught two infinite-loop bugs through it that would have burned through my API budget otherwise.

MCP support landed on day one. My agents could call external tools through the Model Context Protocol without custom wrappers. I connected a filesystem server and a web search tool in maybe 15 minutes.

Where It Falls Short

Python support feels rushed. The .NET SDK is polished — types, middleware hooks, proper async. The Python package works but documentation has gaps, and some features like the evaluation framework are .NET-only for now. If you are a Python shop, expect to read source code more than docs.

A2A (Agent-to-Agent protocol) is version 1.0 but the ecosystem is basically Microsoft talking to Microsoft right now. Cross-framework interop with LangChain or CrewAI agents is not there yet. Give it six months.

Boilerplate is real. Setting up a simple two-agent chat requires more ceremony than LangGraph or Claude Agent SDK. Fine for enterprise teams with dedicated infra — overkill for a weekend prototype.

How It Stacks Up

I wrote a full breakdown comparing Microsoft Agent Framework against Claude Agent SDK, LangGraph, and CrewAI on my site with actual code examples and benchmark numbers.

Short version: Agent Framework wins on enterprise features, Claude SDK wins on simplicity, LangGraph wins on flexibility. Pick based on where you are running production workloads.

Who Should Care

If your company already runs on Azure and uses Semantic Kernel, this is the obvious next step. The migration path from SK plugins to Agent Framework tools is nearly 1:1.

If you are an indie developer testing the waters, I would start with Claude Agent SDK or LangGraph first. Lower friction, faster prototyping. Come back to Microsoft Agent Framework when you need enterprise observability or graph-based multi-agent workflows.

My Setup

I tested on Python 3.12, WSL2 Ubuntu, with GPT-4.1 and Claude Opus as backend models. Cost for three days of experimentation: roughly $14 in API calls. The DevUI runs locally on port 5000 and uses about 200MB of RAM.

One thing I appreciated: the framework does not force you into Azure. You can use any OpenAI-compatible endpoint, local models through Ollama, or Anthropic directly. The Azure AI Foundry integration is optional, not required.

Bottom Line

Microsoft Agent Framework fills a gap that has existed since enterprises started asking "how do I put AutoGen in production?" The answer: merge it with your enterprise middleware, add proper observability, ship it.

Not revolutionary. But solid engineering that solves a real problem for a specific audience. Which is probably the more valuable outcome anyway.