# Stop Using 'Skills' for Brainstorming. Build a Hook Instead. 🛠️

> Source: <https://dev.to/mehmetcanfarsak/stop-using-skills-for-brainstorming-build-a-hook-instead-3c5n>
> Published: 2026-06-11 20:20:00+00:00

You know that look? The one where you ask an AI coding agent to "just brainstorm a caching strategy" and suddenly—*poof*—it's implemented a Redis key-value store in Python anyway.

It's not because you didn't explain it well enough. It's because modern instruction-tuned models are **prioritized to act, not think**. They are over-trained on coding tasks and suffer from what we call "execution drift."

I spent the last few months trying to stop my AI agents from building UIs before they were even ready. I tried "prompting." I tried "skills" (Markdown files that act as system prompts).

**They all fail.**

As soon as the context gets too large (context compaction), the instruction gets wiped. Even if it doesn't, the model can just be talked out of it by a persuasive prompt. A skill is just *advice*.

If you can't rely on the model to follow instructions, you have to **bypass the model entirely** and enforce the constraints at the hook layer.

I built **Brainstorm-Mode**, a lightweight, agent-agnostic plugin architecture that blocks the actual execution of coding tools (`Edit`

, `MultiEdit`

, `NotebookEdit`

) *before* they ever touch your files.

Brainstorm-Mode operates on two enforcement layers:

Using a `UserPromptSubmit`

hook, the plugin injects a "Do Not Edit" constraint into every single user turn. It’s a constant reminder to the model that it's in ideation mode, re-injected every time to survive context compaction.

This is where it gets good. Instead of hoping the model obeys, Brainstorm-Mode uses a `PreToolUse`

hook to intercept tool calls. If the brainstorm lock is active, **any call to a coding tool is deterministically denied.**

The model doesn't get to "break character" by accident. It doesn't matter how persuasive the model gets—the tool simply will not run.

The core logic is written in Python (stdlib only, zero dependencies) and is entirely agent-agnostic. The `core/`

folder contains all the state management, meaning you can drop this into:

It also tracks every "drift" attempt (attempts by the model to execute a blocked tool) in a `drift-log.jsonl`

file, allowing you to actually *measure* how much the model fights back against your constraints.

If you are building agents, you know that "prompting" is just the beginning. True reliability comes from **enforcement**.

Brainstorm-Mode isn't just a brainstorming tool; it's a case study in control planes. It proves that you don't need to build a whole new AI model to solve alignment issues—you just need to enforce the rules at the infrastructure layer.

If you are tired of your AI agents coding before they are ready, check out Brainstorm-Mode.

One of the coolest side-effects of the `drift-log.jsonl`

is that you can actually see *when* your agent lies to you. If the log fills up with denied `Edit`

attempts right before context compaction, you know exactly where your control flow is breaking.

Stop asking your agents nicely to brainstorm. Force them to listen.