disable-model-invocation: true in SKILL.md blocks explicit user invocation via $ / Skill tool

[axisrow]

Problem

When a standalone skill has disable-model-invocation: true in its SKILL.md frontmatter, the skill is completely excluded from the system-reminder's available skills list. This means even when a user explicitly types $skill-name or /skill-name, the model cannot invoke it via the Skill tool because it doesn't appear in the available skills.

Expected Behavior

disable-model-invocation: true should only prevent the model from proactively invoking the skill on its own. When a user explicitly requests a skill via $skill-name, it should still work — the user's intent is clear.

Current Behavior

The flag completely removes the skill from the model's available skills list, making it impossible to invoke in any way (including explicit user request).

Reproduction

1. Create ~/.claude/skills/my-skill/SKILL.md with:

   ---
   name: my-skill
   description: My test skill
   disable-model-invocation: true
   ---
   # My skill content

2. In a session, type $my-skill
3. Model responds: "The skill 'my-skill' is not available"

Suggested Fix

When building the available skills list for the system-reminder, include skills with disable-model-invocation: true but mark them as "user-invocable only". The model should be instructed not to invoke these proactively, but should honor explicit user requests.

Analysis

The skill discovery in cli/src/modules/common/skills.ts returns all skills (no filtering by frontmatter). The filtering by disable-model-invocation happens upstream when generating the system-reminder. The fix should be in the system-reminder generation logic — either:

1. Include disable-model-invocation skills in the available list with an annotation
2. Or separate "model-invocable" vs "user-invocable" skill categories in the system-reminder

[github-actions]

I checked the HAPI codebase for this specific behavior.

In the current implementation, HAPI's skill discovery does not read or filter on disable-model-invocation. listSkills() scans the skill directories, parses SKILL.md, and only extracts name and description. That list is then returned unchanged through the CLI RPC and exposed by the hub API.

I also could not find code in this repo that builds Claude's system-reminder or removes skills from Claude's model-visible skill list based on that frontmatter flag. In the Claude path, HAPI passes requests into the Claude SDK and appends HAPI's own system prompt, but there is no HAPI-side filtering for disable-model-invocation.

Based on what is currently in this repo, the behavior you described does not appear to be implemented in HAPI itself. It looks more like upstream Claude Code / SDK behavior than a HAPI-specific filter.

Relevant code:

• cli/src/modules/common/skills.ts:76 - parses skill frontmatter, but extractSkillSummary() only uses name and description
• cli/src/modules/common/skills.ts:140 - listSkills() returns all discovered skills after dedupe/sort; no disable-model-invocation handling
• cli/src/modules/common/handlers/skills.ts:6 - listSkills RPC returns that list directly
• hub/src/web/routes/sessions.ts:412 - hub exposes the same list via GET /sessions/:id/skills
• cli/src/claude/claudeRemote.ts:113 - HAPI passes SDK options through to Claude; no skill filtering here
• cli/src/claude/sdk/metadataExtractor.ts:35 - HAPI reads SDK init metadata for tools/slash commands, not skill policy

Need more info:

• Can you confirm whether the failure happens in HAPI's web composer skill suggestions, or inside the wrapped Claude CLI after sending $my-skill?
• What HAPI version/commit are you running?

---

HAPI Bot