restricted-tool-triage

# Restricted Tool Triage Use this skill whenever you (the agent) are executing inside a gh-aw workflow whose frontmatter declares a narrow `tools:` allowlist (e.g. a short `bash: [...]` list, a scoped MCP `toolsets`, or no `read`/`shell` at all) and you hit — or are at risk of hitting — a "permission denied" / tool-denial response from the harness. ## Why this matters gh-aw enforces a **hard, non-renewable denial budget** per session (commonly 3 denied tool calls). Once the threshold is reached, the harness emits `guard.tool_denials_exceeded` and aborts the entire session immediately — no further turns, no partial credit, no chance to recover. Treat every tool denial as spending down a scarce budget, not as a way to probe what's allowed. ## Triggers - A tool call returns "permission denied by workflow tool permissions" or similar. - You are about to try a shell/read/write command and are unsure if it's in the declared `tools:` allowlist. - The workflow frontmatter shows a short/explicit `bash:` list, restrictive MCP `toolsets`, or omits `edit`/`bash` entirely. ## Procedure 1. **Read the allowlist first, before acting.** Before issuing any shell/file/MCP command, check the workflow's declared `tools:` block (frontmatter `bash: [...]`, `edit:`, MCP `toolsets:`, etc.) if visible in context, or infer it from the first denial message, which echoes the exact denied command. Do not assume general-purpose shell access is available just because the environment looks like a norm...