Feature Request: Add source context to PermissionRequest hooks for skill-specific auto-approval

Summary

Add a sourceContext field to PermissionRequest hook inputs so users can distinguish between commands invoked from skills/slash commands versus direct CLI interactions. This would enable auto-approving trusted commands within user-defined skills while still requiring permission prompts for ad-hoc commands.

Problem

Currently, permission rules in Claude Code are global. If I want a skill to run subl -n .claude/ without prompting, I must add Bash(subl -n:*) to allowedTools — but this also auto-approves that command everywhere, not just within my skill.

Skills are user-defined trusted code, so it makes sense to give them elevated trust compared to ad-hoc Claude suggestions. But there's no mechanism to express "approve this command only when triggered by a skill."

Proposed Solution

Add context information to the PermissionRequest hook input:

{
  "session_id": "...",
  "tool_name": "Bash",
  "tool_input": { "command": "subl -n .claude/" },
  "permission_mode": "default",
  "sourceContext": {
    "type": "skill",
    "skillName": "edit-infra",
    "skillPath": ".claude/commands/edit-infra.md"
  }
}

When not invoked from a skill, sourceContext could be:

{
  "sourceContext": {
    "type": "direct"
  }
}

This would allow hook scripts to implement logic like:

#!/bin/bash
input="$1"
source_type=$(echo "$input" | jq -r '.sourceContext.type')
skill_name=$(echo "$input" | jq -r '.sourceContext.skillName // empty')

# Auto-approve all commands from trusted skills
if [[ "$source_type" == "skill" ]]; then
  echo '{"decision": "allow"}'
  exit 0
fi

# Otherwise, let normal permission flow continue
exit 0

Alternatives Considered

1. Pre-approve commands globally — Works but defeats the purpose of permission prompts for exploratory use
2. Wrapper scripts — Adds indirection and maintenance overhead for every command
3. Skill-level allowed-tools — Only restricts tools, doesn't auto-approve specific commands

Use Cases

• Skills that open editors (subl, code, vim)
• Skills that run build/test commands (npm run, pytest)
• Skills that perform git operations (git commit, git push)
• Any skill with predictable, safe bash commands the user has explicitly defined

Additional Context

This aligns with the principle that user-authored skills represent intentional, trusted automation — similar to how IDE extensions or shell aliases work. Users who write skills have already reviewed the commands; requiring re-approval on every invocation adds friction without security benefit.