Trust It: Verifying Unsupervised Runs

Sat, 03 Oct 2026 00:00:00 +0000

Note

TL;DR

Make the check as serious as the run was unsupervised:

Read the diff yourself.
Turn the tests into a hook that gates the turn.
Verify headless runs by their JSON result and exit code.
- Get a cold second opinion on anything that matters.

Keep Unattended Runs in Auto Mode

When a run goes unattended at work, keep it in auto mode rather than bypass permissions. In auto mode, the classifier still reviews each action for danger. But it never judges whether the code is actually correct. It only flags dangerous actions.

Start with the Diff, Not the Summary

Don’t start with Claude’s summary of what it did. Start with the diff itself.

Run /code-review to walk the changes and flag issues.
Then put your own eyes on git diff.

Read what changed. Read the files that were part of the plan first, then look for anything outside it.

Turn Tests into a Gate, Not a Promise

The real gate on an unsupervised run is whether the tests passed. Don’t leave that to trust. Wire it as a hook so Claude can’t skip it.

A couple of hooks do the job:

A stop hook that runs your tests and refuses to end the turn on a failure.
A post-tool-use hook that lints and type checks after every edit.

The key detail is the exit code. A hook that exits with exit 2 feeds the failure straight back to Claude. Claude reads that failure and fixes it without you asking.

Get a Cold Second Opinion

Open a fresh session or sub-agent and have it review the changed code with no memory of how the code was built. Because it has no stake in the approach, it catches the things the original run talked itself past. A second reviewer with fresh eyes finds what the author rationalized away.

Plugins

Sat, 03 Oct 2026 00:00:00 +0000

Note

TL;DR

When you use plugins, read before you install. A plugin runs code with your privileges, so look at its hooks, agents, and MCP servers first.
When you build one, package your .claude the moment it works. One manifest, one install.

What Is a Plugin

A plugin is one installable unit.

It bundles everything you’d otherwise share by hand: skills, subagents, hooks, and MCP server configs, plus the longer tail of stuff like language server protocol servers, background monitors, themes, and a slice of settings.json.
One version, one install.

Inside a session, you can install one directly by name. Example:

/plugin install github@claude-plugins-official

Adding a Marketplace for Your Team

For a team, the better move is to add a private marketplace once. A marketplace is a shared source that plugins resolve through:

/plugin marketplace add your-org/claude-plugins

Once it’s added, every install after that resolves through it. You get centralized discovery, version tracking, and updates in one place instead of scattered across everyone’s laptop.

Read before You Install

Before you install, check the plugin’s details. Claude Code shows you what it will install and estimates the context cost, along with a plain warning that Anthropic doesn’t control what’s inside third-party plugins.

Two things worth knowing about where plugins come from:

The in-app submission form posts to the community marketplace after Anthropic’s automated review.
The official marketplace is curated on its own separate track.

Tip

Install plugins and add marketplaces only from sources you truly trust, and check what a plugin actually does before turning it on.

Components Run Alongside Yours

A plugin doesn’t overwrite your configuration. Its components run alongside your own.

Things that are worth noticing

Hooks stack.

A plugin’s PreToolUse hook and your own PreToolUse hook both fire on every tool call. Neither replaces the other. -> This is exactly why you read the details first.
Skills, agents, and commands are namespaced under the plugin name, so they never clash with yours. A plugin can also ship a settings.json file, but only a narrow one. Claude Code honors just two keys from it: the agent and subagent status line keys.
Agent key

Setting it promotes one of the plugin’s subagents to the main thread, along with its system prompt, tool restrictions, and model. In other words, enabling the plugin can change how Claude Code behaves by default.

Packaging Your Own Plugin

Once you’ve built a .claude directory that works, don’t make your team copy and paste it between machines. Package it instead.

A plugin uses the same .claude shape you already use:

One folder per skill.
One markdown file per subagent under agents.
hooks/hooks.json and .mcp.json, at the plugin root.

The directory structure does most of the work. Claude Code discovers components by convention.

The Manifest

An optional manifest lives at .claude-plugin/plugin.json and holds the name, version, description, and author. Example:

{
 "name": "svg-splitter-review",
 "version": "0.1.0",
 "description": "Reviews the SVG Splitter repo",
 "author": {
 "name": "Lewis Menelaws"
 }
}

A couple of details are worth knowing:

Name is the only required field.

It namespaces your skills as /plugin-name:skill-name, so a skill in this plugin runs as /svg-splitter-review:<skill-name>. That keeps your skills from colliding with anyone else’s.
Version it like any other dependency.

Verify and Share |

Trust It: Verifying Unsupervised Runs

TL;DR

Keep Unattended Runs in Auto Mode

Start with the Diff, Not the Summary

Turn Tests into a Gate, Not a Promise

Get a Cold Second Opinion

Plugins

TL;DR

What Is a Plugin

Adding a Marketplace for Your Team

Read before You Install

Components Run Alongside Yours

Packaging Your Own Plugin

The Manifest