This is the first path for someone who feels behind but wants real progress today. You will set up one repo, make one small useful change, prove it works, and learn the habits that keep Claude Code helpful instead of noisy.
You do not need to understand every feature before you start. You need one clean loop: ask for a small change, let Claude inspect the repo, review the diff, run a check, and write down what should repeat next time.
Run it in a real repo before reading the rest. The lesson starts when Claude has to inspect something concrete.
Explore this repo. Do not edit yet. Find one small useful improvement we can safely make today. Return: - the likely files involved - the smallest change worth doing - what not to touch - the command, test, or screenshot that would prove it worked Keep it scoped enough that I can review the diff in one sitting.
By the end, Claude Code should feel less like a mystery box and more like a tool you can direct.
You will create useful project context, check what loads into memory, and remove notes that waste attention.
You will turn “fix this” into a clear request with files, constraints, and a proof step.
You will use checks, small diffs, and review points so Claude does not drift past what you asked for.
You will leave with one repeatable prompt, one useful automation idea, and a clear next stop in the Practice Dojo: the rep loop for turning the guide into habit.
/initCreate project context. Then prune it to commands, stack facts, repo guidance, and things Claude would actually get wrong. Done when: the file has the real test/build commands and no long pasted docs.
/memoryLook at what loads before every request. The win is knowing what Claude is carrying, not stuffing in more. Done when: you can name the repo notes, global notes, and one thing you removed or corrected.
Pick a real annoyance and ask for the smallest fix. Require a check: lint, test, screenshot, or command output. Done when: the diff is small enough to review and the proof is visible.
Send exploration out of the main window: “find the relevant files and summarize only what matters.” Done when: your main session receives file names, reasons, and no giant transcript.
Start boring: format after edits, or block edits to secrets. Hooks are for guarantees; project notes are for guidance. Done when: you can trigger the hook and see it pass or block the right action.
Use one that removes real tab switching: GitHub, Context7, Playwright, Supabase, or Linear. Done when: Claude uses the tool for a real answer instead of asking you to paste the same information.
Run a scoped background session or a small /loop. The lesson is knowing what can run while you watch from above. Done when: the task has a clear goal, a stopping point, and a result you can inspect.
Anything you had to say twice becomes a skill, command, hook, or short project note. Done when: a fresh session can repeat the habit without you re-explaining it.
Do not learn in a toy repo. Choose one small improvement in something you actually use.
| Project | What you practice | Done when |
|---|---|---|
| Fix one flaky UI state | Browser verification, screenshots, small diffs | You can reproduce before and prove after |
| Write a PR summary skill | Skills, dynamic context, progressive disclosure | /pr-summary produces a useful draft from live diff |
| Automate a boring check | Hooks, permissions, objective gates | Claude cannot “forget” to run the check |
| Make a repo onboarding doc | Subagents, context pruning, AGENTS/CLAUDE.md | A fresh session can work without a lecture |
Explore this repo. Do not edit yet. Tell me the smallest useful improvement we can make, the files likely involved, and the command or screenshot that would prove it works.
/clear, or rewind/summary when the task changes.When the eight reps are done, do not restart from scratch. Turn the parts that worked into practice.
Use the Practice Dojo when you want reps for a specific habit: better prompts, cleaner context, safer edits, review, testing, agents, hooks, or MCP work.
Move your best request into Prompts language: goal, constraints, files to inspect, proof required, and when to stop.
Run the same loop somewhere else. If the process still works, you are learning the shape of the tool, not memorizing one project.