# Your protocols, your rules.

Six protocols ship in the box, but they’re yours to change. Drop a JSON config in `custom/` and it overrides the system copy of the same name — with no engine change, and never overwritten on upgrade.

## Load order: custom → system → source

When the engine resolves a protocol or a sub-protocol prompt, it walks an ordered search path — `custom/` first, then the installed `system/` copy, then the package source. The first match wins, so a forked `custom/task.json` shadows the shipped one cleanly.

## What you can change

Override any step’s DAIC mode, swap in a custom pre- or post-function, reorder steps, or author a whole new protocol. Behaviour lives in named functions discoverable through the engine, so adding to a step is a JSON edit — not a code change.

The same rule protects your customizations of shipped agents and the `CLAUDE.tm.custom.md` rules file: team-management only overwrites the names it ships on update, so a renamed copy is always safe.

## What a config actually holds

The file is small: a `name`, a `description`, and a list of `steps`. Each step names itself, declares the `mode` it runs in, and carries two lists of named functions — `pre_funcs` on entry, `post_funcs` on exit. A `post_funcs_stop_on_failure` flag decides whether a failing exit function halts the step or lets it through.

Even the text a step shows you is just `start` and `end` fields in the same file. That is most of the shape — which is why so much can be changed without touching engine code, and why anything you fork is yours to maintain.

## Forking a protocol — just ask Claude

You don’t hand-author JSON to start. Ask Claude to run `/team-management:custom-protocol-create task` — it calls `protocol_customize`, copies the system config into `custom/task.json`, and opens it for editing. From there you describe the change in plain language and Claude edits the config with you.

```
You → fork the task protocol and add a security-review step
```

## Staying current after an upgrade

When the plugin updates, the shipped protocols may gain steps or change behaviour — but your `custom/` copies are never touched, so they can quietly fall behind. Run `/team-management:custom-protocol-update-after-reinstall` (which drives `protocol_check_drift`) to diff your custom copies against the upgraded system copies and decide what to merge. Nothing is overwritten without your say-so.