Forem: Kai

Sensitive Env Vars Should Be Default, Not Opt-In

Kai — Mon, 20 Apr 2026 07:47:12 +0000

I wrote a post earlier today about cleaning up after the Vercel breach. The cleanup itself is easy — ten minutes, a sequence of clicks, done.

What's been bugging me all afternoon is a different question:

Why is "sensitive" opt-in?

The implicit default is wrong

When you add an env var to Vercel, it's not marked sensitive by default. You have to remember to toggle it.

This is the wrong default for a class of values where 99% of the time, "sensitive" is what you want.

Think about the actual population of env vars in any real project:

API keys for third-party services — sensitive
Database URLs — sensitive
Signing secrets — sensitive
Stripe keys, Auth0 secrets, etc — sensitive
Feature flags — occasionally sensitive
Config booleans — usually not sensitive
Public API base URLs — not sensitive (they're in the client bundle anyway)

For most teams, the split is maybe 80/20 in favor of "should be sensitive." Maybe 90/10.

A default that matches 10-20% of cases is a design mistake.

Why the default exists

Vercel has a specific technical reason: sensitive env vars can't be read after they're set. You can only overwrite or delete. This makes debugging harder when you're troubleshooting "is the value what I think it is?" The opt-in default gives you a debugging escape hatch.

Fine. But the escape hatch should be the exception, not the default. Debugging an env var value is maybe 1% of the time you interact with env vars. Protecting against leaks is 100% of the time.

Moving from "default not-sensitive, opt-in sensitive" to "default sensitive, opt-out for debugging" would match the actual weight of the two concerns.

The minimal workflow change

I can't change Vercel's default. I can change my own habit.

Before today: add env var, fill in value, save. Maybe remember to toggle sensitive. Maybe not.

After today: add env var, fill in value, sensitive ON, save. If I later need to debug, I'll flip it off, verify, flip it back.

The cost is two extra clicks at creation time. The benefit is that every future breach like today's is a non-event.

Generalizing: safe defaults for tiny projects

There's a broader principle here. Small projects skip security hygiene because the perceived cost-benefit is wrong:

"I have no users, who'd target me?" — but breaches are opportunistic, not targeted
"I'll tighten security when I scale" — but by then you have user data in the loss radius
"Defaults are too paranoid for my usecase" — but defaults are designed for the median case, which is probably you

The fix isn't to be paranoid. The fix is to use tools' safest defaults and only opt out when there's a specific reason. Think of it as borrowing the thinking of a larger team.

Concretely for a solo/indie Next.js + Vercel setup:

Env vars: sensitive by default. I explained my reasoning above.
Deployment protection: "Standard" minimum. Blocks preview deploys from being publicly indexed.
Branch protection on main: requires PR + review even if the reviewer is yourself 24h later. Catches "oh no I just committed the API key" before push.
Pre-commit hook scanning for secrets: cheap to set up, catches the stupid ones. I wrote a piece about mine — it's a 30-line shell script and it's caught me twice.
Service-specific secret rotation: quarterly, on a calendar. Not because you expect a breach. Because it bounds the window.
Separate secrets by environment: production secrets live only in production. Preview and development use their own keys or dummy values.

Each individual control takes five to thirty minutes to set up. None of them are hard.

The meta-lesson

Security defaults are worth thinking about critically because the cost of getting them wrong only shows up asymmetrically — nothing happens 99 times, something catastrophic happens on the 100th.

Most of us outsource this thinking to platform defaults and assume platforms get it right. Today was a reminder that platforms sometimes get it right for the platform, not for you.

Audit your defaults. Pick the ones that cost you two clicks and buy you asymmetric downside protection.

Three cups of tea. No coffee. Sensitive flag ON from now on. Lesson logged.

The Vercel Breach Hit One of My Projects. Here's What 10 Minutes of Cleanup Looked Like.

Kai — Mon, 20 Apr 2026 06:42:26 +0000

Vercel disclosed a security incident today. The short version: a third-party AI tool (Context.ai) used by a Vercel employee got compromised, the attacker took over the employee's Google Workspace, and used that to access some Vercel environments and environment variables not flagged as "sensitive."

I checked my dashboard expecting the all-clear.

One of my env vars had a "Need to Rotate" tag. I was in the affected subset.

Here's the full cleanup, in the order I did it, with what I'd do differently.

What the tag looks like

Vercel surfaced this in two ways:

The affected subset gets an email from Vercel security
The dashboard shows a yellow "Need to Rotate" badge on the specific env var

I didn't get the email (or it went to a spam folder I didn't check). The dashboard tag is what told me.

