Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/github/gh-aw/restricted-tool-triagenpx skills add github/gh-aw --skill restricted-tool-triagegit clone --depth 1 https://github.com/github/gh-awWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00040 | $0.01086 |
| Opus 5 | $0.00020 | $0.00543 |
| Sonnet 5 | $0.00008 | $0.00217 |
| Haiku 4.5 | $0.00004 | $0.00109 |
Grade A, and why
restricted-tool-triage scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 49 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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 MCPtoolsets, or omitsedit/bashentirely.
Procedure
-
Read the allowlist first, before acting. Before issuing any shell/file/MCP command, check the workflow's declared
tools:block (frontmatterbash: [...],edit:, MCPtoolsets:, 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 normal shell. -
On the first denial, stop and pivot — do not retry variants. A denial is not a request to try a slightly different phrasing of the same disallowed command (e.g. don't go from
git statustogit status --shorttogit diff --statas three separate attempts). Instead:- Identify the capability you actually need (e.g. "see which files changed").
- Map it to a tool/command explicitly present in the allowlist (e.g. use
git diff --name-onlyifgit diff:*is allowed butgit statusis not; use the already-available MCP toolset instead of rawread/shellfor file or repo introspection). - If no allowed tool can achieve the capability, stop attempting workarounds for that capability and route around it (skip the sub-task, or note the limitation in your output) rather than spending more of the denial budget.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 49 lines · 40 tokens per session scan A cf843438e4c2
restricted-tool-triage is a skill published in the GitHub repository github/gh-aw (5,084 stars, last pushed today), licensed MIT. It adds 40 tokens to every session and 1,086 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
watch-commit
Watch a GitHub commit for CI status changes using the gh-watch extension. Use when the user wants to monitor a commit's CI checks, wait for a build to finish, or track CI progress on a specific SHA.
ci-cd
CI/CD pipelines for GitHub Actions and Docker-based deployments — lint, test, build, push, deploy stages; environment secrets; branch-gated workflows; health-check rollbacks; and PM2/systemd service restarts.
deploy
Use when ready to ship — runs pre-push gates (lint, typecheck, build, tests, security sweep), commits, releases, and pushes. Standalone, never auto-invoked. Push always requires explicit confirmation. Trigger with /hyperflow:deploy, "ship it", "ready to push", "release", "cut a release", "deploy".
argot-setup-ci
Wire argot into a repository's GitHub Actions as a non-blocking configured check on every pull request — a job summary plus code-scanning annotations. Use when the user wants argot "in CI", "on PRs", "as a GitHub Action", or asks to "set up argot CI". Distinct from argot-setup (local checking) and argot-review-pr…
fixing
Diagnose why a PR's CI failed — compare the CI definition against the sandbox, classify the failure, and make the minimal repair. Use when a PR is red and you must work out why before changing anything.
codebase-argus
Portable Codebase Argus agent playbook for evidence-first multi-agent review of GitHub pull requests, CI failures, GitHub Actions logs, GitHub App webhook review, /argus PR comment commands, autofix branch planning, OpenAI/Claude/Gemini/Codex provider tribunals, downstream merge/rebase work, and long-lived fork sync…