Feature request: Skill-level hooks (pre-tool-use hooks declared in SKILL.md)

Problem

Skills currently have no way to enforce safety constraints on tool usage. The only enforcement mechanism is instructions in SKILL.md, which are advisory — the LLM can bypass them by writing ad-hoc code (e.g. importing a library directly instead of going through the skill's sealed utility layer).

Hooks (pre-tool-use, post-tool-use) solve this at the user/project level via settings.json, but they are not portable with the skill. When a skill is shared across a team, each user must manually configure the hook — or it simply doesn't exist.

Real-world example

We built a skill that wraps a third-party API client with a sealed access pattern (similar to how database skills use callback-based encapsulation). All operations must go through a utility module that enforces batch API calls and prevents rate limiting.

However, nothing stops the LLM from writing ad-hoc code in a Bash call that imports the underlying library directly — bypassing the utility entirely. This actually happened during use: multiple individual API calls in a loop triggered rate limiting (HTTP 500 errors for ~30 seconds).

A pre-tool-use hook that blocks direct library imports in Bash commands would enforce this. But when the skill is shared with teammates, the hook doesn't travel with it.

Proposed solution

Allow SKILL.md to declare hooks that activate when the skill is loaded. For example:

---
name: my-skill
description: Wraps a third-party API safely
allowed-tools: ["Bash"]
hooks:
  pre-tool-use:
    - tool: Bash
      script: ./guard.sh
      message: "Direct library access blocked. Use the skill's utility module."
---

When the skill is active, the declared hooks would be merged into the active hook set — no manual settings.json configuration needed. The hook script lives inside the skill folder and ships with it.

Benefits

• Portable enforcement: Safety constraints travel with the skill, not the user's config
• Defense in depth: Complements SKILL.md instructions with actual runtime blocking
• Team-friendly: No per-user setup when sharing skills across an organization
• Consistent with existing patterns: Uses the same hook mechanism already in settings.json, just scoped to skill activation

🤖 Generated with Claude Code