Lesson already learned: the dashboard is the authoritative source during an incident. Don't wait for the email.

The 10-minute recovery

Step 1: Do NOT revoke the old key first

I almost did. If you revoke before you've cut over, your production endpoint dies between revoke and replacement.

Order matters: new key → update env → verify → revoke old.

Step 2: Generate a new key

Go to the provider (in my case, the email API vendor whose key was exposed). Create a new key with the same permissions as the old one. Name it with the date — vendor-prod-20260420 — so future-me knows what it was for.

Copy the key immediately. Most providers show it exactly once.

Step 3: Update the Vercel env var

In Vercel dashboard: Project → Settings → Environment Variables. Find the compromised one. Edit.

Paste the new value.

And here's the critical part — toggle "Sensitive" on. If your env var was marked Sensitive before the incident, Vercel's bulletin says those values were stored in a way that prevented them from being read. The attacker only had access to non-sensitive ones.

Small gotcha: Sensitive env vars can't exist in the Development environment. Just Production + Preview. That's fine for most setups — you use .env.local for dev anyway.

Step 4: Redeploy

An env var change does not automatically trigger a deployment. You have to redeploy manually or the new value won't hit your running production.

Deployments tab → latest production → ⋯ → Redeploy. Don't reuse the build cache.

Two minutes later, production is running the new key.

Step 5: Verify it works

Hit your endpoint with a test request. In my case, I did a real newsletter signup from the public site with a test email. Got a 200 back, saw the test contact in the email vendor's dashboard. New key live.

If you skip this step and the new key has a typo or permission gap, you won't know until the next real user hits the broken endpoint.

Step 6: Now revoke the old key

Back at the provider. Revoke. Confirm.

This is the step where the potential leak actually closes. Everything before was setup.

Step 7: Audit your other env vars

While you're in there:

Mark everything sensitive that should be sensitive (retroactive fix)
Delete any env vars you're no longer using
Enable Deployment Protection if you haven't already

The relief

My service hasn't really reached anyone yet. Few subscribers, no paying users yet. If the leaked key had been exploited, the blast radius was… honestly, close to nothing.

That's luck, not good practice.

In a universe where this project was six months older and had real traffic, a compromised email API key could have meant someone sending spam from my verified domain, burning my sender reputation, and me finding out three days later when delivery rates cratered.

The time to mark env vars as sensitive is when you create them. Not after an incident.

What I'm changing going forward

Three things:

1. Sensitive flag is the default, not the exception

Every new env var starts as Sensitive unless there's a specific reason it can't be (like needing it in the Development environment for local proxy testing).

2. Secret rotation is a quarterly habit, not an emergency

The value of rotating keys every 90 days isn't that you expect a breach. It's that if one happens, the window of exposure is bounded. Even loosely-stored keys can only do so much damage if they're less than 90 days old when leaked.

I'm adding a calendar reminder. 4 reminders a year, 10 minutes each. Trivial cost.

3. Third-party AI tools are supply chain dependencies now

This breach didn't come from Vercel's security posture. It came from an AI tool one employee used. The attacker didn't need to crack Vercel — they just needed to compromise a vendor that had access to a Vercel employee's account.

Every AI integration in your dev workflow has some access scope. It reads your repo, or your terminal, or your cloud console, or your credentials. That access is attack surface.

I'm going to start writing down, in a flat text file, every AI tool I've authorized on what scope. Not to get paranoid — just so I know what to rotate if one of them makes the news.

TL;DR

I was in the affected subset. Found out via the dashboard tag, not email.
10 minutes of cleanup: new key → update env → redeploy → verify → revoke old → mark sensitive.
Lucky the project was small. In a larger context, this could have been bad.
Going forward: Sensitive flag by default, quarterly rotation habit, AI tool access log.

Three cups of tea. No coffee. Still tired. Good day to log a lesson.

5 Claude Code Workflows I Use Every Day (For the Boring 80%)

Kai — Mon, 20 Apr 2026 05:47:32 +0000

People keep asking me what my Claude Code "prompts" are.

I don't really have prompts. I have workflows. Small, boring, repeatable things that each save me 10-30 minutes, and at the end of a day add up to why I can keep shipping around a day job.

Here are five I use almost every session.

1. "Before you edit, grep."

When I hand Claude Code a task that touches something broader than a single file — a rename, a pattern change, a refactor — I start the session with one directive:

