Scope or freeze which files Claude can edit during debugging, a refactor, or review. Use when edits should stay in specific dirs, or for a read-only investigate lock. Backed by a sentinel + PreToolUse hook.
npx skills add https://github.com/oliver-kriska/claude-elixir-phoenix --skill freeze
Toggle a project-local edit lock so Claude can only modify the files you intend
during a focused task (debugging, a tight refactor, a review pass). Enforced by
the freeze-gate.sh PreToolUse hook, which denies Edit/Write/NotebookEdit
outside the allow-list. No sentinel = no lock; the hook stays dormant.
The lock lives in .claude/.freeze — one allowed path prefix per line,
project-relative. Empty file = freeze everything.
/phx:freeze [args] — resolve $ARGUMENTS and run the matching Bash branch.
| Invocation | Effect |
|------------|--------|
| /phx:freeze | Freeze ALL edits — read-only investigation mode |
| /phx:freeze lib/app_web priv/repo | Allow edits only under these dirs |
| /phx:freeze status | Show current lock state |
| /phx:freeze off | Lift the lock (delete the sentinel) |
mkdir -p .claude && : > .claude/.freeze
echo "Freeze ON — all edits blocked. Lift with /phx:freeze off"
mkdir -p .claude
printf '%s\n' lib/app_web priv/repo > .claude/.freeze
echo "Freeze ON — edits limited to: lib/app_web priv/repo"
Map $ARGUMENTS to the dirs the user named. Include any directory you still need
to write to — e.g. add .claude if progress/scratchpad logging must continue.
if [ -f .claude/.freeze ]; then
if [ -s .claude/.freeze ]; then echo "Freeze ON — limited to:"; cat .claude/.freeze
else echo "Freeze ON — ALL edits blocked"; fi
else echo "Freeze OFF — no edit lock"; fi
rm -f .claude/.freeze && echo "Freeze OFF — edits unlocked"
:>, printf, rm) — NEVER viaEdit/Write. The freeze hook gates Edit/Write and would block you from
re-scoping or clearing the lock.
/phx:freeze off, including into later sessions. Clear it when the task ends.
lib/foo allowslib/foo and everything under it; it does NOT allow lib/foobar.
surfaces clearly instead of failing silently.
/phx:investigate (freeze all while root-causing) and /phx:work(scope to the plan's dirs). The lock is advisory tooling, not a security
boundary — anyone can run /phx:freeze off.
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions "/commit". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping
Comprehensive GitHub code review with AI-powered swarm coordination
Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
Use this skill to review code. It supports both local changes (staged or working tree) and remote Pull Requests (by ID or URL). It focuses on correctness, maintainability, and adherence to project standards.
Refactor bloated AGENTS.md, CLAUDE.md, or similar agent instruction files to follow progressive disclosure principles. Splits monolithic files into organized, linked documentation.
Create high-quality git commits: review/stage intended changes, split into logical commits, and write clear commit messages (including Conventional Commits). Use when the user asks to commit, craft a commit message, stage changes, or split work into multiple commits.
Take oliver-kriska/freeze from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.