Forem: LazyDev_OH

I Spent a Week with the MCP Server I Built — 8 Real Cases for Apsity

LazyDev_OH — Sat, 02 May 2026 15:09:50 +0000

In EP.21 I bolted an MCP server onto Apsity. Four tools: keyword_search, app_lookup, list_supported_countries, keyword_search_history. While building it I half-doubted I'd actually use it. Then I used it for a week.

Here's the result: I use it more than I expected. With only four tools, the flow from market discovery to entry decision lands inside one conversation. A keyword search is one line, deep-checking the Top 5 is another, comparing markets is another. The dashboard is for visual exploration; MCP is for fast ask-and-answer — the two channels split naturally.

This post is the eight prompts I actually ran during that week. Each case shows which tool gets called and what the answer looks like — full screen.

TL;DR

4 Apsity MCP tools — keyword_search · app_lookup · list_supported_countries · keyword_search_history

A week in: chat-window queries handle more work than I expected

8 cases — name conflict check, multi-region entry pick, ASO keyword gap, tracked competitor watch, launch-week baseline, meta design guide, research planning, 20-country matrix

Why it helps: deciding and querying happen at the same time, so the friction drops

1. "Validate a new app name — conflict + visibility"

The lightest but most frequent question right before launch. "Is this name available? Does anyone else use it? Will it surface in search?" These decisions are hard to undo post-launch, so verifying first is cheap insurance.

One keyword_search call. Claude pattern-matches the name field for exact and partial hits. Zero exact = available; partial hits = subtitle has to differentiate — "Foco Pro is available, but it'll surface alongside two existing Foco apps, so pair it with a high-search keyword like Deep Focus Timer."

A decision that's hard to reverse after launch finishes in one chat exchange. Light query, heavy consequence.

2. "Compare 3 markets → pick one"

Same keyword, three markets. Comparison alone is just data. Going one step further to "which market should a solo indie enter, and why" turns it into a decision. So I ask for the recommendation in the same prompt, not a follow-up.

Three keyword_search calls (us, jp, kr). Claude builds a matrix — Top 5 avg reviews, dominant model, indie feasibility — then names US as the entry pick with a concrete concept ("envelope + AI auto-categorization") on top. JP needs expensive bank-sync; KR has Toss/Bank Salad eating standalone budget apps; only US still has room for methodology-led differentiation.

An analysis used for decisions has to ship with the recommendation. MCP fetches the data; the LLM adds judgment.

3. "Competitor descriptions → keywords missing from mine"

Core ASO question for any app already in the wild. Which keywords show up across the Top 3 competitor descriptions but are missing from yours? That gap drives search visibility differences. By hand it's an hour.

Two tools chained. keyword_search for Top 3, then app_lookup × 3 to pull every description. Claude counts noun/verb keyword frequency, separates 3/3 vs 2/3 shared, then matches against my own description and surfaces what's missing — streak, daily, motivation.

The most asked ASO question, answered in one chat exchange. Once the missing keywords land, rewriting the first paragraph of the description is the only follow-up.

4. "Tracked competitors → threat & next move"

Apsity's isTracked flag picks the 5 competitors I follow. Stopping there is monitoring. Going one step further — threat scoring + next move as a solo indie in the same response — turns it into action.

One keyword_search call. Claude scores threats from rating + reviews + price (color-tagged tiers) and lands on actionables: "don't fight Forest head-on (312K reviews)", "differentiate against Focus Keeper on ONE axis (themes / stats / Watch-first)."

Competitor analysis matters less for "where they are now" and more for "what I do next." Both arriving in the same response is the channel's real strength.

5. "Build me a launch-week baseline"

The shakiest moment after launch is week-1 numbers. "Is this normal? Did I just bomb?" The only way to know is comparing against apps that recently launched into the same category. That's a baseline — and it's exactly what MCP is good at producing.

Two-tool chain. keyword_search + app_lookup filters 30-day-old launches and averages their week-1 reviews/rank/rating. The baseline lands as "~124 reviews, 60% Top 50 entry, 4.4 rating average." Plus an ops guide — "below 100 reviews? rewrite subtitle. rating dropping under 4.3? you'll bounce out of Top 50."

Post-launch you need a comparison set, not raw data. The baseline tells you whether you're on track, and one chat exchange produces it.

6. "Top 10 meta → my app's design guide"

Subtitle, language, secondary-genre patterns from a Top 10 sweep are useful. Turning them into "a metadata design guide for my next app" in the same response is more useful — that's a checklist you can ship with that day.

keyword_search + app_lookup × 10. Claude pulls description-first-sentences, genres, languages, pricing — "verb+noun subtitle, ~22 languages, Lifestyle as secondary, Free+IAP at 70%" — then converts the patterns directly into a checklist.

An hour by hand, with gaps. In chat the analysis and the design guide arrive together — App Store listing fields can be filled the same day.

7. "History → next-week research plan"

keyword_search_history shows footprints. Footprints alone are a postmortem. Asking for "blind spots + next-week priority keywords (5)" in the same response turns the postmortem into a queue.

keyword_search_history with limit 30. Claude clusters the list, spots US-bias and adjacent-keyword zeros, then drops 5 prioritized keywords — screen time, journal, deep work, UK habit tracker, East Asia pomodoro.

People are bad at noticing what they didn't see. The data sees it. Now my Monday queue auto-fills from one prompt.

8. "20-country sweep → top market + plan"

Last case. list_supported_countries hands back 20 markets, one keyword runs across all of them. The matrix is informative; pushing one step further to "#1 entry market + 3 localization musts" turns global-entry decisions into one response.

Two tools. list_supported_countries + keyword_search × 20. Claude bands markets by Top 5 reviews, picks Vietnam from the EMPTY band based on mobile pop + low entry barrier, then concretes it: lunar-calendar integration, MoMo/ZaloPay payments, Zalo-first share.

A global-entry decision is normally a multi-day exercise. Burns 21/100 of the STARTER quota — fine for a once-a-month prompt that resets the next month's roadmap.

Why four tools is enough

After a week, four tools never felt limiting. Reason: market research is two questions on repeat. "What's ranking?" (keyword_search) and "what does this app do?" (app_lookup). Those two carry the load. The other two are just orchestration.

If anything, having a small surface helps the LLM. Too many tools and Claude burns cycles deciding which to call. Four is small enough to memorize and call by name. "keyword_search US then JP, app_lookup the Top 5" — that level of explicit prompting comes naturally.

And the LLM is better at recombining tools than I expected. Cases 5 (launch baseline) and 6 (meta patterns) use the same two tools but produce completely different analyses. The tool is the input; the LLM produces the analysis. Keeping them separate works best when the tools stay simple.

Why MCP actually helps

It's not the data speed. iTunes was already fast. What's actually different is that deciding and querying happen at the same time.

"What should I look at right now?" and "open that view" are usually two steps. In a chat window they collapse into one. Typing "meditation US Top 50" decides and queries simultaneously. So I end up checking data I'd normally skip.

The answer stays in chat history too. A dashboard is great for visual exploration — sort, filter, charts on one screen — and chat is great for fast ask-and-answer. They sit naturally side by side. Big-picture work goes to the dashboard; pinpoint questions go to chat.

Last thing — and I only got this from building it: MCP's value isn't "hand data to Claude." It's "make data access cheaper for a person." The AI isn't doing my work; it's making my work easier to do.

Next episode

This episode was the catalog of "what you can ask." EP.23 goes a level deeper: gap analysis, idea validation, market-entry feasibility — how to compose four tools into a real decision-making workflow.

And the episodes after that get into combining other MCPs. With Notion, Slack, or Email MCP, "summarize this week's new competitors into a Notion page and ping Slack" becomes one line. That's where this whole thing is actually heading.

Originally published on GoCodeLab.

I Shipped 3 Major Features in 3 Days — Keyword Search, MCP Server, Monthly Magazine

LazyDev_OH — Thu, 30 Apr 2026 16:53:05 +0000

One major feature normally eats a week. Design, implementation, UI, i18n, marketing pages, docs. One at a time. That's the rule I learned. From April 28 to 30, I shipped three of them. Keyword Search, an MCP server, and a monthly magazine. 41 commits, +15,380 lines.

Up front: I didn't build all three with the same hands at the same time. I finished one per day. They landed in the same three days. The reason it worked was simple — I sliced each feature into phases, and the unit I gave Claude was small. This post is a record of those three days.

EP.02 was where I built the Apsity dashboard. EP.03 added AI insights on top. That's the base. The three things I shipped this week sit on top of that — keyword discovery, calling data from Claude directly, and an automated monthly magazine.

TL;DR

April 28-30. 41 commits, +15,380 lines. Three major Apsity features at once

Day 1: Keyword Search (14 tasks). 18 countries, Top 50, AI summary, watchlist

Day 2: MCP server. Apsity data callable from Claude. FREE plan blocked at key issuance

Day 3: Monthly magazine. Phases 1-7 in one day. Auto-sent on the 1st of each month

What made it possible: phase slicing per feature + small Claude prompts

Why these three at once

They weren't separate items. They were a single flow. Apsity already shows registered apps well — revenue, downloads, keyword ranks, competitor changes. What was missing: "Where do I find new keywords?", "How do I use this data in other tools?", and "I want a one-page view of what happened this month."

Keyword Search is discovery. ASO ultimately comes down to picking which keywords to rank for. Looking only at registered keywords is a fishbowl. You need to see how other apps are showing up. So I pull iTunes Top 50 across 18 countries, let AI summarize, and let the user save promising keywords to a watchlist.

The MCP server is the exit door. Sometimes you want to ask the data in natural language from Claude instead of opening Apsity. "How was my revenue yesterday?" — Claude asks Apsity and answers. I'd been thinking about this since I built npm-subscriber-mcp in EP.15.

The monthly magazine is the look-back. Daily alerts came in EP.03. But daily is noisy. After a month, you want to look back and see what happened — and that data is scattered. Aggregate it on the 1st, send it as email, done.

Together: discovery → use → look-back. Both ends of a workflow that were missing. That's why they shipped together.

How concurrency was possible — slicing phases

Three week-long features in three days. The reason it worked is simple. I never looked at a feature as one big lump. I sliced it into small phases. Each phase ends with a working artifact and a commit.

The monthly magazine, for example, was sliced like this.

// Magazine phases

Phase 1 — Language setting (ko/en in Settings)
Phase 2 — Monthly aggregation function
Phase 3 — Claude generates the magazine body
Phase 4 — 4 card components (metrics/chart/reviews/suggestions)
Phase 5 — Magazine page render
Phase 6 — Email send (4 cards inline)
Phase 7 — CLI test tool

Phases 1 and 2 are independent. Phase 3 takes the output of 2. Phases 4 and 5 are built on Phase 3's result. The dependency graph looks serial, but Phase 2 and 4 can run in parallel. Define the data shape early, then build the aggregation query and the card UI separately.

Two benefits. First, the unit I throw at Claude shrinks. "Build me a magazine system" is too big. "Phase 4: just the metrics card component. Input is this object, output is a React component" is precise. Second, when something looks off, I can stop at that phase. I rarely lose a whole day.

Keyword Search was 14 tasks. MCP was 5 stages — server code, auth, gating, UI, docs. The big picture stays in my head, but execution moves in small steps. That's the whole trick.

Day 1 (4/28) — Keyword Search

Day 1 — Search input + AI Summary / GoCodeLab

Day 1 — Top 50 results list / GoCodeLab

April 28 went entirely to keyword search. I shipped 14 tasks at once. It's a tool that searches iTunes Top 50 across 18 countries — not just registered apps, but any app worldwide, by keyword.

I started with requirements. Search form, results list, side panel on row click for app detail, AI summary, search history, watchlist. Free/paid filter, daily limit, input validation. Korean and English i18n. And marketing — Pricing page mention, landing demo, blog announcement in both languages.

Here are the 14 tasks.

// Keyword Search 14 tasks

Backend: iTunes Top 50 helper, daily limit, search history, validation
API: POST /api/keywords/search, history GET/DELETE, summary
DB: KeywordSearchHistory + plan-limits extension
Components: SearchForm, SearchResults, SearchHistory, AISummary, SearchTab
UI: /dashboard/keywords tab, side panel, free/paid filter, watchlist
i18n: full ko/en split
Marketing: Pricing/Landing/Blog ko·en

The core was gating. Daily limits sit in plan-limits. FREE gets N per day, STARTER and up get more. Side panel detail is STARTER+. Watchlist plus daily snapshots are PRO-gated. The UI blocks, the API blocks again. That's the pattern I learned in EP.07 with LemonSqueezy. If you only block at the UI layer, someone routes around it.

Three follow-up fixes after launch. AI summary came back as markdown so asterisks were rendering literally — added a markdown renderer. SWR cache flickered on every search — keepPreviousData option. Side panel scrolled the page background — body overflow lock. None of these show up unless you actually use the thing. The gap between "code that runs" and "product I'd use" is exactly here. Ship 80% fast, fix the last 20% when real problems show up.

Day 2 (4/29) — MCP server

Day 2 — MCP API key screen / GoCodeLab

April 29 went to MCP. EP.15 already taught me the pattern with npm-subscriber-mcp. That one exposed npm download data to Claude. This one exposes Apsity data.

The server itself is a two-day job at most. Use @modelcontextprotocol/sdk to build a stdio server, define tools, and have handlers call the Apsity API. Where I actually spent time was gating.

The problem: MCP is called from external clients like Claude. The key runs in an environment the user doesn't directly control. If a FREE-plan user calls it without limits, costs leak. So how do we block it?

// MCP gating — defense in depth

Layer 1 — Settings UI: issue button disabled on FREE
Layer 2 — POST /api/mcp/keys: server checks plan, blocks
Layer 3 — On MCP call: validate key + re-check plan
Layer 4 — Per-tool gating (PRO-only tools separated)

If you bypass the UI and hit the API directly, blocked. If you grab a key while on STARTER, downgrade, and try to call it, blocked. Security can't sit in one place. EP.06 and EP.07 taught me that.

UI is a new tab in Settings. Issue API key, list issued keys, revoke. Key is shown once. Afterwards only the last 4 chars. That's the GitHub Personal Access Token pattern.

Marketing got an MCP demo section on the landing page and a guide at /docs/mcp in both languages. Claude Desktop config JSON, example conversations, issuance walkthrough. Ship without marketing and nobody knows it exists.

Day 3 (4/30) — monthly magazine

Day 3 — Magazine page 1 (Wrap, sample data) / GoCodeLab

April 30 — monthly magazine. Phases 1-7 from above, all in one day. It worked because the magazine doesn't generate new data; it organizes existing data. Revenue, downloads, reviews, keywords — already there. Aggregate, summarize with AI, render as cards, email it.

Phases 1-3 were the data pipeline. Add a magazine language setting, build the monthly aggregation, generate the body with Claude. This is where currency conversion came in for the first time. KRW and USD revenue mixed; if magazine display currency is KRW, USD has to be converted. Exchange rate cached at the 1st-of-month value. Plus subscription deduplication — same payment recorded twice in some edge cases.

Phases 4-7 were the output. Four card components — key metrics, trend chart, review highlights, next-month suggestions. Magazine page render. Email send via Resend with all four cards inline. CLI test tool to preview an arbitrary month.

May 1 single-shot test cron

The real cron runs at 5am KST on the 1st of each month. But I shipped on the 30th and couldn't wait until the 1st to verify. So I added a one-time cron that runs only on May 1st, sending myself the magazine in both Korean and English. After verification, only the regular monthly cron stays.