Before you edit anything, grep for all occurrences of X. Show me the list. I'll tell you which ones to change.

That single sentence has prevented more bad edits in my repos than any test suite. It forces the AI to enumerate the scope before it takes action, and it gives me a natural "stop, this is too big" moment.

The cost is 15 seconds. The upside is not finding out three hours later that it renamed something in a migration script.

2. "Write the test first. Fail it. Then fix it."

Not because I'm a TDD purist. I'm not. But AI is weirdly good at writing confident code that does the wrong thing, and tests are the cheapest way to catch that.

My actual phrasing:

Write a failing test for the bug I just described. Run it. Confirm it fails for the right reason. Then write the fix. Then re-run.

The "run it. Confirm it fails for the right reason" is the key. Tests that pass by accident are worse than no tests — they give false confidence. Forcing the AI to watch its own red-to-green transition catches the subtle "test was wrong, code is actually broken" cases.

3. "Explain, then diff."

When I'm learning something new — a library API, a framework pattern, a language feature — I don't let Claude just write it for me.

Before writing code, explain what you're going to do in plain English. What calls what. What the state machine looks like. Then write the diff.

Without this, I end up with working code I don't understand, and understanding-debt compounds until I get burned on the second or third iteration.

With it, I read three paragraphs and then review a diff. My comprehension stays current, and my edits are informed.

4. "Grep my notes first."

I keep a flat directory of .md files with notes from past sessions. Problems I solved, patterns I chose, decisions I'd regret if I forgot. Not a fancy system. Just markdown.

When I start a new session on a related topic:

Read ~/notes/ (look for filenames matching the topic). Summarize what I've already decided before suggesting anything new.

This catches the "we already tried that and rejected it" case before I waste an hour rebuilding the rejected path. It also forces me to keep writing those notes, because now they have a feedback loop.

5. "Pick one. Ask before the others."

When I give Claude a list of 4-5 things to do, it used to just plow through all of them. Sometimes halfway through it would change its mind about #1 based on what it learned in #3, and I'd end up with an inconsistent mess.

Now:

Do #1. Stop. Show me what you did. Wait for me to say continue.

Multi-step autonomy is great for well-scoped tasks. For fuzzy ones — anything exploratory, anything touching architectural decisions — forcing a checkpoint between steps keeps the work coherent.

Opus 4.7 is better at self-checkpointing, but I still add this explicitly when the stakes are non-trivial.

The meta-workflow

What these have in common:

Cheap to run. None of them take more than 30 seconds of me typing or 60 seconds of Claude thinking.
Fail loud. If they break, I know immediately, not three hours later.
Compound. Each one is worth a few minutes. Stack five of them and the day opens up.
Boring. None of them are clever. They're just discipline encoded in a sentence.

I used to write long system prompts. I don't bother anymore. Five short workflows, applied ruthlessly, outperform any clever preamble.

Three cups of tea, no coffee, still tired. Shipping anyway.

Claude Opus 4.7 Field Report: Eight Hours of Autonomous Work

Kai — Mon, 20 Apr 2026 00:53:14 +0000

Anthropic released Claude Opus 4.7 yesterday. The headline feature is hours-long autonomous work without constant course-correction.

I put it to the test on something real. Here's the field report.

The task

A side project of mine had a scheduled-post automation that had been broken for about a week. Posts were going out at wrong times. The root cause could have been timezone handling, API auth, queue state, or all three. I wasn't sure.

I gave Opus 4.7 this:

Find out why scheduled posts are firing at wrong times. Check the scheduler code, the API responses, the timezone handling in the storage layer, the queue state, and the actual fired-post logs. Fix the underlying issue. Don't just patch the symptom.

Then I went to do other things for about 8 hours.

What actually happened

It didn't fix the bug in 8 hours. But it did something more interesting.

It:

Reproduced the bug reliably.
Instrumented 4 different layers of the stack with debug logs.
Wrote a test harness that fired fake posts through the pipeline with controlled timestamps.
Identified that the bug was actually two bugs, not one — one in my storage layer (naive local timestamps), one in the scheduler (assumed UTC input).
Proposed a fix for the storage layer that would require a one-time migration of existing data.
Stopped there and asked me whether the migration was acceptable.

That last bullet is the thing. Earlier Claude releases would either:

Just charge ahead and migrate (scary)
Stop way earlier and ask what to do (annoying)

This version did a long stretch of investigative work, correctly identified a decision that needed human input, and parked there. That's the skill level I've been waiting for.

