Issue: the disable-model-invocation: true frontmatter field is ignored for skills in .agents/skills/. Skills with this flag are still shown to the model and can be auto-inferred.
Actual: The flag works correctly in ~/.cursor/skills-cursor/ and .cursor/skills/, but is ignored in .agents/skills/.
Steps to Reproduce
Add disable-model-invocation: true to any .agents/skills/*/SKILL.md frontmatter
Start an agent conversation
Observe the skill still appears in the model’s available skills list
Expected Behavior
skills with disable-model-invocation: true should be hidden from the model’s skill list — only accessible via explicit /skill-name invocation.
Is it possible that you have the same skill in another folder, like .claude/skills/ or .codex/skills/, or a user-level ~/.agents/skills/, that doesn’t include the disable-model-invocation flag*? It’s possible that in attempting to dedupe the skills, a copy without the flag wins.
Generate an example skill with disable-model-invocation: true at .agents/skills/ and ask the agent if he see the skill in the <available_skills>section. It shouldn’t appear in this section.
Repeat the test on .cursor/skills (preferably with different skill name from the previous test)
Make sure you open new-session or re-open cursor to make an hard refresh after you change the either of the skills folder.
---
name: example-explicit-skill
description: >-
Drafts concise release notes from git history between two refs. Use only when
the user invokes /example-explicit-skill or asks to run the example explicit
skill — not for general changelog or release work.
disable-model-invocation: true
---
# Example Explicit Skill
This skill is an **example** of a project skill under `.agents/skills/` with `disable-model-invocation: true`. The agent should **not** auto-load it from ambient context; it applies only when the user names it (for example `/example-explicit-skill`).
## When to run
Proceed only if the user explicitly requested this skill. If they asked for release notes without naming this skill, do not use these instructions.
## Release notes workflow
1. Confirm the base and head refs (defaults: `main` and `HEAD`).
2. Run `git log <base>..<head> --oneline --no-decorate` to list commits.
3. Group commits by theme (features, fixes, chores). Skip merge commits unless they carry user-visible changes.
4. Write notes in present tense, user-facing language. Omit internal refactors with no external effect.
## Output template
....
## Quality checks
- Every bullet maps to at least one commit in the range.
- No speculative items; if scope is unclear, say so in one line under Highlights.
- Keep the full output under ~40 lines unless the user asks for detail.
I have tested this on an empty repo and it didn’t reproduce, for some reason in our repo it still happens.
From further investigation its not clear if its in the context or did the agent read files or did it exist in the context. Do you have any idea what might be the issue in our repo?
the “untracked” was suspicious for me so i asked the next question
do you see example-explicit-skill in the context or did you see it in the files
and i got this answer
I saw it in the context — specifically in the git status shown at the start of the conversation:
?? .agents/skills/example-explicit-skill/
It appeared as an untracked directory. It was not listed in the <available_skills> section provided by the system, which is why I marked it with (untracked) in my list. I should not have included it as an “available
skill” since it wasn’t actually in the skill list — that was a mistake on my part.
I didn’t see git status invocation so I don’t know where it got it from but it seems like the <available_skills> doesn’t contain the explicit skill
