Include skill_name in PreToolUse/PostToolUse hook payloads

Feature Request

Add a skill_name field to the JSON payload that Claude Code sends to PreToolUse and PostToolUse hooks.

Current Behavior

Hook input only contains the underlying tool name:

{
  "tool_name": "Bash",
  "tool_input": { "command": "git commit -m 'fix'" },
  "session_id": "abc123",
  "cwd": "/home/user/project",
  "hook_event_name": "PreToolUse"
}

When a skill like "commit" invokes the Bash tool, the hook sees tool_name: "Bash" — identical to a direct Bash call. There is no way to determine which skill (if any) triggered the tool invocation.

Proposed Change

Include the skill name when a tool call originates from a skill:

{
  "tool_name": "Bash",
  "tool_input": { "command": "git commit -m 'fix'" },
  "skill_name": "commit",
  "session_id": "abc123",
  "cwd": "/home/user/project",
  "hook_event_name": "PreToolUse"
}

When no skill is active, skill_name would be null or absent.

Why This Matters for Security

Security hooks need to distinguish who is driving a tool call, not just which tool is being called. Without skill context:

1. Per-skill security tiers are impossible to enforce. A deploy skill running Bash should be treated as dangerous. A commit skill running Bash should be treated as default. Today both look identical to the hook — they're just "Bash."

1. Security memory can't scope decisions to skills. If a user approves a pattern triggered by the "commit" skill, that approval shouldn't silently carry over to the "deploy" skill invoking the same tool. Without skill_name, memory systems can only key on tool_name, creating overly broad learned exceptions.

1. Audit trails lack attribution. Security logs can record that Bash was invoked, but not that it was the "deploy" skill that initiated it. Incident investigation requires knowing the full call chain.

1. Third-party skills from untrusted sources are a growing attack surface. Skills can be installed from repositories and may contain prompt injection. Security tools need to apply stricter policies to untrusted skills vs. built-in ones, but can't distinguish them without this field.

Implementation Notes

• The field only needs to be present in PreToolUse and PostToolUse events
• null or absent when no skill is active (backward compatible)
• Minimal payload size increase (one string field)
• Enables downstream security tooling without requiring any other protocol changes

Context

We build Tweek, an open-source security layer for AI coding assistants. We've built the infrastructure for skill-aware security tiers, skill-scoped memory, and skill-level audit logging — but none of it can activate because the hook protocol doesn't include skill context. This single field addition would unlock the entire capability.