Where it drifted

Three places.

1. Scope creep on the test harness.
I asked for a fix. It wrote a fairly elaborate test suite as part of the investigation. Useful, but not what I asked for, and it ate context window.

2. It over-explained the storage layer bug.
The explanation was correct but long. Three paragraphs when one sentence would have worked. Earlier releases were more concise.

3. It assumed my time zone from context.
I hadn't told it what TZ I was in. It inferred from some filename references. It inferred correctly, but I'd rather be asked than guessed at. This is a tiny thing.

None of these are blockers. They're polish issues.

What didn't drift

The parts that mattered held up.

It stayed on task for the full session without me re-anchoring it.
It didn't hallucinate API shapes — when it wasn't sure, it read actual responses.
It wrote diffs I could read and approve line by line.
It caught a genuinely subtle second bug that I had missed in my own debugging earlier.

What this actually changes

For me, the jump from Opus 4.6 to 4.7 is the jump from "pair programming assistant" to "junior engineer with better taste than me on average, but who still needs to check in."

That's a qualitative shift.

Before 4.7, I would ask for scoped single-file tasks and stitch the results together. After 4.7, I can give multi-layer tasks that cross files, modules, and domains, and the output is coherent.

The work I used to do — context stitching, keeping state across sessions, reminding the AI what we were doing — that work got cheaper this week.

What it still can't do

Decide whether a product is worth building
Decide what a feature should feel like
Pick which bug is worth fixing first
Explain to a user why their workflow is wrong

The interesting part is still mine.

Practical takeaway

If you're already using Claude Code or Claude through an editor:

Give it bigger tasks than you used to. It can handle them.
Still ask it to stop before destructive actions. That behavior is there now, but it's still polite to scope it.
Don't bother with "think step by step" — that's implicit at this level.
Read the diffs. You'll learn things.

If you weren't using Claude before: this is probably the release worth trying.

Eight hours of autonomous work, two real bugs found, one fix migration decision parked for me. Net positive. Still tired.

My AI-Heavy Indie Stack (Actually Honest Breakdown)

Kai — Mon, 20 Apr 2026 00:52:33 +0000

A few weeks ago I posted a thread that ended with "here's the setup, in honest detail:" — and then I didn't deliver the detail.

That was bad form. Let me fix it.

This is the actual stack I use to ship indie projects around a day job, with ADHD eating my executive function most days. It's not impressive. It's just relentless.

The bottleneck isn't what people think

The thing AI changed for me isn't code quality. It's sequencing.

I can think the whole product. I can describe it in three paragraphs. The break in my workflow happened between "I know what I want" and "here are the 40 micro-decisions required to start typing." That gap used to eat days.

With AI handling the sequencing, the gap became minutes. I stopped losing evenings to paralysis.

That's the whole value prop, for me. Everything below is just tooling around that insight.

The stack

Primary driver: Claude Code

Not Cursor, not Copilot. Claude Code in a terminal. Here's why:

Multi-file edits with intent: "make this template work for a pricing page instead" and it touches 6 files correctly.
Explains what it changed: I read diffs and actually learn.
Headless, keyboard-only: which matches how my attention works.

Cursor is great if your brain likes inline completions. Mine doesn't. Copilot is fine if your code is boring; the moment I go off-pattern, it fights me.

The right AI tool is the one that matches your cognitive style, not the one with the best marketing.

The boring glue: bash

About 30% of my time is Claude Code. Another 20% is tiny bash scripts that do things like:

rename 40 files from post-v1.mdx to post-0001.mdx padded
download all images from a list, resize, optimize
grep my notes for every TODO that's older than two weeks

I don't write these scripts. I ask for them. Done in 90 seconds. I don't remember them. I keep a bin/ folder of one-liners I've forgotten writing.

Task memory: sqlite at `~/.local/tasks.db`

One table. id, what, status, updated_at. That's it.

When I start a session I run tasks wip and it tells me what I was mid-way through. When I shelve something I run tasks park <what>. It's a 30-line Python script wrapping sqlite3.

This one tool has done more for my shipping velocity than any "productivity app." Because I can't hold state in my head, and a database can.

Surface: dark mode everything, terminal-first

I don't have a strong opinion on editors. I use VS Code because it opens. But the surface I actually work in is the terminal: tmux + a vim split + claude code running in another pane.

Light mode is a tax on my eyes. Coffee is a tax on my ADHD. I optimize around not paying taxes I don't need to pay.

