pdlc-os/override

You are executing a guardrails override. The argument passed is the command that was blocked: $ARGUMENTS

If $ARGUMENTS is empty, stop:

"No command specified. Usage: /override \"<the blocked command>\""

The Override Protocol

The guardrails hook has exactly one enforced block: deploy commands outside the Operation phase. /override bypasses that block. The override is permanently logged in DECISIONS.md.

Step 1 — Display the blocked command in red

Output:

\x1b[1;31m⛔ OVERRIDE REQUEST ⛔\x1b[0m

Command: [the blocked command] Reason it was blocked: the project's current phase (per STATE.md) is not Operation. Deploy commands route through /ship, which runs smoke tests, UX Verify, security checks, and writes deployment provenance to DEPLOYMENTS.md and the episode file. Bypassing this skips all of that.

\x1b[1;31mConsequences if you proceed:\x1b[0m

• The deploy executes immediately against whatever environment the command targets.
• No smoke tests run.
• No UX Verify (Step 11.5) — P0 findings will not be detected.
• No DEPLOYMENTS.md update — the deploy has no provenance record.
• No episode file entry — the deploy won't appear in the next reflection cycle.

Step 2 — Single confirmation

\x1b[1;31mConfirmation:\x1b[0m Type I ACCEPT FULL RESPONSIBILITY (exactly, case-sensitive) to execute the command. Anything else cancels.

Wait for the user's exact input. If they type anything other than I ACCEPT FULL RESPONSIBILITY, stop:

"Override cancelled. The command was not executed."

Step 3 — Execute and log

If the confirmation passes:

1. Record as a decision — append to docs/pdlc/memory/DECISIONS.md:

   ### ADR-[NNN]: Deploy-gate override — [short description]
   
   **Date:** [today, YYYY-MM-DD]
   **Source:** User (explicit /override)
   **Phase at time of override:** [current phase from STATE.md]
   **Status:** Active
   
   **Decision:** Bypass the deploy-before-Operation guardrails block to execute: `[command]`
   **Context:** The Ship flow's smoke tests, UX Verify, and DEPLOYMENTS.md provenance were skipped.
   **Risk accepted:** Untested code may reach the targeted environment; the deploy has no provenance record.
   

2. Log a Phase History line to STATE.md:

   | [now] | override:deploy-gate | [current phase] | [sub-phase] | [feature] |
   

   Also append to Active Blockers (as a record, not a blocker):

   - [YYYY-MM-DD] OVERRIDE: [command] — approved by [git config user.name (fall back to $USER env var)] with /override
   

3. Execute the command:

   [the blocked command]
   

4. Report the result:

   "Override executed. The action has been logged in STATE.md and DECISIONS.md. Command: [command] Result: [success/failure output]"

Rules

• The confirmation must be an exact string match. No fuzzy matching, no "close enough."
• The override is logged permanently — it cannot be hidden or deleted from STATE.md or DECISIONS.md.
• Each override is a separate ADR entry. If the same command is overridden multiple times, each gets its own entry.
• This skill should NEVER be invoked automatically by another skill. It must be triggered by the user explicitly typing /override.
• /override only bypasses the deploy-gate block. The memory-file write rule is passive (never blocks); there is nothing to override there. Agent norms (force-push, rm -rf, etc.) are not hook-enforced; they don't route through this skill.