disable-model-invocation hides commands from skill list, blocking user-initiated invocation

Problem

Commands with disable-model-invocation: true in their frontmatter (e.g., review.md, adversarial-review.md, cancel.md, result.md, status.md) are completely hidden from the skill list presented to Claude at conversation start. This means Claude has no awareness these commands exist.

When a user explicitly types /codex:review in conversation, Claude cannot route to it because it's not in the visible skill list. In practice, Claude either:

1. Silently reroutes to a different command (e.g., codex:rescue) that IS visible, or
2. Tells the user the command doesn't exist

Both outcomes are wrong. The user asked for a specific command by name and didn't get it.

Root Cause

disable-model-invocation: true conflates two separate concerns:

1. Preventing proactive model invocation (Claude shouldn't spontaneously decide to run a review)
2. Making the model aware a command exists (so it can route explicit user requests)

Currently one flag controls both. Commands with the flag set are invisible to the model entirely, even when the user explicitly requests them.

Affected Commands

Suggested Fix

Separate the two concerns. Options:

• Option A: Add commands with disable-model-invocation: true to the skill list but mark them as user-initiated only, so Claude knows they exist but won't proactively call them.
• Option B: Ensure the Skill tool resolver can match user-typed /codex:review to the command file even when the command isn't in the proactive skill list.
• Option C: Introduce a second frontmatter key (e.g., hidden: true vs disable-model-invocation: true) to distinguish "hide from model entirely" from "don't let model call proactively."

Environment

• codex-cli 0.117.0
• Plugin version 1.0.3
• Claude Code on Windows 11

Start by tracing how disable-model-invocation is processed when building the skill list and resolving user-typed commands. Compare proactive skill visibility with explicit /codex:review routing, then verify that disabled commands remain non-proactive but explicit requests resolve correctly.