what else can it do?

what do i want to add?

an extension should have a specific job. instructions provide context, a skill carries a procedure, MCP connects a system, a subagent owns a separate problem, and a hook responds to an event. a plugin can package those pieces for reuse. Anthropic’s feature overview explains how they compose.

start with a repeated problem from actual work. “the agent keeps missing the same review step” gives you something to improve and a result to evaluate. “add more extensions” leaves both of those unclear.

a project to try this in

create an empty folder with Node available. save this as label.mjs:

export function displayLabel(value) {
  return value.replace(/\s+/g, ' ').trim();
}

copy

save this as label.test.mjs:

import assert from 'node:assert/strict';
import test from 'node:test';
import { displayLabel } from './label.mjs';

test('labels preserve words and normalize whitespace', () => {
  assert.equal(displayLabel('  two   words  '), 'two words');
  assert.equal(displayLabel('already clear'), 'already clear');
});

copy

run node --test label.test.mjs once before adding an extension. these are small instructional fixtures, so you can see exactly which behavior each extension adds.

how do i teach it a repeatable task?

skills use SKILL.md with a name, description, and instructions. supporting files can carry examples or scripts. write a description that makes the intended task recognizable.

for a manually invoked review of the label exercise, save this at .claude/skills/check-label/SKILL.md:

---
name: check-label
description: Review displayLabel against its string input contract and tests.
disable-model-invocation: true
---

Read label.mjs and label.test.mjs.
Check edge whitespace, internal whitespace, empty output, and unchanged casing.
Run node --test label.test.mjs.
Return the command result and any missing behavioral case with an example input.
Keep this pass limited to inspection and reporting.

copy

invoke it with /check-label. the explicit invocation setting keeps this procedure under your control; it does not establish a tool permission boundary. review the actual result to see whether the skill gave a clearer report than the ordinary prompt. keep it when repeated use justifies the extra file.

when should i bring in a subagent?

subagents can have their own prompt and tool list. a project definition belongs under .claude/agents/. for example, .claude/agents/contract-reviewer.md can contain:

---
name: contract-reviewer
description: Inspect the label function and tests for a mismatch with the stated contract.
tools: Read, Grep, Glob
---

Inspect label.mjs and label.test.mjs using the contract supplied with the task.
Return a concrete counterexample for each mismatch, with file references.
If the stated cases are covered, say which cases you checked.

copy

ask Claude to use contract-reviewer for the label function. the narrow tool list supports a source inspection. this agent has no shell tool for executing the test; the main session can run it and compare the evidence. label those two kinds of review accurately.

separate context is useful for a question whose investigation would otherwise crowd the main conversation. include the exact contract and files in the handoff. a worker can only use the context and tools it receives.

how do i connect another service?

MCP exposes tools and resources from other systems. a skill can explain how to use an issue tracker; its MCP server provides the operations that read or change issues.

use claude mcp list to inspect configured servers and /mcp inside a session to inspect connections and authenticate supported services. local, project, and user MCP scopes control where a server is configured. approving a project server and approving its tool calls are separate steps. interactive sessions ask before loading project servers; claude -p, SDK, and cloud sessions can load them without that prompt.

begin with one inspectable operation, such as reading a known issue by its identifier. check the active account, expected result, and permissions in the environment where Claude runs. a connector configured locally can need separate setup in a cloud session.

then decide whether the workflow needs writes. adding access to comments, records, or messages changes what the session can do on another system. match the service permissions to the intended operations, and keep returned content separate from instructions that authorize the task.

Alex Albert’s 2024 demo shows Claude desktop using MCP to create a GitHub repository and pull request.

Alex Albert (@alexalbert__), november 2024.

can it run a check after each edit?

hooks attach handlers to lifecycle events. PreToolUse runs before a tool action; PostToolUse runs after a successful one. current handlers include command, HTTP, MCP tool, prompt, and agent types, with event specific support. command handlers suit deterministic checks; model based handlers add judgment and another model call.

try a hook

in the scratch project, this .claude/settings.json entry runs the label test after an Edit or Write tool call:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "node --test \"$CLAUDE_PROJECT_DIR/label.test.mjs\" >&2 || exit 2"
          }
        ]
      }
    ]
  }
}

copy

this deliberately small example runs after every matching edit in the scratch project. Bash commands and other processes that edit the same files do not match Edit|Write. exit code 2 shows the failed check’s stderr to Claude; the edit has already happened. running the command directly checks the test and shell behavior. triggering an actual Edit call is a separate check of the hook’s registration and delivery.

for a real repository, narrow the event or script to the relevant files and measure the delay it adds. a slow hook makes each matching action slower. record success, failure, and timeout behavior so a quiet handler has an explanation.

plugins

plugins distribute related skills, agents, hooks, and MCP configuration. begin with standalone files while the workflow is changing. package them when several projects need the same tested procedure and you can describe what updating it will change.

a small plugin might contain a manifest in .claude-plugin/plugin.json, a review skill under skills/, a specialist under agents/, and event handlers under hooks/. the manifest names the plugin; these component directories belong at the plugin root.

use the manifest reference and claude plugin validate ./my-plugin to check the package, then load it in a disposable project with claude --plugin-dir ./my-plugin. test one expected invocation and one failure. package validation checks structure; an actual run checks whether the pieces work together.

mods extend the harness

i’m interested in how much an agent can change about its own setup, including the harness around it. that’s why the Function Hooks proposal caught my attention: it described deeper access to Claude Code’s internals.

that discussion now tracks Mods. Mods are plugins with JavaScript or TypeScript event handlers that run inside Claude Code. they are enabled by default in terminal v2.1.287 and later and Desktop Code v2.1.286 and later, subject to organization controls. the earlier CLAUDE_CODE_ENABLE_FUNCTION_HOOKS variable is ignored from v2.1.287.

mods can change tool calls, requests, and parts of the interface. they run with your user permissions, outside the Bash sandbox. inspect the code before loading one. the event reference documents the $ capabilities, event, and next continuation. handler failures can skip a handler, so a guard needs deliberate failure handling and a test.

the interesting test for deeper customization is concrete: can a plugin observe one intended event, make a visible change, and recover cleanly when its callback fails? the settings hooks above and Mods have separate APIs. this page documents the distinction; it does not report a firsthand Mods runtime test.