The magazine is data aggregation plus auto-send, but to a user it's just "an email shows up on the 1st." The four cards inside, the FX handling, the dedup — all invisible. Time goes into invisible details. EP.04 was the first time I felt this with FeedMission. Going from MVP to product takes longer than the MVP itself.

Things that snuck in

Three things crept in around the major work.

One — auto-recovery for paid-but-not-signed-up edge case. Sometimes payment goes through before signup completes. Used to be manual. Built a PendingSubscription model — store payment temporarily, match on signup, auto-activate. I knew about this case from EP.07 but had pushed it off.

Two — VAT/tax disclaimer near pricing. Tiny addition on the Pricing page. Skipping it means post-purchase emails asking "why did the price go up?"

Three — Korean translations of 9 English posts. Marketing blog had been English-first, but Korean users need Korean. Translated 9. Plus fixed Korean detection by reading the entire navigator.languages array — some browsers don't put ko-KR first.

These slip in between major work. One hour at a time. "Doing one thing at a time" is a fantasy; in reality, small things move alongside the big ones.

Retrospective — what really made it work

Reasons three in three days worked:

One — no new stack. Next.js + Supabase + Vercel + Prisma + Resend. All running since EP.02. No learning tax. MCP I'd already done in EP.15, so the pattern was familiar.

Two — small phases. Each phase finishes in 30 minutes to 2 hours. That keeps the prompt to Claude small and the verification fast. "Build a magazine system" becomes "write a function that generates magazine body via Claude. Input is this object, output is markdown."

Three — verify every phase. Don't run end to end and pray. EP.04 was the lesson: 52-minute MVP, then 6 more days of work. Fast generation isn't fast completion. Fast verification is fast completion.

Four — marketing in the same loop. Usually you build the feature, then make marketing pages, then more days disappear. This time Pricing/Landing/Blog ko·en were folded into the feature task list. Shipping = feature + marketing + docs. That's a real ship.

Coming next

How keyword search actually works, the MCP server architecture, the magazine data pipeline — each is its own deep-dive. EP.22 onward will go into one at a time. This post is just the record of how I ran three at once.

That's how the last week of April ended. May 1, 5am KST — the magazine sends itself for the first time. If that goes through, it's truly shipped.

FAQ

Q. Did you really build three features at the same time?

Not literally at the same time. I finished one major feature per day, and inside each feature I sliced things into phases that ran in order. Concurrency here means three week-long projects landing in the same week, not two hands typing two features.

Q. How did you build the MCP server?

Stdio server on @modelcontextprotocol/sdk. The hard part was auth and gating. Users get an API key from the Settings UI, and FREE plan key issuance is blocked at the API layer too — defense in depth. UI gate plus server gate.

Q. How do you slice phases?

Independently runnable units. For the magazine, phases 1-3 were the data pipeline and 4-7 were rendering, email, and CLI. Each phase ends with a commit and a quick check. I never run end to end before validating an intermediate output.

Q. Is Claude doing all of this?

No. I write the requirements, define inputs and outputs per phase, throw the implementation to Claude, verify, and move on. The speedup isn't code generation — it's the entire decision loop. Vague requirements produce vague code.

Supabase RLS — 5 Common Mistakes I Broke and Fixed Myself

LazyDev_OH — Thu, 30 Apr 2026 04:53:33 +0000

I had RLS enabled on a Supabase project and data still leaked. A single anon API key read another user's entire notes table. No error message. The problem was that I'd only configured half of it. It took two hours to find what was missing.

RLS (Row Level Security) is PostgreSQL's row-level security feature. The simple way to picture it: a lock on every row of a table. Supabase ships it by default, but if the setup is half-done, it gets quietly broken. This is the 5 mistake patterns I found while reproducing real attack scenarios myself.

Block these five and you stop most data leaks. The difference is one line of code, one policy.

Quick Look

Mistake 1 — RLS itself wasn't enabled → table fully public. ALTER TABLE ... ENABLE ROW LEVEL SECURITY required
Mistake 2 — RLS on, no policies → returns 0 rows (silent failure). At least 1 policy required
Mistake 3 — auth.uid() called directly → re-runs per row, slow. Replace with (SELECT auth.uid()) pattern
Mistake 4 — UPDATE WITH CHECK missing → user_id can be tampered with. USING + WITH CHECK together always
Mistake 5 — INSERT with no role specified → anon can write. TO authenticated must be explicit
Bonus — service_role key exposed to client → RLS fully bypassed. Isolate to server-only env vars

What RLS Is — Why Mistakes Happen

RLS is PostgreSQL's row-level access control. Unlike GRANT, which controls read/write at the whole-table level, RLS attaches a condition to each row so only specific rows can be seen. The "you can only see your own data" rule is enforced at the DB layer, server-side. No matter how sloppy the app code is, the DB layer blocks access.

Supabase Auth puts the logged-in user's UUID into a JWT token and passes it along. Calling auth.uid() inside an RLS policy retrieves that UUID. Compare it to the table's user_id column to restrict access to your own rows. Break that link and data leaks anywhere.

Supabase has three roles. anon is the anonymous user accessing without login. authenticated is a user logged in via Supabase Auth. service_role is an admin key that bypasses RLS. If a policy doesn't specify a role, it applies to all three. Not knowing this means anon users become subject to the policy and end up with unintended access.

Why do mistakes happen so often? Because RLS setup is split across stages. First you enable RLS on the table, then create policies, then specify roles and conditions inside each policy. Drop any of these and the table is silently breached or silently locked. No error message — that makes it harder to find.

Mistake 1 — RLS Itself Wasn't Enabled

When you create a new table in Supabase, RLS is off by default. CREATE TABLE alone makes the entire table queryable with the anon API key. The Dashboard Table Editor shows a "RLS disabled" warning, but it gets ignored often. Deploy in this state and anyone can read the table.

I tested this directly. A curl with the anon key returned all the data as-is. No authentication, content field exposed too. One missing line of RLS does it. Some devs turn RLS off during development for convenience, but it must be on before deploy.

The safest pattern is to put the ENABLE line right next to CREATE TABLE in migration files.

-- Vulnerable: no RLS → fully public
CREATE TABLE notes (
  id      UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  user_id UUID,
  content TEXT
);

-- Fix: run immediately after CREATE TABLE
ALTER TABLE notes ENABLE ROW LEVEL SECURITY;

-- Find all tables with RLS off (result should be 0 rows)
SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public' AND rowsecurity = false;

I made a query to find tables with RLS off. Adding this query to a CI/CD pipeline catches it automatically before deploy.

Mistake 2 — RLS Enabled but No Policies

Sometimes you enable RLS and no data shows up at all. No error. Just an empty array []. At first I couldn't tell whether it was a data bug or a security setup issue. After staring at the wrong query for a while, I finally realized there were no policies.

If RLS is enabled and zero policies exist, PostgreSQL blocks all access by default. This is called implicit deny. It returns 0 rows with no error message, so it looks like a bug. You need at least one allow policy for data to show up.

The default (PERMISSIVE) policies combine with OR when there are multiple on the same operation. Passing one is enough for access. RESTRICTIVE policies combine with AND and must all pass. Most cases use PERMISSIVE; use RESTRICTIVE only when you need additional restrictions.

-- Vulnerable: RLS on, no policies → returns 0 rows (silent failure)
ALTER TABLE notes ENABLE ROW LEVEL SECURITY;
-- No policies → all blocked, returns [] with no error

-- Correct: RLS + policy together
ALTER TABLE notes ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users see own notes"
  ON notes FOR SELECT TO authenticated
  USING ((SELECT auth.uid()) = user_id);

-- List policies on the current table
SELECT policyname, cmd, roles, qual
FROM pg_policies
WHERE tablename = 'notes';

Mistake 3 — auth.uid() Called Directly

When writing policies, many people put auth.uid() directly in the USING clause. It works. But there's a performance trap. This pattern calls auth.uid() once per row of the table.

10,000 rows means 10,000 auth.uid() calls. Wrap it in a subquery as (SELECT auth.uid()) and it runs once per query. The Supabase official docs recommend this pattern. The bigger the table, the wider the gap.

I compared the two with EXPLAIN ANALYZE. On a 50,000-row table, the direct call did a Seq Scan with 50,000 function executions. The (SELECT auth.uid()) version had 1 function execution and used an index scan. Query time differed by more than 4x.

-- Slow: re-calls auth.uid() per row
CREATE POLICY "slow policy"
  ON notes FOR SELECT TO authenticated
  USING (auth.uid() = user_id);

-- Fast: called once per query (recommended)
CREATE POLICY "fast policy"
  ON notes FOR SELECT TO authenticated
  USING ((SELECT auth.uid()) = user_id);

-- Replace existing policy
DROP POLICY IF EXISTS "slow policy" ON notes;
CREATE POLICY "fast policy"
  ON notes FOR SELECT TO authenticated
  USING ((SELECT auth.uid()) = user_id);

-- Add user_id index (if missing, add it)
CREATE INDEX IF NOT EXISTS notes_user_id_idx ON notes(user_id);

Mistake 4 — UPDATE WITH CHECK Missing

UPDATE policies have two clauses: USING and WITH CHECK. USING applies when picking which rows to modify. WITH CHECK validates that the post-modification result still satisfies the condition. Drop WITH CHECK and a row's ownership can be transferred to another user.

The scenario is UPDATE-ing my note's user_id to another user's UUID. With USING only, the pre-modification row is mine, so the condition passes. With no post-modification check, it saves as-is. My note is now owned by another user.

This attack is real and reproducible. From the JavaScript client, send .update({ user_id: 'other-user-uuid' }). With a USING-only policy, the request succeeds. The target then SELECTs their own data and gets the tampered note. Data integrity broken.

-- Vulnerable: no WITH CHECK → user_id can be tampered
CREATE POLICY "update own notes (vulnerable)"
  ON notes FOR UPDATE TO authenticated
  USING ((SELECT auth.uid()) = user_id);

-- Correct: USING + WITH CHECK both specified
CREATE POLICY "update own notes"
  ON notes FOR UPDATE TO authenticated
  USING      ((SELECT auth.uid()) = user_id)
  WITH CHECK ((SELECT auth.uid()) = user_id);

UPDATE policies must always include both USING and WITH CHECK. Even if the two conditions are identical expressions, both must be specified. PostgreSQL's docs explicitly state this behavior.

Mistake 5 — INSERT Policy with No Role Specified

If an INSERT policy doesn't include a TO clause, PostgreSQL applies the policy to all roles by default. That includes anon. If WITH CHECK is loose, data can be written without login.

Especially when WITH CHECK (true) is used as a fully permissive condition with no role specified, anyone can INSERT. Spam data piles up and the table grows fast. Just specifying TO authenticated blocks it.

Even WITH CHECK (auth.uid() = user_id) isn't fully safe. In the anon role, auth.uid() returns NULL. NULL = UUID comparison is FALSE, so it looks blocked. But if user_id has no NOT NULL constraint and the client sends user_id as NULL, you get a NULL = NULL comparison. Depending on DB version or settings, that can pass.

-- Vulnerable: no role + loose condition → anon can INSERT
CREATE POLICY "insert notes (vulnerable)"
  ON notes FOR INSERT
  WITH CHECK (true);

-- Incomplete: NULL comparison may accidentally pass
CREATE POLICY "insert notes (incomplete)"
  ON notes FOR INSERT
  WITH CHECK (auth.uid() = user_id);
-- auth.uid() is NULL in anon → NULL = NULL comparison risk

-- Correct: TO authenticated + ownership check
CREATE POLICY "insert own notes"
  ON notes FOR INSERT TO authenticated
  WITH CHECK ((SELECT auth.uid()) = user_id);

The principle is to not depend on accidental condition pass-through. Specifying TO authenticated blocks anon-role requests before policy evaluation. Specifying the role makes intent explicit and prevents unexpected bugs.

Bonus — service_role Key in the Client

The service_role key bypasses RLS. Requests with this key can access every row. Put this key in a browser or mobile app and the entire RLS setup becomes meaningless. Anyone can open DevTools, extract the key, and access all data.

It must be managed only as a server-side environment variable. In Next.js terms, manage it as a server-side variable without the NEXT_PUBLIC_ prefix. The client should only get the anon key. Any name like NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY in code must be fixed immediately.

If the key is already exposed, rotate it immediately. Project Settings → API → API Keys. The old key expires the moment a new one is issued. Same applies if the key was committed to GitHub. Even in git history, rotate immediately.

The recommended Next.js pattern is to split the Supabase client into two. One for the browser (anon key) and one for the server (service_role key), each created separately. createBrowserClient and createServerClient handle that role.

Key	Where	RLS	Public?
`anon`	browser, app client	Applied	Safe to expose
`service_role`	server-only (Edge Functions, API Routes)	Bypassed	Never expose

Real-World Scenario — Full RLS Setup for a Multi-User Notes App

I built the full CRUD-protected RLS setup for a notes app from scratch. SELECT, INSERT, UPDATE, DELETE — all four needed. The structure ends up with 4 policies on one table.

Order of setup matters. Run as: create table → enable RLS → policies. Naming policies clearly with intent helps when debugging later. "notes: select own" — table name + operation + target — is readable even six months later.

Skip the DELETE policy and other users can delete your notes. DELETE also needs a USING condition. SELECT and DELETE need only USING, INSERT needs only WITH CHECK, UPDATE needs both.

-- Full RLS setup example for a multi-user notes app

