Freeze

--- name: freeze type: workflow description: "Locks the codebase to prevent unintended writes during a freeze period such as before a release or during an incident. Use when the user mentions freezing, code lock, or release lockdown." argument-hint: "[reason]" user-invocable: true allowed-tools: Read, Write, Bash effort: 1 agent: release-manager when_to_use: "Before release cut, hotfix deployment, or when a stabilization period is needed"

Code Freeze

Lock the codebase in preparation for a release. Create a .freeze file containing freeze information.

Workflow

1. Read Current Status

Check if .freeze already exists by reading the file. If it exists, display the information and ask:

"The codebase is currently frozen for: [REASON]. Do you want to override the current freeze? (yes/no)"

If no, stop.

2. Get Freeze Reason

If no argument is provided, ask:

"What is the reason for the freeze? (e.g., 'Release v2.1.0', 'Hotfix deployment', 'Sprint end')"

3. Create .freeze File

Write the following content:

FROZEN=true
REASON=[reason]
FROZEN_AT=[ISO timestamp]
BRANCH=[current branch from git rev-parse --abbrev-ref HEAD]

4. Notification

Display:

🔒 CODEBASE FROZEN
Reason : [reason]
Time   : [timestamp]
Branch : [branch]

Non-critical merges are blocked. Only hotfixes are permitted.
To unlock: /unfreeze

5. Suggested Next Steps

• /release-checklist — Run the full release checklist
• /guard — Check the freeze status at any time
• /unfreeze — Unlock after the release is complete

Edge Cases

• Existing freeze: Ask for override confirmation before overwriting.
• No git repository: Still create .freeze but omit the BRANCH field.

Related Skills

• /guard — Check freeze status before merge/deploy
• /unfreeze — Remove freeze after release
• /release-checklist — Full release workflow
• /hotfix — Deploy urgent fixes during a freeze