▶ Watch (2 min): https://youtu.be/g41dnAWhOiU For a long time, when a curious person asked me how to get into Claude Code, I pointed them at the terminal or VS Code. I'm not going to tell people that anymore. Here's what changed — and what's coming. ——— ⚓ Why I'm changing it Honest truth: the first hour on your own in the terminal is frustrating. Install errors, commands that won't run, a screen full of text and no idea what's wrong. Too many curious people quit in that first hour — not because Claude Code is hard, but because the door was hard. ⚓ The new starting point Claude Desktop → the Code button. Same Claude Code, same power — just a friendlier way in. - You can see what's happening — file tree, the plan, the changes before you accept them - It's your IT support — when something breaks, paste the error back in and ask it to fix itself - Nothing's wasted — everything you set up here works the day you open the terminal ⚓ What's coming this week A new lesson — "Start at the Right Door" — plus a short post every day: - Mon — The terminal used to be the only door. Not anymore. - Tue — Three doors, one Claude Code - Wed — Claude Code is your IT department: paste the error, let it fix itself - Thu — When should you graduate to the terminal? Maybe never. - Fri — What you actually give up staying in Desktop (spoiler: not much) The terminal and VS Code aren't going anywhere — they become the "going further" path for when you want more control. ——— The whole idea in one line: start where the power is visible. Climb later, if you ever need to. —Your Trusty First Mate (on Captain's Orders)

Most people give Claude a task and hope the output works. But there's a dead-simple way to make Claude catch its own mistakes before you ever have to — just tell it to build in testing. ——— ⚓ The One-Liner That Changes Everything When you're prompting Claude to plan out a build, add this to your instructions: "Build in testing to ensure everything works before moving to the next phase." That's it. One sentence. Claude will now plan verification steps into each phase of your build instead of barreling through and hoping for the best. ——— ⚓ What Actually Happens When Claude sees that instruction, it breaks testing into three layers — the same three layers professional developers use: Smoke Tests — "Does it turn on?" - Run at the very start of each phase - Check that the basic setup works before writing real logic - Example: After scaffolding a project, Claude runs it to confirm it loads without crashing Unit Tests — "Does each piece work on its own?" - Test individual functions, components, or API calls in isolation - Claude writes a small test, runs it, and fixes anything that breaks before moving on - Example: Testing that a single function returns the right output given a specific input End-to-End (E2E) Tests — "Does the whole thing work together?" - Run after all the pieces are in place - Simulate the full user flow from start to finish - Example: Filling out a form, submitting it, and confirming the data shows up where it should ——— ⚓ Why This Works So Well Without testing in the plan, Claude builds Phase 1, Phase 2, Phase 3... and if Phase 1 had a bug, you don't find out until Phase 3 explodes. Now you're debugging three phases of code to find a problem that started in the first ten lines. With testing built in, Claude catches the bug in Phase 1 before it ever starts Phase 2. Each phase gets validated before the next one begins. Your plan self-corrects as it goes. ——— ⚓ How to Use It You don't need to understand testing theory. You don't need to write tests yourself. Just add the line to your prompt when asking Claude to plan a build:

Someone asked me to help edit a video. I fired up Claude Code, connected a video MCP server, and had the edit done in minutes. Then I thought: why stop at editing? I could automate the entire publish — editing, thumbnails, YouTube upload, Skool post, all of it. One command. So I built it. Honestly? Building the pipeline took longer than editing the video did. But now every future video is a single command away. Here’s how I put it together — and how you can build your own automation pipelines. ——— ⚓ How It Started I needed to edit a video. Instead of opening a video editor, I connected a video-audio MCP server to Claude Code and just told it what to do in plain English: “trim the first 8 seconds,” “remove the silence,” “compress it.” It worked. Fast. But then I was still manually uploading to YouTube, writing descriptions, making thumbnails, posting to Skool. The editing was the easy part — all the publishing busywork around it was the real time sink. So I built a skill that handles the whole pipeline. ——— ⚓ The Solution: /video-publish One slash command. Nine phases. Fully interactive. /video-publish ~/Downloads/my-tutorial.mp4 That kicks off: - Analyze — ffprobe scans the video. Claude flags issues (file too big, silence detected, dead start) - Edit — Claude auto-applies fixes, then drops you into an interactive editor. You type natural language commands like “cut 5:00 to 7:30” or “speed 2x 10:00 12:00” and it maps them to the right tools - Thumbnail — Renders from a locked Remotion template. I just give it 3-5 words - Metadata — Title, description, tags auto-generated from my channel profile. I approve before anything goes live - Upload — Playwright opens YouTube Studio, uploads, fills everything in, publishes - Skool Post — Writes a community recap with the YouTube link - Cleanup — Updates a registry, offers to delete temp files Every step has an approval gate. Nothing publishes without my say-so. ——— ⚓ The Tools That Make It Work