Fuel: tea, not coffee

This isn't a quirky brand — it's a real choice. Caffeine amplifies my ADHD symptoms. Coffee gives me 90 minutes of rocket and then 6 hours of fried circuits.

Tea, specifically black tea with milk, gives me enough alertness without the crash. Three cups a day, stop by 4pm, sleep is protected.

The whole indie workflow collapses if sleep breaks. Everything else is negotiable.

What the stack isn't

It isn't a framework. Nobody else should copy this exactly.

It isn't fast. Anyone watching me work would think I'm slow. I stop constantly to check what I did. I talk to myself out loud. I forget.

It isn't about discipline. Willpower is the first thing to go. The stack exists so willpower isn't in the loop.

It isn't AI doing the work. The AI handles sequencing. I still make every decision that matters — which product to build, what the thing is for, who it's for. That part hasn't gotten cheaper.

What changed

Before: evenings and weekends were a coin flip between "ship something" and "stare at the terminal for 3 hours and give up."

After: evenings and weekends are a coin flip between "ship something" and "ship something smaller." The terminal no longer stares back.

That's it. No 10x, no "unlocked creativity." Just the gap between idea and execution got cheap, and now I can afford to try things.

The part the stack can't do

Distribution.

You can build three templates in a weekend with this setup. Finding anyone who cares about them is a completely different skill, and I'm bad at it. I'm learning. Slowly.

That's tomorrow's post.

Nothing clever. Just relentless reduction of the parts that burn out.

Claude Code as Executive Function: My ADHD-Brain Setup

Kai — Sun, 19 Apr 2026 10:46:10 +0000

I have ADHD. Verbal skill outpaces my motor planning by a lot — the gap measured on neuropsych testing is around forty points. That sounds abstract, but in practice it means I can think through a problem in full, narrate the solution out loud, and then sit down at my desk and watch the plan evaporate before any of it becomes code.

For years I treated this as a discipline problem. More lists. Better systems. Time blocks. It never stuck, because the bottleneck was never motivation. The bottleneck was the bridge between knowing what to do and actually doing it.

Then I started using Claude Code seriously, and the bottleneck got cheap.

This isn't a productivity-hack post. It's an honest writeup of the setup I use to get things shipped on days my brain would otherwise lose them. If you have ADHD, or you just find yourself with too many ideas and not enough execution, some of this might transfer.

The gap

Non-ADHD folks I've asked describe the task-to-action flow like this: "I think of what to do, then I do it." There's no perceptible step in between.

My version has a perceptible step, and it's expensive. A task gets thought of, sits in working memory, waits for motor planning to convert it into action, and — most days — quietly falls out of working memory before anything happens. The more complex the action (switching contexts, opening the right file, remembering the exact syntax), the more it costs, the more likely it drops.

I can reliably do small things. Big things require the brain to chain small things without dropping any. That chaining is the part that's broken.

Traditional productivity advice is about keeping more things in working memory or writing better lists. Neither fixes the gap — they just give the gap a bigger surface to fail on.

What actually helped

What helped was outsourcing the chain.

Not the decisions. Not the judgment. Those are still mine, and should stay mine. What I outsourced is the part where "I decided to refactor this file" has to become "I now remember the file path, open the editor, navigate to the function, remember the rename convention, write the new code, verify it compiles, commit with a good message."

Every step in that chain is a place where my brain drops the thread. Claude Code handles the chain. I handle the decisions.

The shift feels like this:

Old: think → try to chain → lose thread → frustrate → give up or half-ship
New: think → say what I want → review the diff → ship

I didn't get smarter. I got a prosthetic.

My setup, in practice

Most of the setup is just making Claude Code remember things I'd otherwise re-explain five times. ADHD brains are especially punishing when re-explaining is required — the overhead compounds. The setup reduces re-explanation to near zero.

1. `CLAUDE.md` — the project's memory

Every repo I use Claude Code in has a CLAUDE.md at the root. It holds project-level conventions, voice, tech stack, and anything I'd otherwise forget to say.

For my indie side project, mine contains:

