Part four of the Handmade Claude Code campaign: the agent becomes extensible without being recompiled. Skills the model can pull in when it needs them, commands the user can type, hooks that run around every tool call and can veto it, settings that layer, and subagents — whole loops the model can delegate to.

This session continues the agent you built in parts one to three, in the same repository. Everything lives under .agent/ in the working directory.

Skills

.agent/skills/<name>/SKILL.md
---
name: <name>
description: <one line>
---
<the instructions>

Every skill is listed in the system prompt by name and description, so the model knows what it could ask for. A tool skill with input {"name": "<name>"} returns the skill's body (the frontmatter stripped) and the absolute path of the skill's directory, so the model can read the files beside it. An unknown name is an error result.

Slash commands

A prompt that starts with / is a command. /<name> <args> looks for .agent/commands/<name>.md and sends its contents as the user message, with $ARGUMENTS replaced by <args>; when there is no such file but a skill of that name, the skill's body is sent the same way.

Hooks

.agent/settings.json
{"hooks": {"PreToolUse": [{"matcher": "bash", "command": "sh .agent/hooks/pre.sh"}]}}

Events: PreToolUse, PostToolUse, UserPromptSubmit, Stop. A hook is a shell command run with sh -c in the working directory, with one JSON object on stdin: hook_event_name, and for tool events tool_name and tool_input (plus tool_response — the result content — after the tool ran), for UserPromptSubmit the prompt. matcher is a glob over the tool name; absent, the hook runs for every tool.

• PreToolUse — exit 2 blocks the call: the tool does not run and the result is is_error: true with the hook's stderr as content.
• PostToolUse — whatever it prints on stdout is appended to the tool result the model sees.
• UserPromptSubmit — whatever it prints is appended to the user message.
• Stop — runs once the final answer is ready, before the agent exits.

Settings layering

.agent/settings.local.json sits on top of .agent/settings.json: lists (allow, deny, each hook event) concatenate, scalars from the local file win.

Subagents

.agent/agents/<name>.md
---
name: <name>
description: <one line>
---
<that agent's system prompt>

Every agent is listed in the system prompt by name and description. A tool task with input {"agent": "<name>", "prompt": "<text>"} runs a fresh loop: its own conversation starting with just that prompt, the agent's body as its system prompt (plus your usual environment), the same model command, the same tools. Its final text is the tool result. The parent conversation never sees the child's turns.

The judges

The quality panel — architecture, performance, code quality, test quality, technical governance and DX review — sits on the rungs where its subject is decided, one verdict per judge per rung, on top of the rung's own points. There is no closing review: what you build is judged as you build it, and a rung you never reach is a verdict you never get.

The ladder

• Set up and carry parts one to three forward (10)
• Skills are listed (20)
• A skill is a tool (30)
• Slash commands (20)
• A hook can say no (30)
• A hook can add a note (20)
• Prompt and stop hooks (20)
• Settings layer (20)
• Subagents (40)