AI was supposed to democratize coding. Anyone can now sit in front of an agent — OpenCode, Claude Code, Cursor, Codex, Gemini — and bring an idea to life using nothing but natural language.
Until this pops up in your terminal:
Run rm -rf dist/? [Allow once / Always / Reject]
Or worse:
find . -name "*.bak" -exec rm -f {} +
For non-technical builders, this is terrifying. What is rm? What is -rf? Does this delete the whole operating system?
For seasoned developers, it is death by alert fatigue. After the agent prompts you 40 times in an hour, you stop reading the flags. You reflexively click "Always Allow" — and that is how entire repositories and local databases get nuked.
Democratizing coding does not just mean generating code with natural language. It means making safety and permissions understandable in natural language.
I built a 15-line, zero-dependency rule that fixes this: permission-explainer.
What it looks like
Instead of forcing you to decipher shell flags, your agent is required to output four clear lines before you ever see an approval prompt:
🔧 Tool call incoming
What: Deletes the compiled distribution build artifacts in the dist/ folder.
Why: To ensure the next build creates clean assets from scratch.
Changes: Removes the directory ./dist and all its contents.
Reversible: No. Uncommitted compiled files cannot be recovered.
Now anyone — whether you wrote your first prompt yesterday or have used bash for twenty years — can make an informed choice.
How to install (one command)
The skill is published on skills.sh. Install it with one command:
npx skills add uiyuvi/permission-explainer --skill permission-explainer
It works out of the box with:
- OpenCode
- Claude Code
- Cursor
- Codex
- Gemini CLI
- Antigravity
How it works under the hood
The architecture is deliberately minimal — 15 lines, no dependencies, no external calls:
[Agent plans tool call]
│
▼
[permission-explainer rule intercepts]
│
▼
[Agent outputs 4 plain-English answers]
1. What it does
2. Why it is needed
3. Disk / state changes
4. Reversibility
│
▼
[Host approval dialog: Allow / Reject]
The rule is a single markdown file that the agent loads as a constraint. It does not wrap your tools, patch your shell, or add middleware. It changes what the agent is required to say before reaching for any tool — terminal commands, file edits, MCP tool calls, browser actions.
The blockquote format is intentional: it forces the explanation to be visually distinct from the agent's reasoning and the tool output, so the signal is never buried in a wall of text.
The full rule, unabridged
Here it is. All 15 lines:
# Tool Explanation Rule
Before calling ANY tool (terminal commands, MCP tools, file edits, or browser actions),
you MUST first write a chat message in the following format — it must appear before the
tool call, not after:
> 🔧 **Tool call incoming**
>
> **What:** [plain-English description of what the tool does]
> **Why:** [why this specific call is necessary for the task]
> **Changes:** [what will be different after — or "None" if read-only]
> **Reversible:** [Yes / No / Partially]
> ⚠️ **Elevated access / system files:** [Yes — describe] or omit this line if not applicable
The blockquote format is required so the explanation is visually distinct from
model reasoning and tool results.
Audit it yourself. There is no telemetry, no network call, no hidden behaviour.
An honest safety note
Explanation does not equal safety.
This rule guarantees transparency, not immunity. If an agent explains that it is about to run rm -rf / to "clean up disk space," the explanation is accurate — but the action is catastrophic.
If something looks wrong after reading the explanation, hit
Reject.What the rule does eliminate is the scenario where you click Allow because you had no idea what you were approving. That is the most common failure mode. Alert fatigue kills judgment. Forced plain-English kills alert fatigue.
Why alert fatigue is the real threat
A single coding session with a capable agent can generate 40 or 50 tool call prompts. After the first dozen, your brain stops processing them. You have seen [Allow / Reject] so many times that it has become visual noise.
The rule breaks that pattern by changing the signal, not the frequency. The agent still calls the same number of tools. But now each prompt is preceded by a sentence you can actually read and evaluate, not a raw command you have to mentally parse under time pressure.
The two failure modes the rule addresses:
| Without the rule | With the rule |
|---|---|
Non-technical user sees find . -name "*.bak" -exec rm -f {} + — has no idea what to do |
Reads "Deletes all .bak backup files found anywhere in the project" — can decide |
Experienced developer sees the 40th [Allow once / Always / Reject] — clicks without reading |
Reads a one-line plain-English summary — snaps back to attention |
Built from a phone
A fun detail for the mobile hackers: the entire rule, test suite, and documentation were written, tested, and published directly from Termux on an Android phone. No workstation, no IDE, no desk required.
curious to know more please read this- https://dev.to/iamyuvaraj/turn-your-android-phone-into-an-ai-coding-workstation-no-laptop-required-10ej
You do not need a high-end development environment to ship practical developer tooling. A focused constraint expressed in 15 lines of markdown is fully within reach of a phone-sized workflow.
Try it
npx skills add uiyuvi/permission-explainer --skill permission-explainer
👉 Published on skills.sh: uiyuvi/permission-explainer
Audit the 15 lines, install it, and let the agent explain itself before it touches anything. If it saves your environment once, it has paid for itself.
If you hit a tool call that the rule handled well — or one it handled badly — drop it in the comments. The format is a starting point. The community can improve it.
Top comments (0)