How I built advisory skill permissions for my desktop AI companion: a manifest the model can ignore

Description and use

The article details adding a permission manifest to Ankita’s skill system, enabling explicit declaration of allowed tools and scopes. The manifest is advisory; enforcement still occurs via per‑call approvals.

Problem

Skills lack a clear way to declare which tools they are allowed to use, leading to silent scope creep where a skill may call unintended tools.

Outcome

Introduced a clear permission manifest that standardizes skill scope declaration, improves authoring clarity, and prevents silent tool misuse, though it does not enforce boundaries.

Workflow

• Define allowed-tools and touches fields in the skill frontmatter.
• Parse the frontmatter with parseSkillFile, enforcing character limits and regex patterns.
• Validate entries, deduplicate, and reject malformed skills during load.
• Render catalog line with Permissions: allowed-tools: …; touches: … appended to the description.
• Add standing instruction in prompts: "When allowed-tools is present, prefer those tools and ask before using others."
• Keep enforcement separate: tool approvals remain the enforcement boundary; manifests are advisory.
• Monitor usage and gather feedback for future enforcement integration.

Evidence

Skills are instructions, not code. Nothing stops a model that loaded a review skill from also calling a shell tool, because the skill text never had a way to say "I only need these tools."

Source

Parsing is strict in cheap, honest ways. Each field is capped at 200 characters (PERMISSION_CHARS), a bound chosen to keep install prompts readable.

Source

Note the wording — "prefer" and "ask", not "you may only use" — and that the manifest is surfaced, never fed into a filter.

Source