Gnothi Claude Code

OCDevel

Take Claude Code from its first useful change in your terminal to a repeatable software delivery workflow. For working developers who already ship applications and use Git, this course starts with setup, giving Claude a task, inspecting the diff and checking the result. Build on that session with project instructions, skills, hooks, MCP connections and context management. Later lessons connect parallel agents and Git worktrees to GitHub issues, pull requests and review-and-fix loops, then develop testing and deployment workflows with GitHub Actions and AWS. Permissions, sandboxing, cost controls and observability are taught alongside the automation they support, so you can judge what a run changed and investigate a failure. Concrete examples explain the commands, settings and checks behind each workflow; earlier techniques return as parts of larger systems. Claude Code news and practical shortcuts cover changes that affect coding work, setup or cost. The curriculum builds toward an issue-to-deployment pipeline, including rollout decisions and incident response. This show's audio is narrated by AI-generated synthetic voices.

Episodes

  1. 2 days ago

    7. Letting the Agent Read the Issue Itself

    A fast-add bug becomes a GitHub issue that Claude Code reads through GitHub's MCP server, with read, comment and delete tools each given their own permission. The bug is then fixed against the issue's acceptance criteria, and MCP is weighed against the gh CLI and a small script. Recent Claude Code releases that affect MCP, hooks and unattended runs close it out. This episode is narrated by AI-generated synthetic voices. Episode page & show notes Visit website A tracked issue for the fast-add bug The bug that makes a second, quickly added item vanish from the screen gets written up as GitHub issue twelve. The issue has a plain problem statement taken from the reproduction note and two testable acceptance criteria. No item vanishes when two are added quickly, and a reload shows the same list the screen showed. Adding GitHub's MCP server MCP, the Model Context Protocol, lets Claude Code take on extra tools from a separate server. It is separate from the Claude API and the Agent SDK. GitHub's remote server is added at project scope, so it is written to a committed .mcp.json. A personal access token comes in through an environment variable placeholder, so the token itself never lands in the file. Teammates who clone the repo must approve the server before it runs. claude mcp list and claude mcp get github confirm the connection is healthy. Sorting tools and setting permissions The /mcp manager lists the server's tools, which split into reads and writes: Allow: get_issue and get_issue_comments Ask: add_issue_comment Deny: the delete tools An allow wildcard must follow a literal server prefix. Deny beats ask, and ask beats allow. Tool search keeps tool definitions deferred until the model needs them. One small test comes first: the agent reads issue twelve word for word, and the reply is checked against the browser. Issue text describes the task. It is never an instruction to the agent. Fixing from the acceptance criteria The fix changes each save so it adds its own item to the current list. Before, each save wrote back a stale copy of the list. Disabling the add button would not meet the criteria. A regression test is confirmed to fail on the old code and pass on the new one. After that comes the full suite and a manual check in the app, both before and after a reload. The agent drafts a comment on the issue, which waits for approval before posting. The issue stays open. gh, a script, or MCP The gh CLI: low context cost and low upkeep, but viewing and commenting are hard to tell apart for the permission system. A committed REST script: the lowest context cost, but you maintain it and it can only do what you wrote. MCP: the most operations, each with its own permission rule, but the highest context cost. The rule: built-in tools first, a script for one fixed step, MCP when you need many operations with separate control over each. Recent Claude Code releases 2.1.300: fixes tool search switching itself off after a resumed session reconnects. It also validates hook-rewritten tool inputs against the tool's schema. 2.1.302: fixes servers on the July 28, 2026 protocol version that could show zero tools. Unattended runs: claude -p and the Agent SDK may now start in default mode on third-party providers, so pass the auto permission mode explicitly if a script relied on it. 2.1.301: adds a setting that aborts a request when a usage limit would reset too far in the future. Hook cap: prompt and agent hooks are capped at twelve running at once per event, with extras queued.

  2. 10 Oct

    6. Writing a Method Down Once as a Skill

    Building a Claude Code skill that turns bug reports into a four-part reproduction note before any code changes, including how skills differ from CLAUDE.md and hooks and how to test and fix a skill's description. Also covered: early October Claude Code updates to hooks, debug logging and Sonnet 5.5 cache pricing. This episode is narrated by AI-generated synthetic voices. Episode page & show notes Visit website Skills, CLAUDE.md and hooks The routine for reproducing a bug is a method, and it only matters for certain tasks. CLAUDE.md is read in full every session, so it suits standing rules. A hook is a command Claude Code runs at a set moment whether or not the model remembers. A skill is a method written down once. At startup only its name and short description are read. The model loads the full body with the Skill tool when a request matches. The rule of thumb: a procedure belongs in a skill, and anything a machine must enforce belongs in a hook. Building reproduce-bug A project skill is a folder under .claude/skills/ containing a SKILL.md with frontmatter. The frontmatter needs a name and a description, and the description is the only part the model sees when it decides whether to load the skill (Claude Code skills docs). This skill's description does three things: it names the result, lists the words real bug reports use, and excludes feature requests, refactoring and styling. disable-model-invocation stays off because the skill has no side effects. The body sets out five steps. The agent restates the report as exact steps, records the data, reproduces the bug twice from a clean state, and traces the code read-only. Then it stops with a four-part note: steps, data, observed result and expected result. The body stays well under the guidance of roughly five hundred lines (skill authoring best practices). Testing and fixing the description To test, restart the session and check /skills. Then run a positive test with an emoji bug report, which should load the skill, and a negative test with a sort-button feature request, which should not. A vague description like "Helps with problems in the app" loads the skill on feature work. A narrow one like "Use for reproduction notes" never loads it. Both are fixed by rewording the description, not the body. The disappearing item On the made-up report "Sometimes when I add things fast, one of them disappears," the trace points at a second submit while the first save is still in progress. In the illustrative manual check, the item vanished both times and came back on reload: it was saved, and the screen dropped it. The fix is left for a separate task. The skill gets committed, and CLAUDE.md gains one line pointing to it. Bringing in real issues and logs is left to MCP. Early October Claude Code updates According to the Claude Code changelog, versions 2.1.289–2.1.296 shipped these changes: An onFailure: "block" option for command and HTTP hooks. Hook tracking in debug mode. Sonnet 5.5 cache reads halved to ten cents per million tokens, now reflected in /cost and the status bar. A fix for lost final messages when a session ended. Patches for several shell permission bypasses.

  3. 3 Oct

    5. A Check That Runs Without Being Asked

    Moving the type check from something you remember to run into a PostToolUse hook that Claude Code runs after every edit, feeding errors back so the agent fixes them before finishing. Also covers this fortnight's Claude Code changes to hook failure handling, sandbox fixes and headless time limits. This episode is narrated by AI-generated synthetic voices. Episode page & show notes Visit website Turning the type check into a hook The routine still relied on memory for two steps: running the type check and running the tests. An example shows the gap. A request to add an optional note field to list items looks fine in the browser. Then the compiler fails on a shared-view component the agent never opened, because the note was marked required by mistake. CLAUDE.md is an instruction the model can skip. A hook is a command Claude Code itself runs at a defined moment, every time. The chapter wires the project's no-emit TypeScript check to the PostToolUse event with an Edit|Write matcher, as described in the hooks guide. It lives in the committed project settings file so everyone working in the repository gets it. Exit codes carry the meaning, per the hooks reference: Zero stays silent. Two hands the compiler's stderr back to Claude to fix. Any other code is a non-blocking warning. The build starts small: a hook that only logs "hook fired." It is confirmed with /hooks, and a file read is shown not to trigger it. The logger is then replaced with a committed script. The script reads the event JSON with jq, skips non-TypeScript files, and checks the whole project, because the note bug lived in an untouched file. It runs through CLAUDE_PROJECT_DIR with a 120-second timeout. The test suite stays out of the hook because it is too slow to run after every edit. The hook is proven by breaking types on purpose, then by making a correct edit that should produce no output. Where hooks go wrong Four risks are covered: Cost: every second the hook takes is added to every edit. Setup failures: a missing tool or uninstalled dependencies should exit one, not two, so the agent isn't sent to fix errors it didn't cause. Repair loops: start from a clean type check, and step in if the agent goes in circles. Trust: hooks run with your permissions without a prompt, so review them like code. disableAllHooks turns off custom hooks but not hooks from an organization's managed settings. The work ends with a commit and one line in CLAUDE.md explaining where the type errors come from. This fortnight's releases The Claude Code changelog covers versions 2.1.286 through 2.1.288: PreToolUse and PermissionRequest hooks now fail closed. Shell sandbox escapes through nested bash -c and symlinked writes are patched. Background time limits are strictly enforced in headless runs, CI and the Agent SDK. Up arrow on an empty prompt restores a request cleared with Control C. /code-review accepts a max-findings option.

  4. 26 Sept

    4. A Change Too Big for One Session

    How to carry a multi-step change across several Claude Code sessions by keeping its plan, decisions and progress in committed files. It covers continue and resume, reading /context, compaction and what it loses, and a deliberate fresh start, plus recent fixes to resuming and compaction. This episode is narrated by AI-generated synthetic voices. Episode page & show notes Visit website A change that outlasts one sitting The conversation with Claude Code is not memory you can rely on. The repository is. The worked example is a done checkbox for items in the shared-list app. It needs a schema migration, a way to set the flag through the database client, a checkbox and crossed-out style in the React interface, and tests. The check at the end is to tick an item, reload the page, and see it still ticked. Planning happens in plan mode. The plan goes into a committed file of numbered steps, each with a check that proves it is done. A second file records decisions and rejected options, such as choosing a boolean column over a status text field because the app has only two states and a boolean cannot hold a typo. Stopping halfway and coming back After two committed steps the session ends. claude --continue reopens the most recent session. claude --resume opens a picker with preview, rename and filter, all described in the guide to managing sessions. Resuming restores the conversation, tool results, model and recent checkpoints. It does not restore launch-time folders or elevated permission modes. It also brings back stale guesses and knows nothing of hand edits made since. When the context window fills /context breaks usage into messages, memory files, tool schemas and skills, and the messages row is the one that grows. Compaction replaces older turns with a summary. The root CLAUDE.md is reread and the active goal survives, but exact names and the reasons behind decisions tend to get lost. You can steer the summary with instructions after /compact or with a compact instructions section in CLAUDE.md. A summary is still written by the model. When it and the committed decisions file disagree, the file wins. A deliberate fresh start The handoff has four steps: Have the agent update the progress file. Check each tick against git log and the code. Commit the file. Run /clear. The new session reads the task files, git log and the diff, then reports the state of the work before editing anything. If its account is wrong, the gap is in the files. Keep plans to steps and checks. Rules for every task go in CLAUDE.md, and notes for one task go in the task files. Auto-memory stays on your machine and is not committed, so it cannot replace the task files. Recent fixes to resume and compaction The Claude Code changelog records several relevant changes: 2.1.274: Resuming a compacted session no longer drops its goal. Goal- or hook-driven sessions compact instead of crashing with "prompt too long" on the second overflow. Damaged transcripts are repaired, or resume stops with an error that suggests rewinding. 2.1.282: Resuming long sessions is faster. This does not make the session aware of edits made after it last looked. Context accounting: Tool-server instructions now get their own row in /context. 2.1.283: Compaction shows an elapsed timer and a live count of summary tokens. Claude Opus 5.5 defaults to a one-million-token window, so auto-compaction triggers later, which makes the handoff habit more important.

  5. 19 Sept

    3. Fixing a Bug in Code You Have Never Read

    A vague pasted-text bug report gets turned into a reproduction, then traced with an agent that is blocked from editing anything, then fixed one narrow diff at a time. Includes how plan mode actually enforces its limits, how to check an agent's account of your code, and the case where the tests pass but the browser is still broken. This episode is narrated by AI-generated synthetic voices. Episode page & show notes Visit website A vague report becomes a reproduction "It keeps saying the name is too long when it isn't. Only happens when I copy the name in from somewhere else." No file, no error text, no browser. The work starts by turning that sentence into four written things: exact steps, exact data, observed result, expected result. The data is the clue — a line copied from a notes app, nine visible characters, carrying a trailing space and a newline. Reproduced twice from a clean state, so there is a before to measure against. Trace first, edit later The code that enforces the length rule has never been opened. Instead of asking for a fix, the request is a trace that forbids edits — done in plan mode, where file editing and writing tools are mechanically blocked rather than merely discouraged. Ways in: the permission-mode flag at launch, Shift+Tab to cycle modes, the slash-plan command, or a default mode set in settings. The caveat: plan mode gates edits, not process execution. Read-only shell commands run unprompted from a built-in allowlist you cannot edit; anything else goes to a safety classifier unless you turn off auto mode during plan. Launching with dangerously-skip-permissions overrides the gate entirely. Tool-level alternatives: allowed-tools or disallowed-tools flags, or edit and write in the deny list. The trace may be delegated to the built-in read-only Explore subagent, which keeps file contents in its own context and returns a summary. Two consequences: intermediate work vanishes from the transcript, and the built-in Explore and Plan subagents skip the project instructions file to save tokens — so your constraints must be restated in the prompt. Ninety seconds of checking The account names a form component, a route handler, and a validation function comparing raw length before trimming. That is a claim until the files are opened. A confident specific you cannot find means stopping and re-asking, not waving it through — the details arrived as one story, not independently. Green tests, broken browser A failing test comes before the fix, read to confirm it fails for the right reason. Three lines change. The suite passes. The browser still fails, because the form component counts characters too. Why a wide diff was wrong the first time and justified the second. Then a branch, one commit, and a message naming the behavior. Three things that went wrong, each with a one-line detection method. Recent changes worth knowing A persistent side-by-side diff pane from slash-diff; grep and glob now returning explicit errors instead of silent "no matches" on large result sets; slash-ultrareview handling a clean tree; Control+Enter to interrupt tool work and submit at once; and AGENTS.md as a fallback when no CLAUDE.md is present.

  6. 12 Sept

    2. Writing the Instructions Your Next Session Will Actually Read

    This chapter explains how to write and test a CLAUDE.md file so a fresh Claude Code session knows a project's commands, layout, and definition of done without being told each time, and covers a recent change to which parts of a session actually read that file. This episode is narrated by AI-generated synthetic voices. Episode page & show notes Visit website The founding charter The core of this chapter is CLAUDE.md, the file Claude Code loads automatically at the start of every session before your first request arrives — no attaching, no pasting, just a file sitting at the project root or inside the .claude directory that gets read on its own. It walks through the four places instructions can live — the shared project file, a personal file in your home directory, an untracked local variant, and organization-wide settings — and explains that Claude Code doesn't let the narrowest file override the others; it concatenates all of them into context, broadest first, and leans on the model to treat the more specific instruction as the one that wins. From there the chapter builds an actual file for a shared-list app: starting from a /init draft, keeping only the commands that aren't obvious (the dev server, the type check, the one authoritative test command), naming the manual click-through journey that tests alone can't replace, writing down two or three real architectural constraints, and stating flatly what "finished" means. It explains why the file should stay short — it's re-injected on every turn, so bloat taxes every future question — and points to /context, /doctor, and /memory as ways to check what's loaded and trim what doesn't earn its place. It draws a hard line between guidance, which the model can still talk itself past, and real enforcement through a permissions deny list, and closes with a repeatable loop for testing whether an instruction actually changes agent behavior: fresh session, one-line request, watch what's skipped, edit one sentence, retest. What changed in how instructions get loaded A shorter section covers a real gap in that mental model: the built-in Explore and Plan subagents skip reading CLAUDE.md and skip checking Git status entirely, while custom subagents you define still inherit it. It also notes a new flag for passing subagent rules via a file instead of a command-line string, and a fix in recent releases removing an approval prompt that used to stall scripted runs using organization-delivered instructions — all catchable with the same /context check.

  7. 10 Sept

    1. Your First Real Change, Made by an Agent and Checked by You

    This chapter installs Claude Code, opens it inside a small shared-list web app, and walks through fixing one real bug — blank items being addable — end to end: describing the project, requesting a narrow change, reading the diff, running tests, manually verifying the behavior, adding a test, and committing. It closes with two recent changes to the tool, Auto permission mode and default model updates, and what to check about each. This episode is narrated by AI-generated synthetic voices. Episode page & show notes Visit website Getting the tool onto your machine The chapter walks through installing Claude Code as a standalone application rather than through npm, explaining why the native installer (fetched with curl or the PowerShell script) is the recommended path — it updates itself and needs no Node.js runtime — while noting Homebrew, WinGet, and Linux package repositories as valid alternatives, per the setup instructions. It covers system requirements, the sign-in flow through a browser, and the built-in diagnostic reached with slash doctor for fixing installation and network problems, drawn from the CLI reference. Opening a real project Once launched inside a small shared-list web app, the chapter shows the workspace trust prompt, the live session display showing model and context usage, and the two permission modes — Manual, which asks before every write or command, and Auto, now the default for Pro, Max and Team plans, which only interrupts for destructive operations. It draws on the permissions documentation and the interactive mode guide to explain what each mode actually shows you and why reading a diff before approving it matters. Making one change and proving it The core of the chapter is a single fix: stopping blank or whitespace-only list items from being added. It shows the tool describing the project first, proposing a small diff, running the test suite after a command-approval prompt, and then a manual click-through of the app to confirm the behavior actually changed — because a passing suite only proves what it already tested. A new test is added, deliberately watched failing and then passing, before a single readable commit closes the loop. What changed recently in Claude Code A short section flags two changes that affect a first session directly: Auto mode becoming the default permission mode on Pro, Max and Team plans, and Sonnet 5 becoming the default model, with Opus 5 launched alongside it (both since succeeded by Sonnet 5.5 and Opus 5.5), plus support for pinning a default model via environment variable, all listed in the Claude Code changelog and the what's new page.

About

Take Claude Code from its first useful change in your terminal to a repeatable software delivery workflow. For working developers who already ship applications and use Git, this course starts with setup, giving Claude a task, inspecting the diff and checking the result. Build on that session with project instructions, skills, hooks, MCP connections and context management. Later lessons connect parallel agents and Git worktrees to GitHub issues, pull requests and review-and-fix loops, then develop testing and deployment workflows with GitHub Actions and AWS. Permissions, sandboxing, cost controls and observability are taught alongside the automation they support, so you can judge what a run changed and investigate a failure. Concrete examples explain the commands, settings and checks behind each workflow; earlier techniques return as parts of larger systems. Claude Code news and practical shortcuts cover changes that affect coding work, setup or cost. The curriculum builds toward an issue-to-deployment pipeline, including rollout decisions and incident response. This show's audio is narrated by AI-generated synthetic voices.

You Might Also Like