Lock Scenes — On-Demand Write Protection

Blocks Edit/Write to approved files during final assembly. Only active when invoked via /lockscenes. The hook is removed when the session ends.

This is a rare example of Claude Code's PreToolUse hooks used for on-demand file guards. Useful pattern for any project that has an "approved" or "frozen" state.

Usage

Lock default set (everything approved)

/lockscenes

This writes a lock file and activates the PreToolUse hook. Any attempt to Edit or Write a file matching a locked pattern is denied.

Lock specific items

/lockscenes shot-01 shot-02 cut-01

Unlock (remove all locks)

/lockscenes unlock

What Gets Locked

When invoked, Claude creates a lock file at runs/.scene_lock with patterns to protect.

Default lock (no arguments) — protect common approved paths:

review_data.json
cleaned_prompts.json
references/approved/
scene_bundles/

Customize the defaults in scripts/guard-approved.sh for your project.

Item-specific lock — add IDs as patterns:

shot-01
shot-02
cut-01

How It Works

1. You invoke /lockscenes. The skill activates for this session.
2. Claude Code runs the hook script (guard-approved.sh) before every Edit/Write.
3. The script reads runs/.scene_lock for locked patterns.
4. If the target file path matches any pattern, the edit is denied.
5. Claude sees the denial message and skips that file.

Implementation Steps (for Claude)

When /lockscenes is invoked:

1. Parse arguments — specific item IDs or "unlock"
2. If "unlock": delete runs/.scene_lock and confirm
3. If no arguments: write default lock patterns to .scene_lock
4. If item IDs given: write those IDs as patterns to .scene_lock
5. Confirm: "Locked N patterns. Edit/Write to matching files will be blocked this session."

Gotchas

• The lock file is just a text file with patterns, one per line. Lines starting with # are comments.
• The hook only blocks Edit and Write tools. Bash commands like sed or echo > are NOT blocked. This is intentional — if you need to force-edit, you can, but you have to be deliberate.
• The lock persists in the file system, but the hook only runs while the skill is active. Stale lock files are harmless but should be cleaned up.
• The lock file should live in a gitignored path (e.g., runs/), not in the repo.

Why this pattern matters

Claude Code hooks are powerful but underused. This skill shows a real production use:

• On-demand activation (not always-on — flips on only during final assembly)
• Scoped to a specific tool matcher (Edit|Write)
• Uses a simple text file as state
• Zero dependencies beyond bash

Fork the pattern for any lifecycle stage where you need temporary guards.