Kit4Some/skills/freeze

<!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly. Run: node scripts/gen-skill-docs.mjs -->

---

name: freeze description: > Restrict file edits to a specific directory for the session. Blocks Edit and Write outside the allowed path. Triggers on "freeze", "편집 제한", "이 폴더만", "restrict edits", "only edit this folder", "lock down edits", "범위 제한". allowed-tools:

• Bash
• Read
• AskUserQuestion hooks: PreToolUse:
  • matcher: "Edit" hooks:
    • type: command command: "bash ${CLAUDE_SKILL_DIR}/bin/check-freeze.sh" statusMessage: "Checking freeze boundary..."
  • matcher: "Write" hooks:
    • type: command command: "bash ${CLAUDE_SKILL_DIR}/bin/check-freeze.sh" statusMessage: "Checking freeze boundary..."

---

/freeze — Restrict Edits to a Directory

Lock file edits to a specific directory. Any Edit or Write operation targeting a file outside the allowed path will be blocked (not just warned).

Preamble

Before executing this skill:

1. Load context from memory:

   memory_search(query: "{skill-relevant-query}", associative: true, limit: 5)
   memory_search(tag: "{skill-name}", limit: 3)
   

   Review returned memories for relevant past context, decisions, and patterns.

2. Check OMC state for active work:

   state_get_status()
   

   If conflicting active tasks exist, warn the user before proceeding.

3. Detect current branch (for git-related skills):

   git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "not-a-git-repo"
   

4. Check proactive mode:

   state_read("occ-proactive")
   

   If "false": do NOT proactively suggest other OpenClaw-CC skills during this session. Only run skills the user explicitly invokes.

5. Log skill activation:

   memory_daily_log(type: "note", entry: "Skill activated: /{skill-name}")
   

Setup

Ask the user which directory to restrict edits to. Use AskUserQuestion:

• Question: "Which directory should I restrict edits to? Files outside this path will be blocked from editing."
• Text input (not multiple choice) — the user types a path.

Once the user provides a directory path:

1. Resolve it to an absolute path:

FREEZE_DIR=$(cd "<user-provided-path>" 2>/dev/null && pwd)
echo "$FREEZE_DIR"

2. Ensure trailing slash and save to the freeze state file:

FREEZE_DIR="${FREEZE_DIR%/}/"
STATE_DIR="${CLAUDE_PLUGIN_DATA:-${HOME}/.omc/state}"
mkdir -p "$STATE_DIR"
echo "$FREEZE_DIR" > "$STATE_DIR/freeze-dir.txt"
echo "Freeze boundary set: $FREEZE_DIR"

3. Log to memory:

memory_daily_log(type: "note", entry: "Freeze boundary set: {path}")

Tell the user: "Edits are now restricted to <path>/. Any Edit or Write outside this directory will be blocked. Run /unfreeze to remove the restriction."

How it works

The hook reads file_path from the Edit/Write tool input JSON, then checks whether the path starts with the freeze directory. If not, it returns permissionDecision: "deny" to block the operation.

Notes

• Trailing / prevents /src from matching /src-old
• Freeze applies to Edit and Write only — Read, Bash, Glob, Grep are unaffected
• This prevents accidental edits, not a security boundary
• To deactivate, run /unfreeze or end the conversation

Completion Status Protocol

Every skill must end with one of these status codes:

| Code | Meaning | When to Use | |------|---------|-------------| | DONE | All steps completed, evidence provided | Root cause found + fix verified, PR created, review finished | | DONE_WITH_CONCERNS | Completed with warnings or caveats | Tests pass but coverage dropped, fix applied but can't fully verify | | BLOCKED | Cannot proceed, requires user intervention | 3 failed attempts, missing permissions, external dependency down | | NEEDS_CONTEXT | Missing information to continue | Unclear requirements, need user clarification |

Escalation Rules

1. 3-strike rule: After 3 failed attempts at any step, STOP and escalate to user. Do not continue guessing. Present what was tried and ask for direction.

2. Scope escalation: If fix/change touches 5+ files unexpectedly, pause and confirm with the user before proceeding.

3. Security uncertainty: If you are unsure about a security implication, STOP and escalate. Never guess on security.

4. Verification requirement: Never claim DONE without evidence.

   • "Should work" → RUN IT. Confidence is not evidence.
   • "Already tested earlier" → Code changed since. Test again.
   • "Trivial change" → Trivial changes break production.

Output Format

═══════════════════════════════════════
Status: {DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT}
Summary: {one-line description of outcome}
Evidence: {test output, verification results, or blocking reason}
═══════════════════════════════════════