Lockscenes
On-demand write protection for approved files during final assembly, implemented via Claude Code PreToolUse hooks — a rare working example of hook-based file guards. Use when the user enters a final-assembly phase, wants to freeze approved work, or says "lock scenes", "protect these files", "freeze approved", "/lockscenes", "add a write guard", or asks how to temporarily block edits during a critical phase. Trigger this skill whenever the user needs temporary, scoped file-level guards without restructuring the repo.From its SKILL.md
npx -y skills add LuisHiluy/claude-code-pipeline-skills --skill lockscenesAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.5 KB, 662 tokens by cl100k_base, as published. Nobody here has run it
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.
What ships with it: 2 files
1.5 KB alongside SKILL.md, 1 of them executable
scripts/
- guard-approved.shruns841 B
- README.md724 B