freeze

Restrict file edits to a user-defined directory for a session.

Updated Mar 11, 2026
One-click install
npx skills add https://github.com/kinetas/ai_coding_web --skill freeze-kinetas
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: freeze
Source: https://github.com/kinetas/ai_coding_web/tree/main/gstack/freeze
Command: npx skills add https://github.com/kinetas/ai_coding_web --skill freeze-kinetas

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Restrict file edits to a specific directory for a session to prevent accidental changes outside the intended area, helping maintain focus during debugging or module work.

Core Features & Use Cases

  • Blocks Edit and Write operations outside the configured boundary to avoid scope creep.
  • Persists the freeze boundary for the session, so settings survive tooling invocations.
  • Useful during debugging, code reviews, or focused module edits when you want to lock changes to a single folder.

Quick Start

Provide a directory path to restrict edits to for the current session.

Frequently Asked Questions about freeze

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I restrict file edits to a specific directory during a debugging session?

You can restrict file edits by configuring a directory path to act as a session-boundary, which blocks Write and Edit operations outside that specific folder to keep changes contained.

What is a filesystem edit restriction and when should I use it?

A filesystem edit restriction is a guardrail that blocks modifications outside a defined directory. You need it during debugging or module-focused work to prevent accidental changes and avoid scope creep outside the intended area.

Can I lock changes to a single folder without affecting other files in the workspace?

Yes, you can lock changes to a single folder by setting a freeze boundary. This guardrail blocks Edit and Write operations outside the configured directory while allowing normal modifications inside the target path.

How do I start locking edits to a folder for focused module work?

To start locking edits for focused module work, provide a target directory path to restrict edits for the current session. The boundary persists across tooling invocations to ensure changes remain contained within that folder.

Why should I use an edit restriction guardrail instead of manually checking file paths?

Using an edit restriction guardrail automatically blocks Write and Edit operations outside your intended directory, preventing accidental scope creep. Manually checking paths is prone to human error during intense debugging or focused module work.

Does the freeze boundary persist across different tooling invocations within the same session?

Yes, the freeze boundary persists for the entire session. It reads and saves the configuration so the edit restriction survives multiple tooling invocations, continuously blocking modifications outside the configured directory path.