Agent frontmatter uses `allowedTools:` — should this be `tools:`? (affects 11 of 12 agents)

[LighttheLastFlare]

Hi — first, thank you for this repo. I'm new to using Claude Code and I've been using it as my main learning material; it's been genuinely excellent.

I hit something while working through /weather-orchestrator and I think it's a real bug, but I'm new enough that I may well have misunderstood how this works — so please treat everything below as an observation rather than a claim. Happy to be told I've got the wrong end of the stick.

Disclosure: I worked through this with Claude Code, which also helped write this issue.

What I noticed

Agents in .claude/agents/ declare tool restrictions with allowedTools:. From your own best-practice/claude-subagents.md:23, the subagent field looks like it should be tools:. If that's right, then because unrecognised YAML keys are ignored rather than rejected, these restrictions may not be applied at all — the agents would inherit every tool.

What made me look

/weather-orchestrator failed for me. weather-agent declined to fetch, citing tool restrictions:

"I've invoked the weather-fetcher skill via the Skill tool, but it returned the skill instructions rather than fetching and returning temperature data… my toolset intentionally excludes them to enforce this boundary."

The agent listing showed it holding all tools, which is what pointed me at the field name.

Run	Config	Tool uses	Tokens	Outcome
1	as shipped	5	27,077	Preamble, no data
2	as shipped	5	26,391	Nothing returned
3	maxTurns: 10	1	24,943	Declined to fetch
4	tools: + contract edit	3	15,125	40.5°C ✅

A second thing, possibly related

weather-agent's execution contract (lines 45–49, 80–81) forbids "reading the skill's instructions and executing them inline" and "calling WebFetch". As I understand it, Skill() loads instructions into context rather than returning data, and weather-fetcher's instructions say to use WebFetch — so the agent may be being told to invoke the skill and then not act on it. This seemed to need addressing separately from the field name. I could easily be wrong about the mechanism here.

The bit I'd most want to flag

If the field name is indeed the issue, correcting it doesn't look like a safe find-and-replace, because those tool lists would then take effect for the first time:

Agent	Effect of enabling its declared list
weather-agent	Removes WebFetch — which the preloaded skill appears to need
development-workflows-research-agent	Grants Write/Edit/Agent, though its body says "Do NOT modify any local files"
5 × workflows/best-practice/*-agent.md	Grants Write/Edit to agents described as read-only

My understanding is that a skill's allowed-tools: only suppresses permission prompts for tools the caller already has, rather than granting new ones — so the agent would need WebFetch itself. If that's right, the current situation may be masking tool lists that don't match their agents' descriptions.

Also worth mentioning: implementation/claude-subagents-implementation.md:30 reproduces the weather-agent frontmatter with allowedTools:, so it may be worth updating alongside.

Already known?

I checked before posting — the NLPM audit in #68 mentions the frontmatter difference under quality issues, so this may already be on your radar in some form.

Thanks again for the repo — it's taught me a great deal, including how to find this. Very happy to open a PR for any part of it if that's useful, and equally happy to close this if I've misread something.