Fourteen ideas, one per screen, from install to hooks. Each is a thing to point at while you explain. The drama is in the watching, so take the silences.
Four moves: see what the agent is, get it running, drive it day to day, then make the must-haves guaranteed.
A coding assistant sits on a spectrum. At one end it guesses your next line; at the other it reads your project and does the work.
An agent doesn't just talk about the code. It works inside your terminal and your repo: reading files, editing across them, running commands, and deciding what to do next.
You ask in plain English. Claude reads the relevant files, makes the edits, runs them, and shows you the result to review.
The course demos this on a small UI-generation app (uigen), but nothing is special about it: you can follow along on a codebase of your own.
One line in your terminal, whatever the platform. Then run claude, pick a theme and sign in.
Hit a "command not found", network or permissions error? The docs' "Troubleshoot installation" page is the first stop. Running through Bedrock, Vertex or Foundry has its own setup.
Claude Code is more interesting with something to work on. The course ships a small UI-generation app to explore.
The Anthropic API key is optional; it only powers the app's own UI generation. Node JS is the one real prerequisite.
Claude only knows what's in its context window. You pull the right files, output and rules in before you ask.
Be specific about what matters. The less Claude has to guess, the less it wanders, and the less context (and money) each run burns.
You say what you want; Claude edits across the files and shows you a diff. You approve, refine, and only then commit.
You stay in control: every edit is reviewable, and you can steer, undo or redirect before anything lands in the repo.
A long session fills the window. Three commands keep it focused on what matters now.
Clear between unrelated tasks; compact to keep a long thread alive; check /context when answers start to drift; that's usually a full window.
A prompt you type often becomes a slash command: a Markdown file Claude runs on demand.
Anything you find yourself re-explaining (a review checklist, a release routine) is a candidate. Write it once; call it with a slash.
Key conceptRuntime parameters: $ARGUMENTS takes everything the user typed; $1 $2 $3 take positional args. → full detail (!`cmd`, @file, argument-hint) in the teacher notes.
Most of what you need lives in other systems: issues, docs, databases. MCP connects Claude Code to them as tools.
Watch the cost: every server loads its tool definitions into context whether you use them or not. Add what you need, and disable the rest with /mcp.
Key conceptRunning MCP in GitHub Actions takes a two-level permission model: configure the server (--mcp-config) and allow-list each tool by name (mcp__server__tool). Both are required. → full detail in the teacher notes.
Claude Code drives the GitHub CLI to commit, push and open a PR, and the GitHub app can run it in CI when you mention it.
Top row is you, locally. Bottom row is hands-off: tag @claude on an issue or PR and the GitHub app runs Claude Code in CI to triage, review or implement.
Asking Claude to "always run the formatter" is a request it might forget. A hook is a shell command that runs every time, no exceptions.
The purpose of a hook: turn what you'd ask Claude to do into what always happens. Run by the harness, not the model. If something must happen every time, don't put it in a prompt. That's what moves a team from "we'll review it after" to "it can't happen in the first place".
Key conceptPrompts are probabilistic; hooks are deterministic. That's the whole point. → the three shapes (guarantee / block / inject context) are in the teacher notes.
A hook is three things in settings.json: which lifecycle event, which tool it matches, and the command to run.
PreToolUse is the one hook that runs before a tool, so it's the only one that can stop a call: exit 2 (or return "permissionDecision":"deny") and the rm -rf or the commit to main is blocked before it happens, not after.
Key conceptThe hook sees the tool name and its input, so you gate on conditions: block Bash on a deny-list, or any edit touching .env. → teacher notes for the deny/allow/ask decisions.
Two real problems the course solves: sharing hooks across machines, and knowing the shape of the input a hook receives.
The input on stdin changes per event and per tool, so log it first. Absolute paths are recommended for security, which is why shared settings use a $PWD placeholder that setup expands.
The same agent you run in the terminal can be embedded in your own scripts and apps through the SDK.
Wrap the agentic loop (tools, context, permissions) inside your own software, and Claude Code stops being just a CLI and becomes a component you build on.
Install Claude Code, work the edit-and-review loop, connect it out with MCP and GitHub, then lock in the must-haves with hooks, and build on it with the SDK.
tutto.one/praxis · daniel@tutto.one