AnthropicClaude Certified Architect – Foundations2026-103.2 Create and configure custom slash commands and skills
Separate skill approval from tool restriction
Completed by the knowledge check
Learning objective
Distinguish the guide’s intended tool restrictions from current behavior: allowed-tools only pre-approves tools for the invocation turn; disallowed-tools or permission deny rules restrict access.
Core idea
allowed-tools grants approval for listed tools during the turn that invokes a skill. It does not make that list exclusive. A tool omitted from the field remains callable under the normal permission configuration. Consequently, allowed-tools: Read Write Edit does not establish that a scaffolding skill cannot use the shell.
Use disallowed-tools to remove tools while the skill is active, or permission deny rules for a restriction across skills and prompts. Keep these mechanisms separate from a sentence such as “do not run shell commands.” The sentence guides Claude’s choices; the configuration governs tool access.
The general distinction between tool availability and approval is covered in 0.6. Here the deciding detail is the skill lifecycle: both a frontmatter grant and a frontmatter restriction clear when you send your next message, even though an invoked inline skill’s instructions can remain in conversation context.
How it works
Pre-approve only what needs a grant
The allowed-tools field accepts a space-separated string, comma-separated string, or YAML list. Listed tools can run without per-use approval during the invoking turn, subject to permission rules that still take precedence. The field is an approval convenience, not an allowlist that removes everything else.
For a file-scaffolding skill, separate the needed grant from the shell restriction:
---
name: scaffold-endpoint
argument-hint: "[resource-name]"
disable-model-invocation: true
allowed-tools: Read Write Edit
disallowed-tools: Bash
---The grant covers file tools, and disallowed-tools: Bash removes Bash while the skill is active. This example names the tool it excludes; it is not a claim that all other execution routes are unavailable. Define restrictions against the actual tool pool rather than treating a familiar tool name as an exhaustive capability boundary.
You can also pre-approve a matching tool pattern instead of granting the whole tool. The skills documentation gives examples such as Bash(git status *). A narrow grant reduces the operations approved by that field, but operations outside its pattern still follow baseline permissions. Narrow pre-approval and explicit denial answer different questions.
Account for the turn boundary
The grant clears when you send your next message. Invoking the skill again reapplies it for that turn. The inline skill content can stay in context across later turns, so you cannot infer active approval from the fact that Claude still knows the skill’s instructions.
disallowed-tools also clears on the next user message. If the next prompt asks the skill to continue, a prior frontmatter restriction is not a persistent session-wide ban merely because the body remains visible. Use permission deny rules when the restriction must survive follow-up prompts and apply outside that invocation.
This distinction changes how you assess a multi-turn workflow. A skill that is shell-restricted during its invocation is not thereby a shell-restricted environment for the rest of the session. Decide whether the requirement is per invocation or persistent before selecting the configuration surface.
Deny operations through permission settings
Claude Code evaluates permission rules in the order deny, ask, then allow. A matching deny wins over an allow rule, and a matching ask wins over an allow rule. More specific allow rules do not carve exceptions out of broader denies.
To remove Bash across project skills and prompts, the project settings file .claude/settings.json can contain this permission configuration:
{
"permissions": {
"deny": ["Bash"]
}
}A bare tool name removes that tool from Claude’s context. A scoped deny such as Bash(rm *) leaves the tool available but blocks matching calls. Do not confuse a selected-command denial with removal of the entire shell tool. /permissions lets you inspect the rules and the settings files they come from.
There is also a documented exception: neither permission deny rules nor disallowed-tools can remove EndConversation while another tool remains available. The scaffolding example does not depend on denying that tool, but the exception matters if you describe either mechanism as an unconditional removal of every possible tool.
Recognize organization-level limits on skill grants
Anthropic documents allowManagedPermissionRulesOnly in managed settings. When an organization enables it, Claude Code ignores allowed-tools in affected project and personal skills. Their listed tools instead go through managed rules and normal approval behavior. This support requires Claude Code v2.1.282 or later.
That means a checked-in grant is not a universal promise of prompt-free execution on every managed machine. If approval behavior differs, inspect the managed configuration rather than expanding the skill’s grant indefinitely. The skills documentation points to /status for skills whose grants Claude Code has ignored during the session.
Key distinctions and trade-offs
Grant versus restriction: allowed-tools approves listed operations. disallowed-tools removes listed tools while active. Omitting a tool from the grant does not deny it.
Invocation turn versus persistent policy: Frontmatter effects clear on the next user message. Permission deny rules apply across prompts and skills according to their settings scope.
Prompt guidance versus enforced configuration: The body can say which operations the workflow should perform. Permission controls decide what Claude Code permits. Both can be useful, but they provide different guarantees.
Per-skill restrictions let you tailor one workflow without removing capabilities from every other task. Persistent denies provide a broader boundary but can also prevent unrelated legitimate work. Select the scope that matches the stated requirement and inspect the actual rule, not only the skill’s prose.
Architecture / decision scenario
A code-generation team creates /scaffold-endpoint to write a resource handler and tests. The author sets allowed-tools: Read Write Edit and declares the workflow safe from shell execution. That conclusion is unsupported: Bash is omitted from the grant, not removed from the tool pool.
For an invocation-specific shell restriction, the team adds disallowed-tools: Bash to the frontmatter. For a project requirement that no prompt or skill use Bash, it instead places "deny": ["Bash"] under permissions in .claude/settings.json. The team inspects /permissions to confirm the persistent rule and recognizes that frontmatter-only restrictions end on the next user message.
On a managed installation, allowManagedPermissionRulesOnly can also prevent the skill’s file-tool grants from being honored. The team checks that configuration before interpreting an approval prompt as a broken skill. The final design separates what the workflow needs approved, what it must not access, and how long each decision lasts.
Common exam traps
- Treating
allowed-toolsas the complete available tool list. - Assuming an omitted shell tool is denied.
- Expecting an invocation grant or restriction to last across later user messages.
- Using an allow rule to override a matching deny rule.
- Treating a prose prohibition as equivalent to permission configuration.
- Ignoring managed settings when a skill’s pre-approval does not apply.
Where the exam guide differs
The exam guide describes allowed-tools as a way to “restrict tool access during skill execution.” The skills documentation defines it as pre-approval for the invoking turn and explicitly says it does not restrict availability. Recognize the guide’s intended mapping when an item uses that wording, but implement a prohibition with disallowed-tools or permission deny rules. The learning objective preserves the comparison while teaching the documented distinction.
What to remember
A skill grant is not a tool boundary. Use allowed-tools for temporary pre-approval, disallowed-tools for temporary removal, and permission denies for restrictions across prompts. Verify the rule’s scope, lifetime, and managed-policy behavior before relying on it.
Knowledge check
A scaffold-endpoint skill sets allowed-tools: Read Write Edit, and its author says it can no longer run shell commands. The team needs Bash unavailable while this skill is active, without removing it from other work in the project. What should the team do?
disallowed-tools: Bash to the skill’s frontmatter"deny": ["Bash"] under permissions in .claude/settings.jsonallowed-tools pre-approves the listed tools; it does not make the list exclusive, so Bash stays callable under normal permissions. disallowed-tools removes it while the skill is active. A sentence in the body only guides Claude, and a project deny rule would remove Bash from every prompt and skill, which the requirement excludes.A skill sets disallowed-tools: Bash, and Claude does not use the shell while the skill runs. The developer then sends “continue”, and Claude runs a Bash command while still following the skill’s steps. What explains this?
disallowed-tools applies only to skills that run with context: forkallowed-tools and disallowed-tools clear when the user sends the next message, while an invoked inline skill’s content stays in the conversation. Claude can therefore still follow the steps without the restriction in force. A restriction that must survive follow-up prompts belongs in a permission deny rule.A project’s .claude/settings.json denies Bash. To let tests run, a developer adds the allow rule Bash(npm test *), but Claude still cannot run tests. The team wants to deny rm commands while keeping the shell available for other work. What should it change?
Bash deny with a scoped deny such as Bash(rm *)npm test invocation the team relies onBash deny removes the whole tool; a scoped deny blocks only the matching commands and leaves the rest of the shell available.A skill grants allowed-tools: Read Write Edit. On personal machines it writes files without prompting; on company-managed laptops with the same Claude Code version, every write asks for approval. What is the likely cause?
Write and EditallowManagedPermissionRulesOnlyallowManagedPermissionRulesOnly , Claude Code ignores allowed-tools in project and personal skills, and the listed tools go through managed rules and normal approval. The grant needs no separate allow rule and applies on every invocation, so neither explains the difference. Inspect the managed configuration — /status lists ignored grants — rather than widening the skill’s grant.References
- Anthropic, Extend Claude with skills
- Anthropic, Manage permissions
- Anthropic, Settings
- Anthropic, Claude Certified Architect – Foundations Exam Guide