Week Two Past The Basics

Week Two.

You're set up, you've run a skill, you've got the model habit. This is what's left — the moves that separate "I use Claude" from "Claude is genuinely part of how I work."

00 — PARALLEL WORK

Big sweeps don't have to be sequential.

When a task is genuinely one thing — write this function, fix this bug — do it in one conversation. But some tasks are actually many independent things: audit every texture in a folder, review a dozen unrelated PRs, sweep the whole project for a pattern. For those, ask Claude to split the work itself.

Say the shape, not the mechanism

"Audit every material in /Game/Characters for missing LODs — there are about 40, split the work up and go" is enough. You don't need to know how Claude organizes it internally.

Expect a summary, not a play-by-play

Parallel work reports back as a consolidated result — what was checked, what was found, what needs your judgment. You review the findings, not forty transcripts.

Reach for it on real breadth, not small jobs

Five files? Just ask directly. Splitting adds overhead that only pays off once the job is wide enough that doing it serially would actually take a while.

01 — WHEN TO GO BEYOND SONNET

Fable 5 is the ceiling, not the only option above Sonnet.

The plan-in-Fable, build-in-Sonnet habit covers nearly everything. Occasionally something is genuinely stubborn — a bug that survives two real attempts, a design decision with real consequences riding on it. That's worth a deliberate step up, not a third attempt at the same altitude.

01

First, try reframing before you switch models

Half of "stuck" is under-specified context, not under-powered reasoning. Give Claude what you've already ruled out, what you've already tried, and what "solved" would look like — often that alone unsticks it.

02

Then, escalate deliberately

If it's still stuck, Opus 4.8 exists above Fable 5's everyday tier for the rare case that needs even more depth — slower and costlier, so reach for it on purpose, not by default. /model to switch, same as always.

03

Escalating is not a failure state

A senior engineer pulling in a second opinion on a hairy bug isn't a bad look — it's good judgment. Same logic here.

02 — REVIEWING CLAUDE'S WORK WELL

The skill most people skip learning.

A

Ask for the reasoning, not just the diff

"Why this approach and not X?" surfaces assumptions before they ship, and it's often faster than reading the code cold.

B

Ask what it didn't do

"What edge cases did you not handle?" gets an honest list more often than silence would suggest there isn't one.

C

Verify, don't just trust "should work"

The whole site's running theme: if it didn't build it, run it, or test it, it doesn't actually know. Ask it to check before you do.

03 — WRITE YOUR FIRST SKILL

The highest-leverage thing on this page.

Every skill in the library started as one person's annoyance with a wrong answer. If you've been at this two weeks, you've almost certainly corrected Claude about something studio-specific at least once. That correction is a skill waiting to be written.

Go do it

The template, the example, and the form — all on one page.

The Contribute page has the five-minute version: what a skill file looks like, a before/after example, and a checklist from noticing the friction to opening the PR. If five minutes feels like too much right now, the same page has a 30-second form that does it for you.

← Prev
Contribute