CREATE TABLE notes (
  id         UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  user_id    UUID REFERENCES auth.users(id) NOT NULL,
  content    TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

ALTER TABLE notes ENABLE ROW LEVEL SECURITY;

CREATE POLICY "notes: select own"
  ON notes FOR SELECT TO authenticated
  USING ((SELECT auth.uid()) = user_id);

CREATE POLICY "notes: insert own"
  ON notes FOR INSERT TO authenticated
  WITH CHECK ((SELECT auth.uid()) = user_id);

CREATE POLICY "notes: update own"
  ON notes FOR UPDATE TO authenticated
  USING      ((SELECT auth.uid()) = user_id)
  WITH CHECK ((SELECT auth.uid()) = user_id);

CREATE POLICY "notes: delete own"
  ON notes FOR DELETE TO authenticated
  USING ((SELECT auth.uid()) = user_id);

-- Index that directly affects RLS performance
CREATE INDEX notes_user_id_idx ON notes(user_id);

After setup I tested three scenarios. Do my notes show up under my UUID? Are my notes hidden under a different UUID? Does the anon key see nothing? All three behaved as expected.

Mixed Public/Private Posts

For blog-like data where public and private posts share a table with an is_public column. Two PERMISSIVE policies combine with OR — anon users pass only the public post policy, authenticated users pass either the public post policy or the own-post policy.

ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

-- Policy 1: public posts readable by anyone (including anon)
CREATE POLICY "posts: select public"
  ON posts FOR SELECT TO anon, authenticated
  USING (is_public = true);

-- Policy 2: own posts readable regardless of public/private status
CREATE POLICY "posts: select own"
  ON posts FOR SELECT TO authenticated
  USING ((SELECT auth.uid()) = user_id);

-- Two policies combined with OR:
-- anon: sees only public posts
-- owner: sees all own posts (public + private)
-- other users: see only that user's public posts

RLS Policy Checklist

Mistake Pattern	Symptom	Risk Level	Fix
RLS not enabled	All data exposed	Critical	`ENABLE ROW LEVEL SECURITY`
No policies	Returns 0 rows (no error)	High	Add at least 1 SELECT policy
`auth.uid()` called directly	Slow queries	Medium	Replace with `(SELECT auth.uid())` pattern
UPDATE WITH CHECK missing	user_id can be tampered	High	Add WITH CHECK
INSERT with no role	anon can write	High	Specify `TO authenticated`
service_role exposed to client	RLS completely bypassed	Critical	Move to server-only env var

Operation	USING	WITH CHECK	Role (TO)
SELECT	Required	Not required	authenticated (anon too for public content)
INSERT	Not required	Required	authenticated
UPDATE	Required	Required (often missed)	authenticated
DELETE	Required	Not required	authenticated

Adding RLS to an Existing Project

Order matters when adding RLS late. Either create the policies before enabling RLS, or wrap them in a transaction and run them together. Enabling RLS alone without policies puts the service in a 0-row state, even if only briefly. Wrapping with BEGIN/COMMIT applies it atomically.

-- Migrating an existing project: wrap RLS + policies in a transaction
BEGIN;

ALTER TABLE notes ENABLE ROW LEVEL SECURITY;

CREATE POLICY "notes: select own" ON notes
  FOR SELECT TO authenticated USING ((SELECT auth.uid()) = user_id);

CREATE POLICY "notes: insert own" ON notes
  FOR INSERT TO authenticated WITH CHECK ((SELECT auth.uid()) = user_id);

CREATE POLICY "notes: update own" ON notes
  FOR UPDATE TO authenticated
  USING ((SELECT auth.uid()) = user_id)
  WITH CHECK ((SELECT auth.uid()) = user_id);

CREATE POLICY "notes: delete own" ON notes
  FOR DELETE TO authenticated USING ((SELECT auth.uid()) = user_id);

COMMIT;
-- RLS enablement and policy creation applied atomically

How to Properly Verify RLS

After creating policies, actual testing is necessary. The Supabase SQL Editor lets you set the role and JWT claims directly.

Two things must be confirmed. Does my data appear with my UUID? Does my data not appear with another UUID? The second is more important. In many cases own data shows up fine, but blocking access to others' data is missing.

-- Testing RLS in Supabase SQL Editor

-- 1. Test authenticated role with my UUID
SET LOCAL role TO 'authenticated';
SET LOCAL "request.jwt.claims" TO '{"sub": "my-user-uuid-here"}';
SELECT * FROM notes;
-- Only my notes should appear

-- 2. Access with another UUID (should return 0 rows)
SET LOCAL "request.jwt.claims" TO '{"sub": "other-user-uuid"}';
SELECT * FROM notes;
-- Should return 0 rows

-- 3. Test anon role
SET LOCAL role TO 'anon';
SELECT * FROM notes;
-- Should return 0 rows

Firing a curl with the anon key directly is also essential. Hitting the actual API endpoint, not the SQL Editor, gives the real picture.

# Direct API call test with anon key
curl 'https://<project-ref>.supabase.co/rest/v1/notes?select=*' \
  -H 'apikey: <anon-key>' \
  -H 'Authorization: Bearer <anon-key>'

# Result should be []
# If data is visible, RLS configuration error

Testing with the JavaScript client is also possible. Log in a test account with supabase.auth.signInWithPassword and SELECT a row that belongs to a different account's UUID. An empty array result is correct. This approach has the advantage of testing through the exact same path as the actual app code.

Closing

Half-configured RLS gets breached. Enabling it matters, and writing policies correctly matters too. The most common of the five mistakes are not enabling RLS and missing policies. Fixing just those two prevents most data leaks.

Run through the checklist above every time a new table is created. It does not have to be perfect. One SELECT policy and one INSERT policy with WITH CHECK is enough to cover the basics. The DELETE policy and UPDATE WITH CHECK can be added as the next step.

Adding service_role key management to the code review checklist is a good idea. If any NEXT_PUBLIC_-prefixed environment variable holds a service_role key, move it immediately. RLS configuration is never a one-time task.

Official sources

How to Actually Write a CLAUDE.md — A Solo Indie Dev's Guide From Running 16 Apps

LazyDev_OH — Thu, 30 Apr 2026 04:52:56 +0000

Every time I opened a new session, I was repeating the same things. "Reply in Korean." "Use the App Router, not Pages Router." "Explain in one line before throwing code at me." I'm running 16 apps as a solo indie, and every session felt like a new-hire interview.

I put up with this for a month, then drew a conclusion. Stop teaching inside the session — pin it outside the session. That's what CLAUDE.md does. It's an internal wiki you hand to the AI.

This is my guide to writing CLAUDE.md, distilled from a year of running it across 16 iOS apps and SaaS projects as a one-person operation. Bottom line: written well, it eliminates 30 minutes of context-setting per session. Written poorly, it gets ignored.

TL;DR

CLAUDE.md is a markdown file Claude Code auto-injects at session start. It's read from two locations: global and project.
A well-written 80-line page kills 30 minutes of context-setting per session.
The 5 core patterns: identity / tone / prohibitions / workflow / danger. Split into five zones.
"Use App Router" is weak. "No Pages Router → use App Router" is strong. Pin prohibition + alternative on one line.
Cap length at 60–300 lines. Karpathy's public CLAUDE.md is 65 lines. Past that, priorities collapse.
Don't mix rules with different scopes (Web vs iOS) in one global file.
Use @import to break up long rule files. Past 200 lines in one file, the model loses priority signal.

What CLAUDE.md actually is

CLAUDE.md is a markdown file Anthropic's Claude Code auto-injects when work starts. It's read from two locations.

~/.claude/CLAUDE.md is the global rules file. It applies to every project. This is where I pin my identity, my tone preferences, and my safety rules. <project-root>/CLAUDE.md is the project rules file. It only applies inside that folder. This is where I pin codebase structure, conventions, and domain knowledge.

I use both. Identity and tone go global. Codebase-specific structure and risks go in the project file. Combined, every session starts already knowing me.

The analogy: instead of giving every new hire a fresh company tour, you hand them a wiki link. If the wiki is good, they're productive on day one. If it's not, they keep walking over to the founder's desk to ask questions.

How it differs from other config files

File	Tool	Location	How it applies
`CLAUDE.md`	Claude Code	global + project	auto-injected at session start
`.cursorrules`	Cursor (legacy)	project root	injected as system prompt every chat
`.cursor/rules/*.mdc`	Cursor (new)	folder inside project	conditional injection via globs
`AGENTS.md`	Codex CLI etc.	project root	injected at session start
`GEMINI.md`	Gemini CLI	global + project	nearly identical to CLAUDE.md

The two I use most are CLAUDE.md and .cursor/rules/*.mdc. I do inline edits in Cursor and run bigger jobs in Claude Code, so the same rules end up scattered across two files. I covered how to keep that in sync separately in Cursor Rules vs CLAUDE.md compared.

The short version: CLAUDE.md is always in. .cursor/rules/*.mdc can be conditionally injected via globs. So the token cost of CLAUDE.md is higher. But it's simpler — one file to look at.

How to split global vs project

My rule is simple. If it doesn't change with the human, global. If it changes per codebase, project.

Global gets the fact that I'm a solo dev, the "reply in Korean" tone, and the "never touch .env" safety rule. These are the same whether I'm building a SaaS or an iOS app. Project gets that codebase's folder structure, conventions, and domain vocabulary. The MVVM layout of a SwiftUI project and the App Router layout of a Next.js project have no reason to live in the same file.

Pin zone	Global	Project
My identity	O	X
Reply language / tone	O	X
Safety / prohibition rules	O	reinforce
High-level stack	O	X
Folder structure	X	O
Domain vocabulary	X	O
Frequently used npm scripts	X	O

Without this split, the global file bloats. My global is 80 lines and I never let it grow past that. There was a phase where it ballooned to 200 lines, and at some point the model stopped picking up priorities. I cut it back to 80 and rule adherence climbed again.

For reference, Andrej Karpathy's public CLAUDE.md is 65 lines. Operations-heavy companies like HumanLayer recommend keeping global under 60 lines and splitting overflow into agent_docs/. 80–300 lines is a safe ceiling.

Don't mix differently-scoped rules in one global file. I keep only my reply language and the "solo indie" identity in global. Web code conventions and iOS code conventions both moved into their respective project CLAUDE.md files. If both stacks' rules sit in the global file, iOS rules get pinned into the context even during Web work, and the model gets confused.

Pattern 1 — Pin identity and stack on the first line

The first line should say who you are and what you use. The most common AI question is "what stack are you on?" Answer it ahead of time and it doesn't ask.

My first line: "Solo indie dev (iOS + Web SaaS)". That single line locks in a lot of assumptions. Say "build me a sign-up flow" and Claude automatically assumes a one-person operation. It doesn't recommend pricey services like Auth0.

For the stack, a noun list works best. "Supabase, Vercel, Tailwind." Now PostgreSQL, edge functions, and App Router are all default assumptions. It stops asking "is this Firebase?".

One caveat. Don't pin versions. If you write "Next.js 16", you'll forget to update it when 17 ships. Just write "Next.js" and let the model assume current.

Pattern 2 — Pin tone rules with detail

This is where I got the most leverage. Everyone writes "reply in Korean", but what comes after that matters more.

One important distinction. Pinning tone is not the same as pinning code style. Indentation, semicolons, quote style — that's ESLint and Prettier territory, not CLAUDE.md territory. Telling an LLM to enforce linter rules just burns tokens with weak results. Tone-pinning should stay limited to actually-human stuff: reply language, first-person, greeting patterns, banned words.

I pinned "Keep explanations concise, skip unnecessary preamble." That one line killed translated-from-English greetings like "Of course! Great question." I also pinned "Explain in one line before changing code." So instead of dumping code, it now writes "I'm going to extract this function — for reuse" first.

Tone responds to detail. "Be friendly" is vague, but "no emojis" is concrete. Tone is the easy thing to forget. Code violations are obvious; tone violations sneak past you for a while. That's exactly why pinning matters.

Pattern 3 — Write coding rules as "prohibition + alternative"

This one I learned the hard way. "Use the App Router" is weak. "No Pages Router" is stronger. But the truly strong form combines both. "No Pages Router → use App Router", on a single line.

There's a reason the difference is large. Training data has way more Pages Router examples than App Router. If you only say "use App Router", the model defaults to majority-class Pages Router under pressure. If you pin "No Pages Router", that phrase enters the context and the model token-by-token avoids it. But pure negative rules aren't enough — sometimes the model halts at "okay then what" and slips into a different legacy pattern. So always attach the alternative right after the prohibition. Anthropic's official guidance also recommends "constructive rules over purely negative ones" for consistency.

My global has five negative + alternative rules: "No Pages Router → App Router", "No class components → functional components", "No completion handlers → async/await" (iOS), "No git push --force", and "Minimize separate CSS files → Tailwind utilities first". Each one was added after I got bitten.

Negative rules also protect me from myself. At 3 a.m., Pages Router can start to look faster. Claude steps in: "this is Pages Router, but CLAUDE.md prohibits it." It's a pin for future me.

Pattern 4 — Write workflow as steps

"Plan → approve → implement → verify." I pinned that 4-step flow globally. Without it, "build me a sign-up flow" will get you 5 files dumped at once.

My pinned phrasing: "For complex tasks, present a plan before coding" and "Wait for plan approval before starting implementation." With those two lines, Claude now writes "1) add the route, 2) add the Supabase table, 3) UI. Should I proceed?" first.

Verification is pinned too. "After writing code, run the build/typecheck if possible." That single line means it doesn't drop code and walk away — it builds its own code, sees the type error, and fixes it.

I also pin the commands I use frequently:

# Commands I use

## Web (Next.js + Supabase)
npm run dev          # dev server (localhost:3000)
npm run build        # production build
npm run typecheck    # TypeScript type check
npx supabase db push # apply Supabase migration

## iOS (Xcode + Swift)
xcodebuild -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 15' build

With this pinned, Claude doesn't guess which npm script to run. The point is to pre-authorize what the AI can do autonomously. When permissions are vague, it goes conservative and keeps asking. Pinned permissions, it just goes.

Pattern 5 — Pin dangers explicitly

The last pattern matters most. Pin the things the AI must never do, separately.

I have three danger pins. "Never read or modify .env files", "Always ask before modifying production files", "No git push --force". These are the worst-case patterns for a solo dev.

The .env rule was added after I got burned directly. Mid-debug, Claude printed a chunk of .env and it ended up in the session log. It was a dev key, thankfully — if it had been production I'd have had to rotate everything. Pinned it globally the next day.

The "ask before production" rule was added after I almost shipped a production migration via a two-line PR. Solo operations often skip staging. "Obviously dangerous" isn't enough — you need to pin "this is dangerous" explicitly.

Use @import to break up long rules

When rules cross 80 lines, I switch to @import. Claude Code supports this officially. Write @docs/conventions.md inside CLAUDE.md and it pulls that file in and merges it.

# Project conventions

@docs/db-schema.md
@docs/api-conventions.md
@docs/danger-rules.md

## Extra rules
- Billing-related code can only be modified inside `lib/billing/`
- Supabase RLS policies must only change via migrations

Two upsides. First, splitting rules by topic looks better on GitHub. Second, when multiple projects share rules, I only edit one file. My two SaaS projects both import docs/danger-rules.md.

The downside: imported files still hit the context. This isn't a token-saving feature. Use it for organization only.

A small script to keep CLAUDE.md updated

At the end of a session, I tell Claude "if you learned a new rule today, add it to global." But I forget to type that every time, so I keep a tiny helper around.

#!/usr/bin/env bash
# scripts/append-claude-rule.sh — safely append a new rule to ~/.claude/CLAUDE.md

set -euo pipefail

CLAUDE_MD="${HOME}/.claude/CLAUDE.md"
TODAY=$(date +%Y-%m-%d)

if [ -z "${1:-}" ]; then
  echo "Usage: ./append-claude-rule.sh \"new rule on one line\""
  exit 1
fi

# Auto-backup, then append
cp "$CLAUDE_MD" "${CLAUDE_MD}.bak.${TODAY}"
printf "\n- %s  # added %s\n" "$1" "$TODAY" >> "$CLAUDE_MD"

echo "added → $CLAUDE_MD"
echo "backup → ${CLAUDE_MD}.bak.${TODAY}"

No more opening vim, and the auto-backup means if I delete something accidentally I can restore it. Lower the friction of pinning. The closer friction gets to zero, the more pins accumulate.

Limitations — what pinning can't fix

CLAUDE.md isn't magic. After a year of running it, three real limitations:

First, long contexts start to override it. If you code for hours in one session, the accumulated context outweighs CLAUDE.md. Late in the session it might suddenly answer in English or suggest Pages Router. When this happens, just open a new session.

Second, write too much and the details get drowned. My global is 80 lines. Early on it ballooned to 200 and the longer the rules got, the worse the model's prioritization became. Even human employees don't follow 200 rules.

Third, if I break my own rule, the AI won't stop me. If I explicitly say "do this with Pages Router", Claude does it. Pinning sets defaults, not guardrails on the human. At the end of the day, controlling myself is still my job.

What to pin first, by situation

Situation	First pin	Why
Writing CLAUDE.md for the first time	reply language + identity	effect lands on the very first response
You've nagged the same thing 3+ times	that nag itself	you already know it's a rule
Right after an incident	danger rules	pin it or it happens again
Just joined a project	folder structure	stop file-location guessing
Blog/docs writing	tone + banned words	output tone stabilizes immediately

This single table is a year's worth of trial-and-error. The two highest-leverage pins were always the top two: "reply in Korean" and "the rule I've now repeated three times". The latter is the strongest one.

Wrapping up

CLAUDE.md takes 5 minutes to start. 3 lines of identity, 3 lines of tone, 5 lines of coding rules, 4 lines of workflow, 3 lines of danger. An 18-line v1 is enough. Add what bites you over the next month. A year in, 80% of how you work will be pinned.

One tip when you write the first version. Don't just freestyle it — do a quick retrospective first. When I wrote my v1, I first listed "the 5 things I nagged Claude about most this past week." That list became my global rules verbatim. Whatever I keep telling it is exactly what should be pinned first.

CLAUDE.md is the wiki you hand to the AI. Written well, it works like a coworker from day one. Written poorly, you remain founder, new hire, and everything in between. Running 16 apps as a solo, the latter doesn't scale. Better to start today.

Official sources

Cursor Rules vs CLAUDE.md — A Deep Dive into Context Injection Patterns for AI Coding Tools

LazyDev_OH — Thu, 30 Apr 2026 04:52:50 +0000

I run Cursor and Claude Code together on the same projects. Both tools see the same codebase, but they inject rules in fundamentally different ways. Early on I didn't know this and copy-pasted the same markdown to both sides. One side followed it well, the other slowly forgot. After a month of confusion I landed on the conclusion that "these two are different species when it comes to context injection."

This post unpacks that difference from a solo dev's perspective. On the surface they're both just one markdown file, but crack them open and Cursor Rules has four modes, while CLAUDE.md has three layers plus an import system. Use them without knowing this and the same rule ends up injected twice per message eating tokens, or the file exists but the model never reads it.

I run 16 iOS apps and a few SaaS products as a solo indie. Mixing two or more tools is daily life for me. I hate writing the same rule twice, and I hate even more spending time debugging rules that don't get followed. That's the motivation for this post — how AI coding tool context injection patterns differ, how to split things when running both, and five common traps.

TL;DR

Cursor Rules is injected per inline edit. CLAUDE.md is loaded once at session start, with child-dir files added on demand.
Cursor's .mdc has 4 modes (Always Apply / Apply Intelligently / Apply to Specific Files / Apply Manually). CLAUDE.md has 5 locations (~/.claude/, project root, CLAUDE.local.md, parent dirs, child dirs) + @import.
For the same rule across both, short imperative for Cursor and descriptive context for Claude makes them stick.
Never commit globals to git. Project CLAUDE.md gets committed, CLAUDE.local.md goes in gitignore.
The 2026 trend is AGENTS.md as the single source of truth + Cursor/Claude/Codex/Copilot all importing from it.
When rules don't stick, it's almost always either "the file wasn't actually read" or "two rules contradict each other."

At a glance

Item	Cursor Rules	CLAUDE.md
Location	`.cursor/rules/*.mdc` or `.cursorrules`	`~/.claude/CLAUDE.md` + project root
Injection timing	Per inline edit / chat	Once at session start
Splitting	File-level + conditional `globs`	Chained via `@import` syntax
Modes	Always / Auto / Agent / Manual	Always injected (only layered)
Global area	App settings screen (no text file)	Separate markdown file

Why Cursor Rules and CLAUDE.md are different species

Surface-level, both are markdown. But the tools' usage patterns differ. Cursor's main mode is inline edit. You fix short blocks of code on the spot. Claude Code's main mode is the agent session. Once you start, it autonomously runs dozens of tool calls. That difference is reflected directly in how each rule file is structured.

Cursor builds a fresh system prompt for every inline edit request. So it injects the rules every time. Token cost every time. That's why Cursor Rules works best with short, forceful imperatives. One-line rules like "use Tailwind only" or "App Router only" — the model re-reads them every request.

Claude Code sessions are long. Once you start, it carries the same system prompt all the way through. So CLAUDE.md works better with background context than short commands. Things like "this is why the codebase is structured this way," "here are the danger zones," "here's who I am" — descriptive prose. Material the model references when making its own judgment calls.

When I didn't know this and copy-pasted the same rules to both sides, Claude got annoyed by the imperative tone and started routing around the rules. Cursor was too long, so it only listened to the first 30 lines and skimmed the rest. Just splitting the tone alone visibly improved rule compliance on both tools.

The 4 modes of Cursor Rules

.cursor/rules/*.mdc files are markdown with frontmatter. The frontmatter field combination determines the mode. Early on I didn't read this and just slapped alwaysApply: true on everything, wasting all the efficiency.

---
description: SwiftUI iOS work rules
globs: "**/*.swift"
alwaysApply: false
---

- Swift 6, async/await
- Prefer @Observable macro, no ObservableObject
- No completion handlers
- Split long Views with ViewBuilder

Always mode (alwaysApply: true) is forcibly injected on every request. Same as the old .cursorrules file. I put danger rules here (no production touches, no force push). Only items where forgetting causes accidents.

Auto mode (alwaysApply: false + globs filled in) auto-injects only when globs match. The example above only injects when touching a .swift file. I split stack-specific conventions into this mode.

Agent-requested mode (only description filled, both globs and alwaysApply empty) lets the model decide whether to pull it in. If the description looks relevant, the model fetches it. I keep things like occasional code review checklists or migration procedures here.

Manual mode (just the name, all auto-triggers off) only loads when explicitly called via @rulename in chat. For templates I don't want forced but want to summon on demand.

After a year of running this, my settled ratio is Always 20%, Auto 60%, Agent 15%, Manual 5%. Stuff too much into Always and per-request token cost balloons while the model's attention drops.

CLAUDE.md's 3 layers and @import system

CLAUDE.md doesn't have modes — it has layers. It reads from three places. ~/.claude/CLAUDE.md (global), <project root>/CLAUDE.md (project), and CLAUDE.md inside subfolders. All three get pasted whole at the front of the system prompt at session start.

Global is my personal identity. Name, tone, my regular stack, hard-banned actions. My global is about 50 lines.

Project root is for that codebase only. Stack structure, folder conventions, danger zones. If something contradicts the global, this is where I explicitly override. For example if global says "TypeScript strict" but some legacy project says "any allowed for now," I write in the project CLAUDE.md: "override the global strict rule for this project."

Sub-directory applies only inside that folder. SwiftUI conventions go in apps/ios/CLAUDE.md, Next.js conventions in apps/web/CLAUDE.md. Works well for monorepos.

There's also @import syntax. Write @docs/conventions.md inside CLAUDE.md and it pulls that file in too. My project CLAUDE.md is about 50 lines and imports two files: @docs/stack.md and @docs/danger.md.

Context injection timing — every time vs once

This is the most important difference. Cursor and Claude inject rules at fundamentally different moments.

Cursor rebuilds the system prompt every request. Rules get injected every time. Token cost every time. Upside: add a new rule and the next request applies it instantly.

Claude Code reads once at session start. It carries the same system prompt until that session ends. Token cost is small thanks to prompt cache. Downside: changing a rule doesn't apply to the existing session. You need a new session for the new rule to land.

Add a rule in Cursor and the next inline edit picks it up. Same scenario in Claude requires /clear to reset the session, or opening a new conversation. I once spent 30 minutes confused about "why isn't it picking up the new rule" before I figured this out.

globs matching vs @import — file-splitting pattern

Cursor Rules splits by file via globs. Touch a .swift and only iOS rules come in; touch a .tsx and only Next.js rules come in. No noise in the model context.

.cursor/rules/
├── always-danger.mdc        # alwaysApply: true
├── nextjs-stack.mdc         # globs: "**/*.{tsx,ts}"
├── ios-swiftui.mdc          # globs: "**/*.swift"
├── tailwind.mdc             # globs: "**/*.{tsx,jsx,html}"
└── pr-template.mdc          # manual

CLAUDE.md splits via @import. The main file acts as the entrypoint and imported files trail along. Downside: no globs matching, so everything loads regardless of work context. Every import behaves like alwaysApply: true.

# Project: apsity

@docs/stack.md
@docs/conventions.md
@docs/danger.md

## Extra notes
- Add new routes under app/
- DB schema changes always via migration files

For Cursor I split fine by stack, for Claude I bundle into bigger chunks. Since everything loads on Claude anyway, fine-grained splitting is meaningless. But I never let an imported file go past 200 lines — model attention drops past that line.

Token cost and noise control

Stuffing too many rules in is the trap indie devs fall into most. I crammed 200 lines into a single page. The result was the model dutifully followed the first 30 lines and "is that even there?" the rest.

On Cursor this also hits as direct token cost. Rules go in every request, so a 200-line ruleset is 200 lines of tokens per inline edit. If I do 50 inline edits a day, that's 10,000 lines of tokens per day. Split with globs and usually only 30-50 lines load — 1/4 the tokens.

The rule-writing guide I've settled on has three parts:

Write in measurable form. "Write clean code" doesn't land — "split functions over 50 lines" does.
One rule per line, one command per rule.
Attach a short "why." Claude generalizes when it knows the reason.

Strategy for running both tools together

Area	Location	Tone	Example
Danger rules	Both	Short imperative	"no .env, no force push"
Stack conventions	Cursor (per glob)	Imperative	"Tailwind utils only, no styled-components"
Codebase background	Claude (CLAUDE.md)	Descriptive	"App Router migration done, new code goes under app/"
Personal identity	Claude global only	Descriptive	"solo indie, Korean, ship-fast first"
PR/review checklist	Cursor (manual)	Steps	"Call via @pr-template"

Only danger rules duplicate across both. Stack conventions go heavily on the Cursor side. Codebase background goes heavily on the Claude side. Personal identity only goes in Claude global.

Debugging order when rules don't stick

I debug "this rule isn't sticking" more often than I write new rules. Almost every case falls into these 4 steps.

Step 1, confirm the file actually got read. On Claude Code, in the first message of a session, ask "list 3 of the danger rules I put in CLAUDE.md." If the answer is accurate, it read it.

Step 2, recheck the rule mode. In Cursor, if alwaysApply: false and both globs and description are empty, that rule will never auto-inject. Always check the frontmatter first.

Step 3, check for rule contradictions. When global vs project, or .cursorrules vs .cursor/rules/*.mdc conflict, the model follows whichever is more strongly worded.

Step 4, check whether the rule is too abstract. "Write clean code" doesn't land. "Split functions over 50 lines" lands. Has to be measurable.

One more thing. Cursor's .cursorrules (old format) and .cursor/rules/*.mdc (new format) both apply when both exist. Keeping both around duplicates rules and confuses the model. Migrate and delete the old file immediately.

Security and git commit policy

Project-level files always get committed, globals never.

<project>/CLAUDE.md, .cursorrules, .cursor/rules/*.mdc are part of the codebase. New collaborators or future-me need the same rules. Don't put them in .gitignore.

The opposite for ~/.claude/CLAUDE.md, ~/.gemini/GEMINI.md and other globals — those are personal identity. Email, tone preferences, even names of apps I run. Pushing this to git causes accidents. I keep them in a separate private dotfiles repo.

Watch for secrets inside rule files. I once accidentally put a Supabase project ID in CLAUDE.md. After that I don't put env var names or identifier-style things in rule files. I stop at "env vars live in .env.local."

Real example — my SaaS setup

Project root CLAUDE.md (descriptive context):

# Project: apsity

## Stack
- Next.js 15 App Router, TypeScript strict
- Supabase (PostgreSQL + Auth + Storage)
- Vercel deploy, Tailwind v4

## Structural decisions
- Prefer Server Components, 'use client' only for interactions
- Data fetching: call Supabase directly from Server Components
- API routes only for webhooks and external calls
- Auth via RLS, no backend if-statements

@docs/danger.md
@docs/conventions.md

Same folder's .cursor/rules/nextjs-stack.mdc (imperative, auto via globs):

---
description: Next.js + TypeScript work rules
globs: "**/*.{ts,tsx}"
alwaysApply: false
---

- App Router only. Don't write Pages Router code.
- Minimize 'use client'. Branch at the top of the component tree.
- Tailwind utils only. No styled-components.
- No `as` casting. If unsure, unknown then narrow.
- Split functions over 50 lines.

And .cursor/rules/always-danger.mdc (every-request injection):

---
description: Danger zone guards
alwaysApply: true
---

- Confirm with user before editing supabase/migrations/.
- Never print production env vars.
- DB schema changes always via migration files.
- No git push --force.
- Never read or modify .env files.

Same ruleset, but Cursor gets short commands and Claude gets background + reasoning. They don't conflict.

AGENTS.md — the 2026 single-source-of-truth trend

Pinning the same rule in two files is obviously inefficient. So starting late 2025, AGENTS.md rose as a standard. OpenAI Codex defined it first, and in December 2025 it was donated to Linux Foundation/AAIF. As of 2026, Cursor, Claude Code, Codex CLI, GitHub Copilot, Devin, Windsurf, and Gemini CLI all read AGENTS.md.

My ops pattern got simpler. Keep AGENTS.md as the source of truth, then @AGENTS.md import via a single line in .cursor/rules/index.mdc, @AGENTS.md import in CLAUDE.md, same for other tools. Edit one file and every tool reflects it.

That said, Claude Code's global (~/.claude/CLAUDE.md) and Cursor's user rules (app settings screen) can't be sync'd outside the tool — personal identity, voice — so they stay out of the AGENTS.md source. The source holds project conventions, codebase rules, and danger rules only.

Wrap-up

Cursor Rules and CLAUDE.md look similar on the surface — both markdown — but inside they're entirely different systems. Cursor is short rulesets injected per inline edit; CLAUDE.md is descriptive context pinned at session level. When writing the same rule in both places, you have to match the tone too for both to listen.

My one-year conclusion is simple. Don't pin both files from the start — start with one tool, one file. When that file goes past 80 lines, then split via globs or @import. When you adopt the second tool, that's when you extract AGENTS.md as the source. Build everything up front and you'll just have rules that go unfollowed.

Official sources

This post is current as of 2026-04-30. Both Cursor and Claude Code update their rule systems quickly — six months out, this may need a recheck. The SaaS I run, apsity, is built for solo developers.

Teaching Claude to Play Tetris with 100 App Store Characters

LazyDev_OH — Wed, 15 Apr 2026 17:30:08 +0000

The App Store keyword field is exactly 100 characters. Commas only, no spaces, no duplicates. You need to pack 15–20 keywords inside.

I tried writing those by hand for a dozen apps. Every time I'd leave characters on the table — a rogue space after a comma, a singular/plural duplicate Apple would auto-match anyway. Manual packing is tedious enough that most indie developers just don't iterate on ASO.

So I built an AI that does it. This post is the actual implementation — prompts, JSON schemas, validation, and the gotchas that killed my first three attempts. I ship this in my ASO tool for iOS developers (Apsity), but the approach works for any tight-constraint text-generation problem.

The Constraints That Break Generic LLMs

When you ask any LLM "generate App Store keywords for my budget app," you get something like:

budget tracker, expense manager, spending analysis,
money manager, personal finance, bill tracker

Readable. Useless. Two characters wasted on every , (space after comma). Four characters wasted on personal finance because Apple auto-matches personal + finance separately. Total wasted: roughly 30% of your 100.

The rules that matter:

Exactly ≤100 characters (including commas)
Single comma separators, no spaces
No duplicate tokens (Apple ignores them anyway)
No singular+plural pairs (Apple auto-matches)
Shorter tokens > compound words (Apple combines them for you)
No competitor brand names (trademark rejection)
No category names, and no app, free, new, best, iPhone, iPad (Apple auto-indexes all of these)
Mix function + situation + alternative keywords

An LLM without these constraints spelled out won't enforce them. Generic "write keywords" prompts fail rules 1–4 consistently.

Why Claude Sonnet

I tested GPT-5, Gemini 2.0 Pro, and Claude Sonnet 4.6 on the same task. Three metrics:

Character compliance — stays under 100 chars without excess whitespace
JSON schema adherence — returns exactly the structured output I asked for
Edge case handling — catches duplicates, plural forms, category name leaks

Claude Sonnet won on all three, but the meaningful gap was edge case handling. When I explicitly said "no duplicates including singular/plural pairs," Claude filtered them out. The others listed budget and budgets and called it done — which is wrong, because Apple's algorithm auto-indexes plurals from the singular form anyway. A keyword duplicated across singular/plural just wastes characters.

I'm also passing a lot of context — competitor review snippets, current rankings, market-specific search trends. Sonnet 4.6's 1M-token context window handles it without trimming.

The Prompt Structure

The prompt is in three layers: system prompt (the rules), user prompt (the app context), and a JSON schema Claude must match.

// lib/keyword-generator.ts
import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

const SYSTEM_PROMPT = `
You are an ASO (App Store Optimization) keyword specialist.
Generate keywords for the app store "Keywords" field, which has
a STRICT 100-character limit. Characters include commas.

Rules (apply in order):
1. Total output length MUST be ≤100 characters
2. Use ONLY commas as separators, no spaces after commas
3. No duplicate tokens
4. No singular+plural pairs (Apple auto-matches both)
5. Prefer short atomic tokens over compound words
   (Apple combines A + B into "A B" automatically)
6. No competitor brand names (trademark violation)
7. No category names and no words Apple already indexes automatically:
   app, free, new, best, iPhone, iPad, or any category label
8. Blend three keyword types:
   - Function (what the app does)
   - Situation (when users need it)
   - Alternative (different names for the same thing)

Return JSON with this schema:
{
  "keywords": string[],         // individual tokens, no commas inside
  "joined": string,             // comma-joined, must be ≤100 chars
  "char_count": number,         // .length of "joined"
  "coverage_notes": string[]    // which search queries this covers
}
`;

type KeywordOutput = {
  keywords: string[];
  joined: string;
  char_count: number;
  coverage_notes: string[];
};

The JSON schema isn't just for structure. char_count forces Claude to count the output itself — models aren't great at counting, but self-reporting forces a pass where the model checks its own work.

Generating Keywords

async function generateKeywords(context: {
  app_name: string;
  description: string;
  competitors: string[];
  existing_keywords?: string[];
  target_market: string;
}): Promise<KeywordOutput> {
  const userPrompt = `
App: ${context.app_name}
Description: ${context.description}
Target market: ${context.target_market}
Competitor apps (do NOT use these names): ${context.competitors.join(", ")}
${context.existing_keywords ? `Currently underperforming keywords to replace: ${context.existing_keywords.join(", ")}` : ""}

Generate an optimal 100-character keyword field.
Before finalizing, count your characters and confirm it fits.
`;

  const response = await client.messages.create({
    model: "claude-sonnet-4-6",
    max_tokens: 1024,
    system: SYSTEM_PROMPT,
    messages: [{ role: "user", content: userPrompt }],
  });

  const text = response.content[0].type === "text"
    ? response.content[0].text
    : "";

  const match = text.match(/\{[\s\S]*\}/);
  if (!match) throw new Error("No JSON in response");

  return JSON.parse(match[0]) as KeywordOutput;
}

Straightforward Anthropic SDK call. Two things worth noting:

max_tokens: 1024 — keywords are short, so we don't need more. Capping reduces cost.
JSON extraction via regex — Claude sometimes wraps JSON in explanation text. Grabbing the first {...} block is more reliable than asking for raw JSON.

Validation Is Where Production Code Lives

Claude gets the constraints right ~85% of the time. Production code has to handle the other 15%.

// lib/validate-keywords.ts
import { z } from "zod";

const KeywordSchema = z.object({
  keywords: z.array(z.string()),
  joined: z.string(),
  char_count: z.number(),
  coverage_notes: z.array(z.string()),
});

export function validateKeywords(output: unknown): {
  ok: boolean;
  issues: string[];
  data?: KeywordOutput;
} {
  const parsed = KeywordSchema.safeParse(output);
  if (!parsed.success) {
    return { ok: false, issues: ["invalid JSON shape"] };
  }

  const issues: string[] = [];
  const { keywords, joined, char_count } = parsed.data;

  // 1. Length check
  if (joined.length > 100) {
    issues.push(`joined is ${joined.length} chars, exceeds 100`);
  }

  // 2. Trust but verify char_count
  if (joined.length !== char_count) {
    issues.push(`char_count mismatch: claimed ${char_count}, actual ${joined.length}`);
  }

  // 3. Commas only, no spaces
  if (joined.includes(", ")) {
    issues.push("contains ', ' — spaces after commas waste characters");
  }

  // 4. Reconstruct and compare
  const reconstructed = keywords.join(",");
  if (reconstructed !== joined) {
    issues.push("keywords array doesn't match joined string");
  }

  // 5. Duplicate detection (case-insensitive)
  const seen = new Set<string>();
  for (const k of keywords) {
    const lower = k.toLowerCase();
    if (seen.has(lower)) {
      issues.push(`duplicate token: ${k}`);
    }
    seen.add(lower);
  }

  // 6. Singular/plural detection (basic)
  for (const k of keywords) {
    const plural = k.toLowerCase() + "s";
    const singular = k.toLowerCase().replace(/s$/, "");
    if (seen.has(plural) && k.toLowerCase() !== plural) {
      issues.push(`singular/plural pair: ${k} / ${k}s`);
    }
  }

  return { ok: issues.length === 0, issues, data: parsed.data };
}

When validation fails, I retry with the specific issue appended to the prompt:

async function generateWithRetry(
  context: KeywordContext,
  attempt = 1,
): Promise<KeywordOutput> {
  if (attempt > 3) throw new Error("Failed after 3 attempts");

  const result = await generateKeywords(context);
  const check = validateKeywords(result);

  if (check.ok) return check.data!;

  // Feed issues back to Claude for a targeted retry
  return generateWithRetry(
    {
      ...context,
      existing_keywords: result.keywords,
      // Add validation issues into a correction prompt here
    },
    attempt + 1,
  );
}

In practice, 94% succeed on the first attempt, 5% on the second, 1% fall through (usually when the concept genuinely can't fit in 100 chars — time to simplify the app description, not the prompt).

The Output Nobody Asks For But Everyone Needs

The coverage_notes field in the schema looks optional. It's the most useful part.

{
  "keywords": ["budget","expense","payday","wallet","debt","bills","money","savings"],
  "joined": "budget,expense,payday,wallet,debt,bills,money,savings",
  "char_count": 51,
  "coverage_notes": [
    "Matches: 'budget', 'expense tracker', 'payday planner', 'wallet app'",
    "Covers 'money management' via money + bills combo",
    "Skipped 'finance' because it's the category — App Store auto-indexes that",
    "Skipped 'mint' (Mint.com trademark)"
  ]
}

Now the app developer can audit why each keyword was picked. When someone asks "why isn't my app showing up for X?" you have a record. Without coverage_notes, the output is a black box.

Prompt Failures I Hit Along the Way

Attempt 1: "Generate 15-20 keywords under 100 characters." Result: the model wrote a nice list, counted wrong, and delivered 112 characters. No self-verification step.

Attempt 2: Added "Do not exceed 100 characters" — model now refused to output more than 10 keywords to stay safe. Under-coverage.

Attempt 3: JSON schema with char_count field. Model started counting. Characters dropped into range but duplicates appeared.

Attempt 4 (shipped): Enumerated every rule with "apply in order," asked for coverage_notes to force reasoning, and added validation with retry.

Each failure mode came from underspecifying the rules. The LLM isn't "wrong" — it's doing exactly what the prompt asked. Getting production-grade output means writing the prompt like a spec, not a request.

Where This Lives Now

I packaged this into Apsity's AI Growth Agent — it runs on every keyword field update across the apps it tracks, compares against real-time search rankings, and flags underperforming tokens for replacement. Free tier covers 1 app and 5 keywords if you want to poke at it.

More importantly, the pattern generalizes. Any time you have "generate text inside tight constraints" — tweet drafts with character limits, SMS messages, ad headlines, product names — the structure is the same:

Enumerate every constraint as a numbered rule
Force a JSON schema with self-reported metrics
Ask for a reasoning field so you can audit
Validate in code, feed failures back for retry

Writing the spec as a prompt beats writing it as docs — because you can actually run it.

Originally written for GoCodeLab. Deeper writeups on building indie SaaS with Claude are in the Lazy Developer series.

The Claude Code Skill Set I Actually Run — Mapped by Dev Task

LazyDev_OH — Wed, 15 Apr 2026 16:11:05 +0000

A type error detonated five minutes before deploy. Claude had just declared "completed." I trusted the line and hit vercel --prod. Preview was green; the Production build failed. Four hotfix commits later, the evening was gone.

Without that incident, I wouldn't have bothered organizing my Skills. The next day I pinned /verification-before-completion as an always-on gate. Task by task I added similar guardrails. I ended up with seven Skills in active use.

This post is the Skill and plugin set I actually run — grouped by dev task. UI / Backend · API / Data · DB / Deploy · Infra / Planning · Research / Review · Debug / Process · Docs.

Skill vs Plugin

A Skill is a single markdown file — an SOP that says "this task runs in this order." One file per Skill.

A plugin is a bundle of Skills. Anthropic launched the official marketplace in January 2026, and since then /plugin install <name> pulls in a whole set. Updates ride the same command.

With 3–4 Skills, manual copy is easier. Past that, plugins are the sensible path.

The 4 Plugins I Run

Most of my dev routine lives inside these four. The rest gets filled by two or three project-specific Skills I wrote myself.

# Base install
/plugin install superpowers@claude-plugins-official
/plugin install vercel@claude-plugins-official
/plugin install frontend-design@claude-plugins-official
/plugin install bkit@claude-plugins-official

# Check
/plugin list

superpowers — methodology Skill bundle. 20+ Skills: brainstorming, TDD, systematic-debugging, verification-before-completion. obra's open-source project, now on the official marketplace. 94k+ stars. Most battle-tested set.

vercel — infra and framework. Next.js App Router, Server Components, Vercel Functions, AI SDK, deploy CLI. Keeps you on the latest syntax without memorizing release notes.

frontend-design — UI drafts + React code quality. Steers away from generic AI-looking UIs. After editing multiple TSX files, react-best-practices auto-kicks a quality checklist.

bkit — PDCA and docs layer. If superpowers is "how to work," bkit is "what to record and in what stage." Overkill for solo work; essential when client or team docs matter. Plan → Design → Do → Check → Act each has a Skill. gap-detector catches design-vs-implementation gaps; pdca-iterator runs auto-improvement loops.

Task-to-Skill Map (7 Tasks × Set)

Task	Primary Skills	Plugin
UI / Frontend	frontend-design · shadcn · react-best-practices	frontend-design · vercel
Backend · API	nextjs · vercel-functions · ai-sdk · phase-4-api	vercel · bkit
Data · DB	vercel-storage · runtime-cache · next-cache-components	vercel
Deploy · Infra	deployments-cicd · env-vars · verification	vercel · superpowers
Planning · Research	brainstorming · writing-plans · pdca (plan/design) · bkit-templates	superpowers · bkit
Review · Debug	systematic-debugging · verification-before-completion · requesting-code-review · code-analyzer · gap-detector	superpowers · bkit
Process · Docs	pdca (do/check/act) · report-generator · pdca-iterator	bkit

Some Skills overlap. verification-before-completion runs across deploy, review, and test tasks. I keep it globally on and call the rest per task.

UI / Frontend — Draft to Review

/brainstorming → /frontend-design draft → shadcn components
  → react-best-practices auto-trigger on TSX save
  → /verification-before-completion

For the draft stage, frontend-design produces production-grade drafts without the generic AI-tailwind look. If the project uses shadcn, vercel:shadcn attaches — component installs, theming, custom registries.

After implementation, vercel:react-best-practices detects multiple TSX edits and runs a review checklist — hooks usage, accessibility, performance, TypeScript patterns.

Backend · API — Next.js Fullstack

vercel:nextjs holds the freshest patterns — Server Component fetch, Server Actions for forms, Middleware for request interception. Write Next.js 16 code and it won't silently regress to 15-era syntax.

When serverless functions enter, vercel:vercel-functions attaches — Edge vs Node runtime, Fluid Compute streaming, Cron Jobs.

AI features bring in vercel:ai-sdk: chat UI, structured output, tool calls, agents, MCP integration. When working against the Anthropic SDK directly, claude-api takes priority.

At the early API-design stage, bkit:phase-4-api helps — endpoint conventions, error payload shapes, Zero Script QA (validate via structured JSON logs, not test scripts).

Deploy · Infra — On Top of Vercel

Two Skills always attached:

vercel:deployments-cicd — deploys, rollbacks, promotions, prebuilt builds. Even writes GitHub Actions workflow files.
vercel:env-vars — syncing .env with Vercel env vars, OIDC tokens, per-env separation.

The last gate is always superpowers:verification-before-completion. Confirms build, type, and tests actually pass before deploy. This Skill prevented most of my production incidents — including the "5 minutes before deploy" one from the intro.

Planning · Research — Before the Code

superpowers:brainstorming for "build vs. skip." Requirement structuring, edge-case discovery, decision trees.

superpowers:writing-plans converts brainstorming into an execution plan — split by file, by step. When the plan file is ready, /execute-plan picks it up.

When planning docs must live in the team repo, bkit:pdca's plan/design stages run alongside. Writes to docs/plans/{feature}.md in template form. bkit:bkit-templates brings planning and design doc templates.

Review · Debug — The Last Gate

Three review/debug Skills hold the last gate.

systematic-debugging kicks in on bugs and failing tests. Forces a sequence — reproduce → three hypotheses → eliminate two with evidence → minimal fix. Cuts the impulse to "just fix it."

verification-before-completion runs before "done." Confirms type, build, tests before allowing completion.

requesting-code-review is for handing off to another session for review.

Two bkit Skills attach here. bkit:code-analyzer produces pre-commit quality, security, and performance reports. bkit:gap-detector catches gaps between design docs and actual implementation — PDCA's Check stage. If Match Rate drops below 90%, pdca-iterator launches an auto-improvement loop.

Process · Docs — When Docs Become Necessary

On solo work, process and docs Skills stay off. When a teammate joins, when progress reports go to a client, or when future-me asks "why did I build it this way?" — bkit pays off.

bkit:pdca splits Plan → Design → Do → Check → Act into slash commands. /pdca plan {feature} writes the planning doc, /pdca analyze writes the post-implementation analysis.

bkit:report-generator fires after one PDCA cycle. Pulls Plan/Design/Do/Check docs and actual code into a single-page completion report — ready to hand to stakeholders.

bkit:pdca-iterator is the Evaluator-Optimizer pattern. Max 5 iterations, hands off to report-generator past 90% match rate.

Mapped Onto the EP.19 5-Agent Team

planner   → brainstorming · writing-plans · pdca plan/design
coder     → executing-plans · nextjs · frontend-design
reviewer  → requesting-code-review · react-best-practices · code-analyzer
tester    → test-driven-development · verification-before-completion
debugger  → systematic-debugging · gap-detector

If the codebase isn't Next.js, swap nextjs for whatever framework Skill fits. Skills are bundled per plugin, so changing stack doesn't require redesigning the team.

Skills I Tried and Dropped

Not every Skill is worth keeping.

using-git-worktrees — useful in theory, didn't fit my workflow. I switch branches fast and don't have enough parallel work to justify worktrees.
dispatching-parallel-agents — set it aside as I moved to running the 5-agent team directly. The external DB state-sharing structure is more stable.
bkit:enterprise / bkit:infra-architect — built for microservices + k8s + Terraform. Doesn't match my stack (Vercel + Supabase). Off unless enterprise-grade infra design actually applies.

When to Build Your Own Skill

Start with what plugins ship. Only build your own when "I keep typing the same thing" repeats three times.

My three custom Skills: publish-post (blog publish pipeline), screenshot-ppt (Puppeteer capture template), wp-media-upload (WordPress media API call). All blog-operations only.

When writing your own, superpowers:writing-skills helps — authoring conventions, examples, metadata format.

Closing

Skills don't make Claude smarter. They show Claude how I work, repeatedly. Four plugins cover most of it; the remainder goes to two or three custom Skills. First setup is under 10 minutes.

80% first, fix the remaining 20% as real problems show up. Skills grow the same way. Start with the four base plugins. When "this repeats" happens three times, that's the moment to write a new Skill. Don't force it earlier.

The last gate is always a human. verification-before-completion passing doesn't guarantee the feature works — build, type, and tests get the automated pass; business logic still needs a human check. Hold that line, and a Skill set demonstrably speeds up development.

Originally published on GoCodeLab.

Same Claude, Different Roles — My 5-Agent Dev Team

LazyDev_OH — Wed, 15 Apr 2026 16:11:00 +0000

I pushed a PR. The Claude I'd spun up as Reviewer flagged 3 edge cases and 1 memory leak. In the previous session, the Claude I'd spun up as Coder had called the same code "complete."

Same Claude 4.6. Only the role was different.

That gap is why I built an agent team from scratch. Writing and validating solo meant obvious issues slipped through. A session set up as Reviewer doesn't hand out "looks fine" easily. Tell it to nitpick and it nitpicks.

EP.17 laid down harness engineering (Rules, Commands, Hooks). Sitting on top of it now is a 5-person team — Planner, Coder, Reviewer, Tester, Debugger. Claude Code subagents isolate context by design, so they don't share cumulative state across sessions. My routine needed that sharing, so I layered MCP servers for Agent-to-Agent communication and Supabase for task state on top.

Why Quality Shifts With the Role

The principle is simple. Claude answers in line with the role you give it.

Tell it "you're the developer who wrote this code," and it answers defensively. Switch to "you're a reviewer, your job is to find mistakes," and it goes straight for edge cases. Same model, different output distribution.

The problem was writing and validating in the same session. Ask Claude "did this go well?" and it tends to protect what it just wrote. Humans do the same. Reviewing your own code has blind spots.

Role separation doesn't end with one line of system prompt. Each role reads different Skills, has different tool permissions, and produces different output formats.

The 5 Agents (Copy-Paste Ready)

Each Agent is a single markdown file following the official Claude Code subagent format — YAML frontmatter with name, description, tools, model, and the system prompt in the body.

~/.claude/agents/planner.md

---
name: planner
description: "Designs specs, implementation plans, and risks. Writes no code — outputs spec.json only."
tools: Read, Grep, Glob, mcp__supabase__query, mcp__docs_search__search
model: inherit
---

You are the Planner. You do not write code. You write the spec.
Input: user's natural-language request.
Output: spec.json (schema below).

spec.json required fields:
  - goal: one-line summary
  - user_stories: array
  - api_endpoints: method, path, I/O
  - components: new / modified components
  - data_model: new tables / columns
  - risks: N+1, missing caching, race conditions
  - test_outline: scenarios the Tester will use

Forbidden:
  - modifying files, running git, running migrations

~/.claude/agents/coder.md

---
name: coder
description: Reads Planner's spec.json and implements it. Stops before commit.
tools: Read, Write, Edit, Bash, Grep, Glob, mcp__supabase__query
model: inherit
---

You are the Coder. Read spec.json and implement it.
Do not add features outside the spec.

Sequence:
  1. Read spec.json in full
  2. List files affected
  3. Implement — record rationale in implementation_notes.json
  4. Run build / type check (exit into debugger state on failure)

Forbidden:
  - committing, git push
  - running migrations (if not in spec)
  - accessing .env or production secrets

~/.claude/agents/reviewer.md

---
name: reviewer
description: Full review of changed code. Edge cases, security, performance. No modifications.
tools: Read, Grep, Glob, Bash(git diff:*), mcp__docs_search__search
model: inherit
---

You are the Reviewer. You do not modify code. You nitpick.
"Looks fine" is only allowed after three review passes.

Review checklist:
  - edge cases (null, empty, overflow)
  - race conditions, concurrency
  - memory leaks, resource cleanup
  - security (XSS, SQL injection, missing permissions)
  - naming, consistency
  - missing error handling

Output: review_findings.json
  - severity: critical / major / minor
  - file, line, description, suggested_fix

Forbidden — modifying files, auto-formatting, refactoring suggestions outside spec

The tester and debugger follow the same pattern — each strictly scoped, each with explicit "do not" rules. What you do not do is stated explicitly. Reviewer — no edits. Debugger — no edits. Coder — no commits. Keeping each role inside its lane is half of the quality story.

Cross-Session State via Supabase

The moment I split roles, I hit a wall. Coder sessions didn't know about the spec Planner had written. Different sessions don't share memory.

Solution: an agent_state table in Supabase. Each Agent writes only to its own slot.

CREATE TABLE agent_state (
  task_id text primary key,
  project text not null,
  current_owner text,           -- planner | coder | ...
  status text not null default 'planning',
  spec jsonb,
  implementation_notes jsonb,
  review_findings jsonb,
  test_results jsonb,
  debug_trace jsonb,
  created_at timestamptz default now(),
  updated_at timestamptz default now()
);

-- planning → coding → reviewing → testing → debugging? → done

Columns are split so it's obvious which stage broke. If a session dies mid-turn, status=reviewing, review_findings is null tells me the Reviewer turn died.

State-transition guards live in a Supabase Edge Function. Moving from "planning" to "coding" requires that the spec column is populated. The DB enforces it.

Files get left behind too. docs/tasks/{task_id}.md holds human-readable output per Agent. DB is the state record, files are the reading record.

MCP Servers for Per-Role Permissions

Five agents working on the same project share tools but need different permission levels. MCP servers handle this — each Agent hits an MCP endpoint, the server checks the role, and serves only allowed operations.

// ~/.claude/mcp/supabase-server.ts (core excerpt)

const policy = {
  planner:  { read: true, write: false },
  coder:    { read: true, write: true, migrate: false },
  reviewer: { read: true, write: false },
  tester:   { read: true, write: true, tables: ['test_*'] },
  debugger: { read: true, write: false },
};

server.tool('supabase.query', async (req) => {
  const role = req.meta.agent_role;
  const p = policy[role];
  if (!p) throw new Error('unknown role');
  if (req.op === 'insert' && !p.write) {
    throw new Error(`${role} has no write`);
  }
  return await supabase.from(req.table)[req.op](req.payload);
});

No need to repeat prohibition rules in every system prompt — the server rejects anything outside role permissions. Agent prompts stay readable; security lives on the server side.

The Actual Routine

Turns are driven by one shell script. Claude Code auto-loads subagent files at ~/.claude/agents/<name>.md. The script tells the main session "read the current state for this task_id and delegate to that subagent."

# ~/.claude/bin/agent-run.sh

TASK_ID=$1
AGENT=$2

STATE=$(curl -s "$SUPABASE_URL/rest/v1/agent_state?task_id=eq.$TASK_ID" \
  -H "apikey: $SUPABASE_ANON_KEY")

claude \
  --mcp-config "$HOME/.claude/mcp.json" \
  --append-system-prompt "Task: $TASK_ID. State: $STATE. Delegate to the '$AGENT' subagent only." \
  -p "Use the $AGENT subagent to handle task $TASK_ID. Read the current agent_state, perform only your role, write back to your own column, and exit."

Turn trace for a single feature:

[me]       → agent-run.sh task-001 planner
              "add a usage chart to the dashboard"

planner    → spec.json → status=coding
coder      → implement → status=reviewing
reviewer   → 1 critical, 2 major → status=coding (rework)
coder      → apply findings → status=reviewing (round 2)
reviewer   → OK → status=testing
tester     → 2 failures → status=debugging
debugger   → root cause → status=coding
coder      → minimal fix → status=testing
tester     → all pass → status=done

[me]       → review diff → commit myself

Key point: turns are closed. A single Agent session does only its job, leaves output in files/DB, and exits. The next Agent doesn't inherit the previous session — it reads artifacts.

A human gates between Agents. I don't auto-launch the next Agent. Tried full auto once; it wandered off course. Manual gating is the current setup. Commits stay with me — no Agent has commit permissions.

What Changed, What Didn't (Honestly)

What changed: edge cases get caught earlier. Reviewer is built to nitpick, so "looks good" doesn't come cheap. Same code Coder called fine, Reviewer finds three problems in.

Debugging sped up. Debugger is a separate session, so the context is clean. No "I just wrote this, it should be fine" bias from Coder.

What didn't change: final review is still mine. Five Agents pass the code, I still skim the diff. Tester sometimes writes meaningless tests. Reviewer sometimes demands a bar nothing can pass. Debugger sometimes names the wrong cause. Team or not, the last gate is a human.

Cost went up too. About 2–3x the tokens of a single-session run. On the other hand, rework rounds dropped, so total wall-clock time actually went down. A token-for-time trade.

Closing

Role separation is less prompt engineering than workflow engineering. Same model, same codebase — split the session, and the result shifts. Ask the Coder to review, it shields its own work. Split off a Reviewer session, and it nitpicks.

80% first, then fix the remaining 20% as real problems show up. This team grew that way. Planner and Coder first. Adding Reviewer showed clearly how quality changed. Test automation was thin, so Tester joined. Debugger got split out last to kill debugging bias. Teams should grow by need.

Final review is still mine. Even after five Agents, I skim the code myself. Take that as a given, and role separation alone changes code quality — measurably.

Originally published on GoCodeLab.

axios npm Supply Chain Attack (March 31, 2026) — What Happened and How to Check Your Lock File Right Now

LazyDev_OH — Tue, 14 Apr 2026 04:44:20 +0000

On March 31, 2026, malicious versions of axios — a package with 70M+ weekly downloads — were published to npm after the maintainer's account was hijacked via social engineering. Versions 1.14.1 and 0.30.4 were pushed back-to-back, both carrying a plain-crypto-js@^4.2.1 dependency that deploys a cross-platform RAT through a postinstall hook.

The malicious releases sat on the registry for roughly 3 hours. In that window, an estimated 600,000 installs occurred.

If you use axios, check your lock file. Now.

TL;DR

Malicious: axios@1.14.1, axios@0.30.4

Safe: axios@1.14.0, axios@0.30.3 (pre-incident), 1.15.0+ / 0.30.5+ (post-incident)

Attribution: North Korea — Sapphire Sleet (Microsoft) / UNC1069 (Google)

Action: wipe node_modules, reinstall, rotate all credentials

How to Check Right Now

# Installed axios version
npm list axios

# Check lock file for malicious versions
grep -E "axios@(1\.14\.1|0\.30\.4)|plain-crypto-js" package-lock.json

# Monorepo-wide scan
find . -name "package-lock.json" -not -path "*/node_modules/*" \
  | xargs grep -l "plain-crypto-js\|1.14.1\|0.30.4"

If grep returns a match, remediate immediately. No output means you're probably fine — but also check git history. If the malicious version was ever installed in the past, the postinstall hook has already run.

# Did the malicious version ever land in lock file history?
git log -p -- package-lock.json | grep -E "1\.14\.1|0\.30\.4|plain-crypto-js"

With pnpm, use pnpm list axios; with yarn, yarn list --pattern axios. The lock-file grep pattern applies regardless of package manager.

The 3-Hour Timeline

Independent reconstructions from Aikido Security, Arctic Wolf, and Elastic Security Labs largely agree:

Time (UTC)	Event
2026-03-31 00:21	`axios@1.14.1` published — targets 1.x line, adds `plain-crypto-js@^4.2.1`
+39 min	Attacker stages the 0.x legacy release
01:00	`axios@0.30.4` published — 0.x branch compromised
~03:00	Socket.dev / Aikido detect anomalous postinstall hook, community alerts begin
~04:00	npm force-unpublishes both versions, exposure totals ~3 hours

"Only 3 hours" is a dangerous framing. Vercel, GitHub Actions, CircleCI, and similar CI environments pull fresh versions on cache misses every 10~30 seconds. Globally, tens of thousands of builds ran in that window. Several regions also reported CDN cache serving the malicious version briefly after the unpublish.

How the Malicious Code Works

plain-crypto-js disguises itself as a crypto utility. It is never imported anywhere in axios source — it exists solely to execute its postinstall hook.

During install, npm runs postinstall automatically. That hook contacts the attacker's C2 server and pulls a second-stage payload. The payload detects the host OS (macOS / Windows / Linux) and drops a matching RAT (Remote Access Trojan).

Per Elastic Security Labs, the C2 protocol rides on HTTPS with a custom command set designed to blend into normal API traffic, making network-level detection difficult.

Attack Vector — Maintainer Account Hijack

Per SANS Institute and The Hacker News, the axios maintainer account was hijacked through a targeted social engineering campaign. The attacker changed the account email to ifstap@proton.me, then abused publish permissions to push the two malicious releases.

Attribution

Microsoft Threat Intelligence: Sapphire Sleet — North Korea state actor
Google GTIG: UNC1069 — same actor, tracked independently
Joint attribution confirmed

UNC1069 / Sapphire Sleet has a track record of targeting developers through:

Fake job offers with malicious coding-test files
Fake recruiter outreach via LinkedIn or Telegram
Phishing open-source maintainers directly

This axios case appears to fall into the third pattern.

Remediation

Don't just upgrade — wipe and rebuild.

# 1. Wipe node_modules + lock file
rm -rf node_modules package-lock.json

# 2. Clean cache
npm cache clean --force

# 3. Reinstall latest safe version
npm install axios@latest

# 4. Verify
grep "plain-crypto-js" package-lock.json
# → No output = clean

Apply the same to deployment environments (Vercel / Netlify / GitHub Actions caches). A stale cache can still serve the compromised artifact.

Rotate All Credentials — Not Just Env Vars

If a malicious version ever reached your machines, the RAT may still be resident. The attacker has system-level access, not just process.env.

Rotation checklist:

[ ] AWS / GCP / Azure access keys
[ ] AI API keys — OpenAI / Anthropic / Gemini
[ ] Database passwords — PostgreSQL, MySQL, MongoDB
[ ] Payment API keys — Stripe, LemonSqueezy, Paddle
[ ] GitHub Personal Access Token + SSH keys
[ ] App secrets — NEXTAUTH_SECRET, SESSION_SECRET
[ ] Webhook secrets for external services
[ ] Infected-machine SSH public keys — remove from ~/.ssh/authorized_keys on any servers they reached

Revoke old keys immediately after issuing new ones. Keeping the old key alive defeats the rotation.

For machines with high suspicion of compromise, an OS reinstall is the safest option. CI runner images should be rebuilt clean. Local dev machines should at minimum clear browser sessions, SSH keys, and saved AWS CLI profiles, then reconfigure.

Prevention Routines

1. Commit lock files. Without a lock file, every build can pull a different version. If package-lock.json is in .gitignore, remove it now.

2. Put npm audit in CI. Run it on every PR. npm audit --audit-level=high catches high-severity issues at minimum. Caveat: audit only sees what's public in the CVE database.

3. Tighten version range specifiers.

// ❌ Too loose — opens the door to auto-updates
"axios": "^1.13.0"

// ✅ Exact pin
"axios": "1.14.0"

// ✅ Patch-only
"axios": "~1.14.0"

4. Monitor beyond CVE.

Tool	Strength	Note
Dependabot	Built into GitHub	CVE-based, limited against fresh attacks
Socket.dev	Behavioral analysis	Flagged this axios incident early
Aikido Security	Real-time behavioral	Published first public analysis
Snyk	Scan + remediation	Free tier available
npm audit	Built-in	CVE-based limits

Realistic combo: Dependabot + Socket.dev. Single-tool reliance leaves blind spots.

Why This Keeps Happening

The npm ecosystem has a low publishing bar. A single account compromise can poison a package used by hundreds of millions of developers. That structural fact isn't changing fast.

XZ Utils (2024-03) — compromised Linux distribution backdoor
event-stream (2018) — crypto wallet stealer hidden in dependency
ua-parser-js (2021) — malicious versions with credential stealer
axios (2026-03) — this incident

axios isn't the first and won't be the last.

Following this incident, npm is reportedly considering mandatory 2FA expansion and a 24-hour cooldown on maintainer email changes. GitHub already required 2FA for top npm maintainers since 2024, but this hijack went through the email recovery flow. Security chains only hold as strong as the weakest link.

Key Takeaways

Check your lock file right now — don't assume you're fine.
Wipe, don't just upgrade — stale caches and remnant RATs are real risks.
Rotate credentials broadly — system-level access means everything is suspect.
Put behavioral analysis in your CI — CVE-based tools can't catch fresh attacks.
Pin exact versions for critical packages — range specifiers are attack surface.

Trusting a popular package and verifying it are different things. If you use axios, put a version check in your routine starting today.

Sources:

Originally published on GoCodeLab — April 2026.

Vercel vs Netlify vs Cloudflare Pages 2026 — Deep Comparison with Real Numbers

LazyDev_OH — Tue, 14 Apr 2026 04:25:43 +0000

The web deployment landscape crystallized into a clear three-way split in 2026. Vercel for Next.js full-stack. Cloudflare Pages for static sites and edge workloads. Netlify for the Jamstack middle ground. All three ship with git push-to-deploy out of the box.

The real story is in billing and performance. In February 2026, Vercel shipped Fluid Compute to GA and announced up to 95% cost savings across 45 billion weekly requests. Cloudflare Workers hold cold starts under 5ms. Netlify migrated to credit-based billing in September 2025. The same app gets billed differently, responds at different speeds, and feels different to operate.

Short version: Next.js ecosystem → Vercel. High-traffic static or edge-heavy → Cloudflare Pages. Forms and adapter ecosystem → Netlify.

Quick Summary

Vercel: Hobby free (100GB · 1M invocations), Pro $20/user/mo, Fluid Compute saves up to 95%
Netlify: Free 100GB · 300 build min, Pro $19/user/mo, credit-based since Sept 2025
Cloudflare Pages: unlimited bandwidth, 500 builds/mo free, Workers Paid $5/mo bundles ecosystem
Cold starts: Cloudflare < 5ms > Vercel Fluid ~0ms (warm) > Netlify 150~3,000ms
Next.js support: Vercel native > Netlify adapter (30~60% slower builds) > Cloudflare OpenNext (constraints)
Edge PoPs: Cloudflare 330+ / Vercel 40+ / Netlify 8-region multi-cloud
Cloudflare ecosystem: KV · D1 · R2 · Durable Objects · Hyperdrive bundled at $5

What Each Platform Actually Is

Vercel was founded by Guillermo Rauch in 2015 — the same person behind Next.js. As of 2026, the company sits around $3.2B valuation. The core edge: native Next.js integration. ISR, Image Optimization, Middleware, Server Actions, Cache Components — all of it works with zero config. Hobby plan is personal / non-commercial only.

Netlify was founded in 2014 and coined the term "Jamstack." Framework adapters span Astro, Next.js, SvelteKit, Nuxt, Gatsby, Hugo — the widest ecosystem of the three. Forms, serverless functions, and Edge Functions come built in. In September 2025, they migrated to credit-based billing.

Cloudflare Pages runs on Cloudflare's global edge network. The headline features are 330+ PoPs and unlimited bandwidth. Workers Paid ($5/month) alone bundles Workers, Pages Functions, KV, D1, R2, Durable Objects, and Hyperdrive. Next.js runs through OpenNext and inherits edge runtime constraints — some Node.js modules unavailable, ISR limited.

Free Tier Deep Dive

Metric	Vercel Hobby	Netlify Free	Cloudflare Pages
Bandwidth	100GB	100GB	Unlimited
Build time	Unlimited deploys	300 min/mo	500 builds/mo
Function invocations	1M/mo	125K/mo	100K/day (~3M/mo)
CPU time	4h Active CPU	Credit-based	10ms/request
Storage	1GB Blob	10GB	R2 10GB / KV 1GB
Usage restriction	Personal / non-commercial	Commercial OK	Commercial OK

Cloudflare dominates on raw bandwidth — traffic spikes don't trigger overage invoices. Vercel Hobby's decisive constraint is the no-commercial clause. A single advertisement can put you in violation. Netlify's 300 build-minute cap is the actual bottleneck — a medium Next.js project often builds in 5~8 minutes, hitting the ceiling at 40~60 deploys/month.

Paid Plans and Overage Simulation

Vercel Pro: $20/user/month + 16 CPU-hours, 1,440 GB-hours memory — overage Active CPU $0.128/hour
Netlify Pro: $19/user/month + 1TB bandwidth, 25K build minutes — $7 per 500 extra build min, $20 per 100GB extra bandwidth, $25 per 1M extra invocations
Cloudflare Workers Paid: $5/month + 10M requests, 30M CPU-ms — $0.30 per extra 1M requests

Scenario A — Small blog (100K monthly visits, 50GB bandwidth, 500K function calls)
Vercel Hobby $0 / Pro $20. Netlify Free possible. Cloudflare Pages $0. → Cloudflare Pages wins.

Scenario B — Next.js SaaS (500K monthly visits, 5M function calls, DB-heavy)
Vercel Pro ~$20~30 (Fluid keeps CPU overage near zero). Netlify Pro $19 + function overage $100 = $119. Cloudflare Workers Paid $5 + extra requests $1.50 = $6.50. → Order: Cloudflare, Vercel, Netlify. If Next.js compatibility is non-negotiable, Vercel.

Scenario C — Image hosting (2TB monthly downloads)
Vercel Pro $20 + 1.9TB overage $380 = $400. Netlify Pro $19 + 1TB overage $200 = $219. Cloudflare R2 $0 egress + $30 storage = $30. → For egress-heavy workloads, Cloudflare is effectively the only option.

Vercel Fluid Compute — Real Savings

Fluid Compute hit GA in February 2026. Per Vercel's figures: 45B weekly requests, customers seeing up to 95% savings, 75%+ of all functions now on Fluid. The old model billed the entire function duration. Fluid only bills Active CPU windows — when your code is actually executing.

// Example: Next.js API handler (I/O-bound)
export async function GET(req) {
  // 100ms — JSON parsing, validation (Active CPU)
  const body = await req.json()
  // 400ms — Supabase query wait (I/O, Fluid bills nothing)
  const data = await supabase.from('users').select()
  // 30ms — response serialization (Active CPU)
  return Response.json(data)
}
// Total wall time: 530ms
// Legacy billing: 530ms (all of it)
// Fluid billing: 130ms (Active CPU only) → 75% saved

From Vercel's case studies: "Many of our API endpoints were lightweight and involved external requests, resulting in idle compute time. By leveraging in-function concurrency, we were able to share compute resources between invocations, cutting costs by over 50% with zero code changes."

For typical Next.js apps, expect function invocation counts to drop 30~50% with proportional cost reduction. The benefit is limited for CPU-heavy workloads (ML inference, image resizing) where Active CPU dominates.

Cold Start Benchmarks — 5ms vs 250ms vs 3 Seconds

Platform	Cold start	Warm response	Mechanism
Cloudflare Workers	< 5ms	~1ms	V8 Isolates + Shard-and-Conquer (99.99% warm)
Vercel Fluid	~0ms (warm)	20~50ms	Instance pre-warming + in-function concurrency
Vercel legacy serverless	~250ms	50~80ms	AWS Lambda
Netlify Functions	150~3,000ms	80~150ms	AWS Lambda (high variance)

Cloudflare Workers' sub-5ms comes from V8 Isolates. Instead of spinning up a container, the platform runs your function directly inside the JavaScript engine. Initialization overhead is near zero. Shard-and-Conquer consistent hashing routes same-request traffic to the same node, keeping warm-hit rate at 99.99%.

Vercel Fluid keeps instances warm with in-function concurrency — a single instance handles multiple concurrent requests. Near-zero cold starts for active functions.

Netlify, running on AWS Lambda, is the slowest. Cold starts up to 3 seconds in benchmarks. For low-traffic sites or early-morning first requests, users feel the wait.

Next.js Feature Compatibility Matrix

Next.js feature	Vercel	Netlify	Cloudflare (OpenNext)
Server Components (RSC)	Full	Full	Full
Server Actions	Full	Full	Partial
ISR (revalidate)	Full	On-Demand only	Limited
Image Optimization	Native	Adapter	Cloudflare Images
Middleware	Full	Full	Full (edge)
Cache Components	Full	Planned	❌
Partial Prerendering (PPR)	Full	Partial	❌
Edge Runtime	Full	Edge Functions	Native
Full Node.js modules	All	All	Some blocked
Build speed (same project)	baseline	30~60% slower	20% slower

Next.js' latest features (Cache Components, PPR) only ship fully on Vercel. Netlify covers most of it via adapter, but ISR semantics differ and builds run noticeably longer. Cloudflare Pages inherits edge-runtime constraints — can't use fs, net, or child_process, and ISR requires wiring Incremental Cache into KV separately.

On the flip side, Cloudflare's Image Optimization routes through Cloudflare Images (faster CDN), and Edge Runtime is native. For edge-friendly codebases, Cloudflare Pages can actually win.

Cloudflare Ecosystem — KV · D1 · R2 · Durable Objects

Cloudflare's real edge: $5/month Workers Paid bundles 6+ data services. Each as a standalone SaaS would run into hundreds of dollars.

Service	Use case	Price (Paid)
Workers KV	Global key-value, config/session/personalization	Reads 10M $0.50, writes 1M $5
D1	Managed SQLite, lightweight relational DB	Reads 25M $1, writes 50K $1
R2	S3-compatible object storage, zero egress	$0.015/GB storage, Class A 1M $4.50
Durable Objects	WebSockets, collaboration, locks, rate limiters	1M requests $0.15, $0.20/GB/mo
Queues	Message queue, async work	1M operations $0.40
Hyperdrive	External PostgreSQL pooling	Included in Workers Paid

Practical combo: sessions/config on KV, user data on D1, images/files on R2, chat rooms on Durable Objects, background jobs via Queues. Everything at the same $5.

AWS equivalent stack: RDS ($15) + DynamoDB ($10) + S3 ($5) + egress ($100+) + SQS ($2) = $130+/month minimum. R2's zero-egress policy alone makes file-heavy services land in a completely different cost range.

Durable Objects is the only practical choice for stateful edge computing. WebSocket chat rooms, Google Docs-style real-time collaboration, distributed locks, rate limiters. Vercel and Netlify have no equivalent, forcing external services (Pusher, Ably) to fill the gap.

Edge Network and Global TTFB

Cloudflare: 330+ PoPs across 120+ countries
Vercel: own edge network (40+ regions) + AWS/GCP
Netlify: multi-cloud AWS/GCP/Azure (8 main regions)

TTFB benchmarks from Korea (static content): Cloudflare Seoul PoP 30~50ms, Vercel Tokyo/Seoul region 80~120ms, Netlify US-West default 250~400ms. For global apps with APAC users, Cloudflare is overwhelmingly the fastest experience.

Vercel's Tokyo/Singapore regions can reach ~100ms in Korea when explicitly configured. Hobby has limited region pinning; Pro enables per-project region selection. Setting regions in vercel.json is important — defaults often point to US regions.

Netlify Credit-Based Pricing

Since September 2025, Netlify uses a unified credit pool. Approximate conversions: 1 build minute = 1 credit, 1,000 function invocations = 1 credit, 1 GB bandwidth = 1 credit. Pro includes 500 credits/month — in theory 100 deploys if builds are 5 minutes each, but practical ceiling drops to 50~70 after other usage.

The complaint is predictability. "My build ran long and drained my credits" posts keep showing up in dev forums. Accounts created before September 4, 2025 can stay on the legacy plan.

Netlify's strengths still hold — Forms built in (100 submissions/mo free), Identity, Large Media, Split Testing. Features Vercel and Cloudflare don't match natively.

Full Comparison Table

Dimension	Vercel	Netlify	Cloudflare Pages
Free bandwidth	100GB	100GB	Unlimited
Paid starting	$20/user/mo	$19/user/mo	$5/mo
Cold start	~0ms (warm)	150~3,000ms	< 5ms
Next.js support	Native (full)	Adapter (mostly)	OpenNext (constrained)
Serverless billing	Active CPU (Fluid)	Credit-based	Per-request
Global PoPs	40+ edge	8 regions	330+ PoPs
Commercial free use	Not allowed	Allowed	Allowed
Ecosystem	Next.js + Postgres/KV/Blob	Forms, Identity, Split Testing	KV, D1, R2, DO, Queues
Build speed (Next.js)	Fastest	30~60% slower	20% slower
DX / dashboard	Best	Clean	Deep but learning curve
Egress cost	Deducts from bandwidth	Deducts	R2 $0

Combining Platforms — Real-World Patterns

No reason to pick one and stick with it.

# Pattern A — Subdomain split (most common)
static.example.com  → Cloudflare Pages (images, docs, heavy assets)
app.example.com     → Vercel Pro (Next.js full-stack)
forms.example.com   → Netlify (form intake)

# Pattern B — Cloudflare as front CDN, Vercel as origin
Cloudflare (CDN/WAF/DDoS) → Vercel (serverless origin)
# Cloudflare absorbs egress, Vercel handles execution only

# Pattern C — Full Cloudflare stack (AWS alternative)
Cloudflare Pages + Workers + D1 + R2 + Durable Objects
# Full-stack infra starting at $5/month

Recommendations by Scenario

Scenario	Pick	Why
Next.js full-stack SaaS	Vercel Pro	Fluid Compute 95% savings, Cache Components/PPR native
Image / video hosting	Cloudflare + R2	Zero egress, 330+ PoPs
Astro / SvelteKit	Netlify	Adapter ecosystem, built-in forms
Real-time / WebSocket	Cloudflare + DO	Only edge stateful solution
Global TTFB matters	Cloudflare	Largest edge network
Intermittent traffic	Vercel Fluid / Cloudflare	Low cold start
Personal (no revenue)	Vercel Hobby	All Next.js features free
Form-heavy marketing	Netlify	Forms built in

Closing Thoughts

All three platforms are mature as of 2026. "Which is better" is the wrong frame — "which fits your stack" is the real question.

Three trends worth watching as of April 2026:

Vercel Fluid Compute now powers 75%+ of all Vercel Functions and has measurably dropped Next.js full-stack bills.
Cloudflare D1 moved past GA with real production references, making AWS RDS replacement a concrete option.
Netlify's credit-based pricing is driving heavy users to reconsider.

The right choice shifts each year. Review your workload periodically.

Official sources:

Originally published on GoCodeLab — April 2026 pricing. Plans and policies change frequently; verify with official docs before committing.

I Catalogued the Security Patterns That Keep Showing Up in AI Code

LazyDev_OH — Mon, 13 Apr 2026 04:03:48 +0000

Across the Apsity App Store dashboard, the FeedMission SaaS, and a dozen side projects, more than half the code I touch is AI-generated. After shipping a SaaS in 7 days, vibe coding has been the default workflow.

Run it long enough and the patterns show up. AI-generated code keeps producing the same classes of security holes. One FeedMission review surfaced seven criticals at the same time — a Slack webhook URL bundled into the frontend, an unsubscribe endpoint that any email address could trigger, an admin reply leaking through a public API, routes missing team-member auth checks. None of that was bad luck. Industry research lists these as the highest-frequency patterns, and they had effectively reproduced themselves in our codebase.

So now I run the same seven checks before every deploy, the same way each time. This post is the pattern catalogue plus the routine.

The numbers, first

This isn't a vibe check. Multiple groups in 2026 (Georgia Tech, Cloud Security Alliance, Checkmarx) analyzed AI-generated code and found:

40–62% of samples contain security issues
2.74× more vulnerable than human-written code on equivalent tasks
86% failed XSS defenses
88% vulnerable to log injection
35 new CVEs tied to AI-generated code in March 2026 alone
One AI app leaked 1.5M API keys post-launch — shipped without security review

Nobody's quitting vibe coding because of these numbers. I'm not. But the 10 minutes you spend before deploy is what decides production's fate.

How AI skips security

Beginners get this wrong. The AI didn't make a mistake — it built what you asked for. "Make a user profile API" → it makes one. Auth wasn't requested, so it's not there. It leaves // TODO: add auth here and moves on.

The fix: put security in the prompt from the start. "Include JWT auth middleware, read secrets only from env, no raw SQL, no TODO comments, ship complete code." One line changes the output quality.

Top 7 mistakes — in the order I hit them

#	Mistake	What happens	Red flag
1	Hardcoded API keys	Scraped by bots within seconds	`sk_`, `api_key=`
2	Auth-less API routes	URL-only access to your DB	no session/auth/token references
3	`NEXT_PUBLIC_` misuse	Service-role key in browser bundle	`NEXT_PUBLIC_*_SECRET/KEY`
4	Raw SQL interpolation	SQL injection → full DB exfil	`SELECT ... ${}`
5	CORS wildcards	Any domain hits your API	`Allow-Origin: *`
6	Missing XSS / log-injection defense	User input straight into HTML/logs	`dangerouslySetInnerHTML`, raw-string logs
7	Phantom packages (slopsquatting)	Malicious package under hallucinated name	unfamiliar packages, low downloads

1 and #3 hit fastest. The moment you push to GitHub, scraper bots scoop the key and burn your API quota. If you've never been hit, you've only been lucky.

Slopsquatting warning — when AI says npm install some-plausible-package, check npmjs.com first. About 20% of AI-generated code references nonexistent packages. Attackers register those names with malicious payloads, and you install them instantly.

What could have happened at FeedMission

From the 7 above, FeedMission had #2, #3, #6, plus a few app-specific issues:

Slack webhook URL rode on ProjectContext into the frontend bundle.
Unsubscribe API took just an email address. Anyone's email → instant unsubscribe. Switched to an unsubscribeToken flow.
/api/feedback/mine returned the full admin reply text. Now hasReply: boolean only.
Team member auth checks missing across several APIs.
.env wasn't in .vercelignore — almost shipped via symlink in a Vercel build.

All fixed in one commit (52efb89). None of these are "too edge-case to happen to me."

My 10-minute pre-deploy routine

# 1. Three grep lines — 5 seconds
# Unfinished security code
grep -r "TODO\|FIXME\|implement.*later\|add.*auth" ./src

# Hardcoded secrets
grep -r "sk_\|api_key\|password\s*=" ./src

# Client-exposed env vars
grep -rE "NEXT_PUBLIC_.*(SECRET|KEY|TOKEN)" ./src

# 2. SQL interpolation and CORS wildcards
grep -rn "\`SELECT\|\`INSERT\|\`UPDATE\|\`DELETE" ./src
grep -rn "Allow-Origin.*\*" ./src

If all pass, paste the generated code back to the AI and ask: "Review this code against OWASP Top 10 for vulnerabilities." Imperfect but a fine first-pass filter.

GitHub side, turn on three things: Secret Scanning, Push Protection, CodeQL Code Scanning. Plus Dependabot/npm audit in CI for package vulns.

My prompt tail (every code-generation request): "Include auth middleware; read secrets only from process.env and use NEXT_PUBLIC only for public values; always validate user input; no raw SQL; ship complete code without TODO/FIXME."

Bonus — Using Supabase? RLS is its own chapter

Next.js + Supabase is the default vibe-coder stack, so RLS gets a dedicated section. RLS (Row Level Security) is PostgreSQL's row-level access control. "This row is readable only by the user whose user_id matches" — enforced at the database layer.

Why this matters: when you create a table in Supabase Studio, RLS is OFF by default. Ship NEXT_PUBLIC_SUPABASE_ANON_KEY to the client in that state and anyone with that key can read or write every row in every table. The anon key effectively becomes a service-role key. Whatever assurance "client-side anon key is safe" gave you, it's gone.

Turning RLS on isn't enough either. Without policies, every access is denied. You write separate policies per action: SELECT, INSERT, UPDATE, DELETE. The most frequent mistake is writing USING (the read/delete-time filter) but forgetting WITH CHECK (the post-write validation):

-- ✗ Risky — USING only
CREATE POLICY "own rows"
ON posts FOR UPDATE
USING (auth.uid() = user_id);
-- WITH CHECK forgotten!

-- ✓ Safe — both
CREATE POLICY "own rows"
ON posts FOR UPDATE
USING (auth.uid() = user_id)
WITH CHECK (auth.uid() = user_id);

Without WITH CHECK, user_a can INSERT or UPDATE rows claiming user_b's user_id — planting rows or hijacking existing ones.

Three review queries to save in your Supabase SQL Editor:

-- 1. Tables with RLS still off
SELECT tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public' AND rowsecurity = false;

-- 2. RLS on but no policies — everything is rejected
SELECT t.tablename
FROM pg_tables t
LEFT JOIN pg_policies p
  ON t.schemaname = p.schemaname AND t.tablename = p.tablename
WHERE t.schemaname = 'public' AND p.policyname IS NULL;

-- 3. INSERT/UPDATE policies missing WITH CHECK
SELECT tablename, policyname, cmd, qual, with_check
FROM pg_policies
WHERE schemaname = 'public' AND cmd IN ('INSERT', 'UPDATE') AND with_check IS NULL;

Run these after every migration. Empty results on all three = you're clear.

Top-4 BaaS-specific mistakes:

RLS off — anon key becomes a master key.
Missing WITH CHECK — attackers plant rows under someone else's user_id.
service_role key shipped to client — SUPABASE_SERVICE_ROLE_KEY must never be NEXT_PUBLIC. Server routes / Edge Functions only.
Permissive anon-role policies — auth.uid() = user_id missing means unauthenticated callers reach every row.

Same principle applies to Firebase Security Rules, Appwrite Permissions, PocketBase Collection rules: if the client talks to the database directly, the database is the last line of defense. Leave that line empty and no upstream security matters.

Wrap-up

Vibe coding didn't make security worse. The habit of deploying without review did. AI raised the speed. Raise your review speed with it. Three grep lines, one AI review, three GitHub settings, the RLS check if you're on Supabase. Ten minutes.

Skip those ten minutes and "1.5M API keys leaked" stops being someone else's story.

Sources

Originally published at GoCodeLab. Lazy Developer EP.18.

Upgraded to Tailwind v4 — Config Files Are Gone

LazyDev_OH — Mon, 13 Apr 2026 02:23:23 +0000

Tailwind CSS v4 shipped in January 2025 and tailwind.config.js is gone. Configuration now lives inside the CSS file itself. I migrated a Next.js project — unfamiliar at first, but simpler once you're through it.

The actual transition is faster than expected. The official CLI handles about 80% of it.

What Changes

tailwind.config.js → replaced by a CSS @theme block
Rust-based Oxide compiler — up to 5x faster full builds, up to 100x faster incremental
Automatic content detection — no more manual content array
@tailwind base/components/utilities → single @import "tailwindcss"
Plugins declared in CSS via @plugin "..."

Real-world number from Tailwind's own benchmark: a design system with 15,000 utility classes saw cold builds drop from 840ms to 170ms.

Config Moved into CSS

v3 kept everything in JS. v4 does it all in one CSS file.

/* v4 — configure directly in CSS */
@import "tailwindcss";

@theme {
  --breakpoint-3xl: 1920px;
  --color-brand: oklch(68% 0.19 245);
  --font-display: "Inter Variable", sans-serif;
}

@theme uses CSS variables. Design tokens are visible in DevTools at runtime. One less JS dependency.

@theme Naming Convention

--color-{name}, --font-{name}, --spacing-{name}. Tailwind reads the namespace and generates utility classes automatically. Define --color-brand and text-brand, bg-brand, border-brand light up immediately.

Oxide Compiler

Rust, not Node. Replaces the old PostCSS plugin. Content path detection is automatic — no more content: ['./src/**/*.tsx']. Oxide ships inside the tailwindcss v4 package, no separate install. Integrates with Vite and PostCSS pipelines.

Migration Steps

Option A — one command

npx @tailwindcss/upgrade

Handles config conversion and class renames for projects without custom plugins.

Option B — manual (Next.js / PostCSS)

npm install tailwindcss@latest @tailwindcss/postcss

// postcss.config.js (v4)
module.exports = {
  plugins: {
    "@tailwindcss/postcss": {},
  },
};

/* globals.css (v4) */
@import "tailwindcss";

@theme {
  --color-brand: #6366f1;
}

tailwind.config.js can be deleted or kept — v4 doesn't read it. Deleting it is cleaner for team repos.

Plugins Now Live in CSS

@import "tailwindcss";

@plugin "@tailwindcss/typography";
@plugin "@tailwindcss/forms";
@plugin "./plugins/my-plugin.js";

@theme {
  --color-brand: #6366f1;
}

The plugins array in tailwind.config.js is gone. Pass a package name or a file path to @plugin and it works. Existing addUtilities and addComponents APIs mostly still apply, but parts of the plugin API changed — verify behavior after migrating.

The `outline-none` Gotcha

v3: outline-none rendered as outline: 2px solid transparent — still accessible.
v4: outline-none renders as outline: none — actually removes the outline.

If you used outline-none to hide focus rings on buttons or inputs, swap in outline-hidden. Expect this to surface during accessibility checks.

v3 vs v4 at a Glance

Area	v3	v4
Config	`tailwind.config.js`	CSS `@theme` block
Import	three `@tailwind` lines	`@import "tailwindcss"`
Content detection	manual array	automatic
Compiler	PostCSS (Node)	Oxide (Rust)
Plugins	`plugins: [...]`	`@plugin "..."`
`outline-none`	transparent outline	actual `none` (use `outline-hidden`)

Should You Upgrade Now?

New project → v4. No reason not to.
Existing v3 project → no rush. v3 is still supported.
Heavy custom-plugin stack → stay on v3 until you've tested each plugin against the v4 API.
Build times biting → v4 is worth the migration cost just for the Oxide numbers.

FAQ

Q. Do I need to delete tailwind.config.js?
No — v4 doesn't read it. The upgrade CLI handles conversion. Delete for cleanliness.

Q. Separate Oxide install?
No. Included in the tailwindcss v4 package.

Q. How long does migration take?
Small Next.js projects: 30 minutes including manual review. Larger ones with custom plugins and dynamic class composition (bg-${color}-500 patterns): a couple hours, because those aren't auto-migrated.

Sources

Originally published at GoCodeLab.

Forem: LazyDev_OH

I Spent a Week with the MCP Server I Built — 8 Real Cases for Apsity

1. "Validate a new app name — conflict + visibility"

2. "Compare 3 markets → pick one"

3. "Competitor descriptions → keywords missing from mine"

4. "Tracked competitors → threat & next move"

5. "Build me a launch-week baseline"

6. "Top 10 meta → my app's design guide"

7. "History → next-week research plan"

8. "20-country sweep → top market + plan"

Why four tools is enough

Why MCP actually helps

Next episode

I Shipped 3 Major Features in 3 Days — Keyword Search, MCP Server, Monthly Magazine

Why these three at once

How concurrency was possible — slicing phases

Day 1 (4/28) — Keyword Search

Day 2 (4/29) — MCP server

Day 3 (4/30) — monthly magazine

Things that snuck in

Retrospective — what really made it work

Coming next

FAQ

Q. Did you really build three features at the same time?

Q. How did you build the MCP server?

Q. How do you slice phases?

Q. Is Claude doing all of this?

Related posts

Supabase RLS — 5 Common Mistakes I Broke and Fixed Myself

Quick Look

What RLS Is — Why Mistakes Happen

Mistake 1 — RLS Itself Wasn't Enabled

Mistake 2 — RLS Enabled but No Policies

Mistake 3 — auth.uid() Called Directly

Mistake 4 — UPDATE WITH CHECK Missing

Mistake 5 — INSERT Policy with No Role Specified

Bonus — service_role Key in the Client

Real-World Scenario — Full RLS Setup for a Multi-User Notes App

Mixed Public/Private Posts

RLS Policy Checklist

Adding RLS to an Existing Project

How to Properly Verify RLS

Closing

Official sources

How to Actually Write a CLAUDE.md — A Solo Indie Dev's Guide From Running 16 Apps

TL;DR

What CLAUDE.md actually is

How it differs from other config files

How to split global vs project

Pattern 1 — Pin identity and stack on the first line

Pattern 2 — Pin tone rules with detail

Pattern 3 — Write coding rules as "prohibition + alternative"

Pattern 4 — Write workflow as steps

Pattern 5 — Pin dangers explicitly

Use @import to break up long rules

A small script to keep CLAUDE.md updated

Limitations — what pinning can't fix

What to pin first, by situation

Wrapping up

Official sources

Cursor Rules vs CLAUDE.md — A Deep Dive into Context Injection Patterns for AI Coding Tools

TL;DR

At a glance

Why Cursor Rules and CLAUDE.md are different species

The 4 modes of Cursor Rules

CLAUDE.md's 3 layers and @import system

Context injection timing — every time vs once

globs matching vs @import — file-splitting pattern

Token cost and noise control

Strategy for running both tools together

Debugging order when rules don't stick

Security and git commit policy

Real example — my SaaS setup

AGENTS.md — the 2026 single-source-of-truth trend

Wrap-up

Official sources

Teaching Claude to Play Tetris with 100 App Store Characters

The Constraints That Break Generic LLMs

Why Claude Sonnet

The Prompt Structure