Skip to content
coding agent tips

guides

GitHub

what else can it do?

last updated

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();
}

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');
});

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.

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.

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.

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"
          }
        ]
      }
    ]
  }
}

this deliberately small example runs after every matching edit in the scratch project. 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 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.

function hooks are a proposal

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 could expose more of Claude Code’s internals to extensions.

as checked September 7, 2026, Function Hooks remain an open proposal shared for feedback. the design describes JavaScript or TypeScript callbacks with an engine capability interface named $, an event, and a next continuation. callbacks could wrap later handlers, inspect results, or change what proceeds. the discussion also explores UI rendering and administrator controls. shipping and the final interface remain open.

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? keep the proposed API separate from the supported hook mechanisms above while those contracts develop.

media preview

by