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.
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.
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.