Workflow 003: Permission Management

Fresh

Overview

Control which skills Claude can invoke, what tools skills can access, and how permissions interact with skill invocation.

Permission Layers

Procedure

Step 1: Skill-Level Control (Frontmatter)

Control invocation at the individual skill level:

# User-only: Claude cannot auto-invoke
disable-model-invocation: true

# Claude-only: Hidden from / menu
user-invocable: false

Step 2: Global Permission Rules

Control via /permissions:

Disable all skills:

# Deny rules:
Skill

Allow specific skills only:

# Allow rules:
Skill(commit)
Skill(review-pr *)

Deny specific skills:

# Deny rules:
Skill(deploy *)

Permission Syntax

• Skill(name) - exact match
• Skill(name *) - prefix match with any arguments

Step 3: Tool Restrictions per Skill

Use allowed-tools to limit what a skill can do:

---
name: safe-reader
description: Read files without making changes
allowed-tools: Read, Grep, Glob
---

When active, Claude can only use the listed tools without asking permission. Your permission settings still govern all other tools.

Step 4: Context Budget Management

Skill descriptions consume context space. Budget: 2% of context window (fallback: 16,000 chars).

Check for issues:

/context

Override the limit:

export SLASH_COMMAND_TOOL_CHAR_BUDGET=32000

Permission Interaction Matrix

Control	What it affects	Where configured
disable-model-invocation	Whether Claude can auto-invoke	SKILL.md frontmatter
user-invocable	Whether skill appears in / menu	SKILL.md frontmatter
Skill() permission rules	Whether Claude can use Skill tool	/permissions
allowed-tools	What tools skill can use	SKILL.md frontmatter
User permission settings	Baseline tool approval	/permissions

Verification Checklist

• [ ] Side-effect skills have disable-model-invocation: true
• [ ] Permission rules match security requirements
• [ ] allowed-tools restricts each skill appropriately
• [ ] Context budget sufficient for all active skills
• [ ] Tested that denied skills are properly blocked