no-vibe-btw

Temporarily disable the no-vibe write guard for one scoped task and restore its prior state.

36|1|Updated Apr 9, 2026
One-click install
npx skills add https://github.com/rizukirr/no-vibe --skill no-vibe-btw
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: no-vibe-btw
Source: https://github.com/rizukirr/no-vibe/tree/main/plugins/no-vibe/skills/no-vibe-btw
Command: npx skills add https://github.com/rizukirr/no-vibe --skill no-vibe-btw

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It solves the problem of needing to make a single, narrowly-scoped change when the normal no-vibe write guard would otherwise block the edit you need right now.

Core Features & Use Cases

  • Temporarily disables the write guard for exactly one scoped task so you can complete that specific change.
  • Restores the previous guard state by re-adding .no-vibe/active only if it was active before the task began, even if the task fails.
  • Prevents scope creep by performing exactly what you asked for—no opportunistic refactors or extra cleanup.

Quick Start

Run: $no-vibe-btw add a .gitignore for node

Frequently Asked Questions about no-vibe-btw

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

FAQPage Schema
How do I make a single file edit when write guards are blocking changes?

To make a single file edit when write guards are blocking changes, temporarily disable the guard by removing the active state file, execute exactly one scoped task, then restore the guard. This prevents scope creep while allowing necessary one-off modifications.

What is a scoped edit escape hatch for guarded writes?

A scoped edit escape hatch for guarded writes is a mechanism that snapshots the current guard state, removes the block to allow a single specific change, and restores the original state afterward, ensuring no opportunistic refactors occur during the task.

How do I add a gitignore file without disabling write guards permanently?

You can add a gitignore file without disabling write guards permanently by using a one-shot escape hatch that removes the active guard file, performs the single addition task, and immediately restores the guard state if it was previously active.

Does the write guard state restoration work if the scoped edit task fails?

Write guard state restoration works even if the scoped edit task fails, because the mechanism snapshots the prior presence of the active guard file and re-adds it afterward, ensuring the original protected state is preserved regardless of task completion.

When should I use a temporary write guard bypass for state restoration?

Use a temporary write guard bypass for state restoration when you need to perform a narrowly-scoped, one-off change like adding or fixing a specific file, and you want to ensure the guard is restored to its exact previous state without enabling broader edits.