[ENHANCEMENT] Rename disable-model-invocation to model-invocable for consistency with user-invocable

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Rename disable-model-invocation to model-invocable for consistency

Problem

The two frontmatter fields that control skill invocation use inconsistent naming conventions:

• user-invocable: true/false — positive boolean
• disable-model-invocation: true/false — negated boolean

This asymmetry makes the mental model harder than it needs to be. You have to invert disable-model-invocation every time you read it, and the combination table becomes a logic puzzle:

| Setting | Value | Meaning |
|---|---|---|
| user-invocable: true | ✅ User can invoke | Intuitive |
| disable-model-invocation: true | ❌ Model cannot invoke | Double negative |
| disable-model-invocation: false | ✅ Model can invoke | Triple negative? |

Proposed Solution

Proposal

Replace disable-model-invocation with model-invocable, matching the pattern of user-invocable:

---
name: deploy
description: Deploy the application to production
user-invocable: true
model-invocable: false
---

This makes the four combinations immediately readable:

| user-invocable | model-invocable | Who can invoke |
|---|---|---|
| true (default) | true (default) | Both user and model |
| true | false | User only |
| false | true | Model only |
| false | false | Neither (disabled) |

Migration

disable-model-invocation could be supported as a deprecated alias for a release or two to avoid breaking existing skills.

Related

• #19141 — Documents the existing confusion between these two fields

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

_No response_

Additional Context

_No response_