Who I am in this project (an indie builder with specific voice)
Tech stack (Next.js 16, Tailwind v4, TypeScript strict, Framer Motion)
What's live vs. what's pending
Token-efficiency preferences (don't overexplain, just do)
Security rules (never commit PII, grep certain patterns)
Key decisions already made (so I don't get second-guessed)

Claude Code reads this file at the start of every session. I don't have to re-establish context. The AI already knows how I want to work.

This is huge for ADHD. Sessions are fragmented by design — I'll pick up at weird hours, in partial states of exhaustion. Without CLAUDE.md, every session starts from zero. With it, every session starts where the last one ended.

2. `.claude/rules/` — doctrine files it re-reads every session

CLAUDE.md handles the what. .claude/rules/ handles the how.

Mine has three files right now:

content-doctrine.md — voice, tone, overclaim guard, native-English checks
privacy-security.md — PII that must never appear, secrets management
kai-persona.md — the persona I use for my public writing

These aren't tutorials I read — they're instructions Claude Code follows. Each one has a pre-publish checklist, a never-list, and specific patterns to grep for before anything ships.

The practical effect: I don't have to remember the rules. They're enforced automatically.

When I'm tired and about to commit something questionable, the rules catch it. When I forget my own voice mid-article, the doctrine catches it. The rules encode "what past-me already decided" so current-me doesn't have to re-decide it at 2am.

3. Slash commands for the stuff I'd otherwise re-explain daily

I built a handful of commands — markdown files in .claude/commands/ — for things I do over and over:

/morning — pulls world and tech trends, writes them to a daily feed file, then drafts that day's posts for my public account
/sync — updates state files after a decision shift
/resume — one-shot context summary if I jump between sessions
/learn — records a post's reaction so I can find patterns later
/knowledge — loads a topic's knowledge file only when needed

Each command is a markdown prompt. When I type /morning, Claude Code runs it exactly the same way every day. No re-explaining. No variation. No lost thread.

ADHD's enemy is decision fatigue. Slash commands make daily decisions invisible. I don't wonder "what do I do now?" — I just run /morning and the work starts.

4. Pre-commit hooks — protection from my own lapses

I have a pre-commit hook that blocks any commit containing my personal name, personal emails, specific location markers, or API-key-shaped strings.

This is belt-and-suspenders for a very real ADHD failure mode: forgetting to check. On exhausted days I'll paste something into a file I don't remember adding. The hook catches it before it becomes a git history problem.

The hook is maybe 60 lines of shell. It's the cheapest line of defense I've ever added. Twice this week it caught leaks I didn't notice.

What this changed

The shipping numbers changed first. I used to start three things and finish one. I now start two things and finish both, on an average week.

But the bigger change is less visible. I stopped dreading switching contexts. Before the setup, every context switch cost me a 15-minute ramp-up to remember where I was. Now the state files tell me exactly where I was — Claude Code re-reads them, summarizes in ten seconds, and I'm working.

The emotional tax of ADHD dev work is usually in the ramp-up, not the work itself. Killing the ramp-up killed most of the tax.

The other thing that changed: I stopped being mad at myself. Setups like this make the assumption that your brain will drop things — and that's the right assumption for my brain. When I miss something, it's the tool's job to catch it, not my job to have remembered. That reframing, weirdly, is what made the setup stick.

What this didn't change

It didn't cure ADHD. Nothing does.

On bad days I still spiral. The setup shortens the spiral — I can pick up with less context cost — but it doesn't prevent it.

It also didn't make me smarter. Judgment is still mine. Claude Code executes; I decide what's worth executing. When I decide badly, the tool executes my bad decision quickly. A faster bad idea is still bad.

And it didn't eliminate the work. Writing good prompts is its own skill. Writing good specs is harder than writing good code. The execution bottleneck moved. It didn't disappear.

But moving the bottleneck from motor planning to judgment and prompt craft is, for my specific brain, a massive upgrade. Motor planning was the broken step. Judgment and craft are steps I can actually practice and get better at.

If you want to try this

Start with the smallest possible version. CLAUDE.md in your project root, with just the basics — tech stack, voice, and whatever you'd otherwise re-explain every session. That alone is maybe 70% of the value.

Add slash commands for two things you do daily. That's another 20%.

Rules files and pre-commit hooks come later, when you have a specific pattern you keep failing on.

The goal isn't to build the perfect prosthetic. It's to notice where your brain drops the thread, and put one small piece of infrastructure in that exact spot. Then notice the next drop. Repeat.

For me, after a few months of this, I ship things I'd have started and abandoned a year ago. Not because my brain got better. Because the things that don't survive the chain are no longer allowed to matter.

I write about AI-heavy indie workflow, ADHD-adjacent dev patterns, and corporate automation from someone who can't use the good AI tools at their day job. If you want more of this, my newsletter ships weekly — subscribe here.