{"version":"2.1.309","anchor":"skill-allowlist-matching-by-full-name-fork-skill-mcp-read-t","canonical_anchor":"skill-allowlist-matching-by-full-name-fork-skill-mcp-read-t","heading":"Nested skills allowed only by full name are handled separately","tier":"notice","area":"Skills","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.309\/e\/skill-allowlist-matching-by-full-name-fork-skill-mcp-read-t","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.309","markdown":"### Nested skills allowed only by full name are handled separately\n\nNested skills now carry an allowlistedByFullNameOnly mark when only their full name is allowlisted, and such commands are filtered like MCP prompts\n\n**Unclear.** Whether a nested skill listed in an allowlist by its plain name is still covered is not clear.\n\n**What**\n\nSkills are reusable instructions Claude can run, and they can sit in nested folders, which gives them a scoped full name as well as a plain name. A skill now carries `allowlistedByFullNameOnly` when its full name differs from the plain name that appears in the allowlist.\n\nA prompt-type command with `allowlistedByFullNameOnly` set is now left out by the same check that already left out prompts from memory stores and MCP servers.\n\nForked commands also work out which MCP read tools a hidden built-in can use.\n\n**Why**\n\nThis affects whether allowed-tools rules apply to skills in nested folders, and may change which skills or commands are shown or listed.\n\n- Area: Skills\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}