Claude Code New Features, Explained

1. Desktop Code tab + self-explaining repo · 05:47

• Runs Claude Code inside the Claude Desktop app — “a lot less overwhelming than in the terminal.” Select a project folder as the workspace.
• Repo layout he asks Claude to create: /app (product), /context (business brain), /customers (calls, objections, customer language), /spec, /demos (Loom scripts, screenshots), /routines.
• Three root manuals: CLAUDE.md (how to work), roadmap.md (what matters now + out of scope), review.md (shipping checklist). Line he repeats: Claude is “just way more useful when the project explains itself.”

2. Plan mode (brief before edits) · 14:53

• For meaningful product work: inspect the app + the three manuals, then propose files to change, smallest clean implementation, UX, risks, verification, and what V1 leaves out — wait for approval before editing.
• He treats this as measure-twice-cut-once. Planning can use a cheaper/faster model (transcript: “Fable” over Opus; also “Opus 4.8” / “Fable 5” — ASR-uncertain, not verified here).
• Live ticket: add a waitlist form (name / email / company + success state). He then constrains: frontend-only, or connect to Supabase, or “don’t touch auth / payments / DB yet.”

3. One ticket, one finish line · 18:08

• Good: add waitlist form; pricing page from the existing design system; fix onboarding redirect after email verification; turn five customer objections into a landing-page section.
• Bad: “make the app better,” “make this more viral,” “add AI,” “build the whole thing.” Vague tickets force guessing; “once it starts guessing, you’re no longer managing the work. You’re cleaning up the work.”
• After approve: implement as one focused change, small enough to review in the diff; run checks; open desktop preview; summarize what changed / tested / still needs a human.

4. Eyes — desktop preview + computer use · 22:15

• This is the piece he flags as newly usable: “you can finally do this in Claude Code.” After a build, Claude should open the app in desktop preview, click the flow, check console / network / mobile, and report what a buyer experiences — not only edit files.
• Loop: build → run → use → test → improve. Demo: empty-submit, success state, backend write, then one focused pass (he accepted microcopy that the waitlist isn’t spam).
• He says this is “amazing how few people actually use the eyes.”

5. Review layers + Desktop diff · 26:13

• Human layer: Desktop diff view — click changed files, leave comments, ask for revisions. Watch for surprises (e.g. a waitlist ticket that also touched auth / routing / DB).
• Standards layer: ask Claude to review against review.md and split must fix / should fix / okay to ship (bugs, confusion, security, extra complexity, out-of-scope files, roadmap violations).
• Slash commands he shows: /review for ordinary review; /ultra review for a remote session before risky production work (auth, payments). Transcript also says “ultra view” — treat the exact command name as on-screen, not ASR.

6. Routines (“night shift”) · 29:34

Scheduled recurring work Claude Code calls routines. He would not start by shipping production code while asleep — start with a controlled operator task.

“Night shift” = work stays organized, feedback gets summarized, risks surface, next tasks get clearer — not unsupervised deploys.

7. Parallel agents + worktree isolation · 34:32

• Desktop Code tab can run separate sessions with isolated changes via worktree isolation so edits don’t mix.
• Example morning trio, each with the same project context and a specific handoff: (1) onboarding-redirect bug → root cause + files + checks; (2) landing hero clarity in five seconds → before/after + customer language; (3) demo script from notes → pain / product-moment / payoff.
• Goal: inspectable packets you can accept / revise / reject — “you don’t want a giant pile of AI work at the end of the day that you have to untangle.”

8. Permissions as delegation · 39:14

Desktop has permission modes. Start conservative; use plan mode for bigger changes; avoid YOLO. Speed up only as the repo brain, review checklist, and ticket scope get stronger.

9. Skills, connectors, hooks · 41:15

• Skills = repeatable prompts. “If you find yourself typing the same prompt over and over again, chances are that should just be a skill.” His examples: landing-page teardown as a med-spa owner (5-second clarity, vague copy, trust, CTA); customer-notes skill (exact words, objections, buying triggers); demo-script skill (pain / moment / payoff). He says marketplaces exist; he does not name them.
• Connectors = context plugins. He names GitHub, Linear, Google Drive, Slack.
• Hooks = guardrails: format after edits; tests before a PR summary; checks before a change ships.

Combined with roadmap / review / customers / routines, this is his claimed moat: bespoke outputs, not a generic coding chatbot.

Seven-day copy plan · 44:28

1. Create the repo brain (CLAUDE.md, roadmap.md, review.md, /context, /customers).
2. Plan mode on one small product task (plan, file list, risks, verification).
3. Build one visible improvement (waitlist, pricing page, demo flow, or onboarding bug).
4. Preview loop (desktop preview, click-through, mobile, clarity).
5. Review: Desktop diff + review.md (and the review slash-command flow for a serious change).
6. Send the Loom / demo / landing page to ~10 people; dump replies into /customers.
7. First routine (morning brief → one recommended build task).

Closed loop: feedback → /customers; direction → roadmap.md; working style → CLAUDE.md; quality → review.md; small tasks through plan mode; changes through preview + review; recurring work as routines.