Steps as JSON, prompts as markdown. Step orchestration — the DAIC mode, which functions run, what arguments advance requires — lives in compact JSON. The verbose human-facing instructions live in separate sub-protocol markdown, so the long prompts can be edited or forked without touching engine logic.

Functions, not hardcoded steps. All side effects — branch creation, issue sync, archiving, squashing — are named functions in a step’s pre_funcs / post_funcs, all catalogued in the engine functions reference. Adding behaviour is a JSON edit, not an engine change.

Gates that can’t be talked past. A post-function marked stop-on-failure becomes a hard precondition for advancing — that’s how spec-compliance, completion-evidence, and the optional test gate become structural walls rather than advisory reminders.

This runs protocol_customize("task"), copies the system config into team-management/protocol-configs/custom/task.json, and opens it for editing — then you describe the change in plain language and Claude edits it with you. The custom copy takes precedence on name match and is never overwritten on upgrade.

To create a net-new protocol, drop any uniquely-named JSON into custom/ — it appears in protocol_list() immediately. The engine functions you can wire into steps (branch setup, issue sync, archiving, frozen paths) are discoverable via protocol_available_funcs(). After an upgrade, run /team-management:custom-protocol-update-after-reinstall to diff your copies against the new system ones and decide what to merge. See customization for the full story.

Forward is earned; backward is always open. A step advances only when its completion criteria are met — but it can always step back. If review surfaces a real problem, the protocol returns to investigation, re-plans, fixes, and re-earns the path forward.