Add active_skill field to PreToolUse hook input (enable skill-scoped permission rules)

Problem

A PreToolUse hook receives the session and the tool call, but nothing that identifies which skill (if any) is active when the tool runs. The current input looks like:

{
  "session_id": "...",
  "transcript_path": "...",
  "cwd": "...",
  "permission_mode": "default",
  "hook_event_name": "PreToolUse",
  "tool_name": "Write",
  "tool_input": { "file_path": "...", "content": "..." }
}

(Inside a subagent there's additionally agent_id/agent_type, but a skill is not a subagent — it runs in the main thread, so those never populate for skill-driven calls.)

As a result, a PreToolUse hook (and a permission rule) cannot tell a skill-driven tool call apart from a direct one. There's no way to express "this action is only allowed when it originates from skill X," and no way to reliably audit which writes came through a given skill.

Use case

Governing writes to sensitive files. I want writes to a sensitive file (e.g. a global CLAUDE.md, or a config file) allowed only when a specific validated skill is performing the edit — so every edit routes through that skill's validation/placement logic — and blocked otherwise.

Content sentinels (having the skill embed a known marker that the hook checks) are forgeable — the model and the skill share one trust domain, so the model can reproduce any marker the skill would. They can't serve as a reliable enforcement primitive. And agent_id only populates inside subagents, not skills. So there's no reliable operator-side workaround today — this is the blocking gap.

Request

Add an active_skill (or invoking_skill) field to the PreToolUse hook input: the name of the skill currently executing, if any.

Separately (and ideally together): support it as a permission-rule condition — e.g. allow Write(<path>) only when the active skill is my-edit-skill. The field alone would unblock the hook use case; the permission-rule integration would enable the sanctioned-path enforcement directly.

Non-goal (honest scope)

This would not be a hard security boundary against an adversarial model — a model can choose to invoke the skill. But it would give hooks the missing primitive to reliably distinguish skill-driven actions from direct ones, enabling sanctioned-path enforcement and accurate audit logging.