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
- You invoke
/lockscenes. The skill activates for this session. - Claude Code runs the hook script (
guard-approved.sh) before every Edit/Write. - The script reads
runs/.scene_lockfor locked patterns. - If the target file path matches any pattern, the edit is denied.
- Claude sees the denial message and skips that file.
Implementation Steps (for Claude)
When /lockscenes is invoked:
- Parse arguments — specific item IDs or "unlock"
- If "unlock": delete
runs/.scene_lockand confirm - If no arguments: write default lock patterns to
.scene_lock - If item IDs given: write those IDs as patterns to
.scene_lock - 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
sedorecho >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.