Pi: make generated OpenSpec skills explicitly invoked #2156

The problem, in one or two sentences

I use Pi and want to choose when to enter an OpenSpec workflow, rather than have its workflow skills advertised to the model during every task. OpenSpec doesn't need to stay in the model's attention when the user isn't doing spec-driven work; I'd like a cleaner default context while keeping the workflows available on demand.

Who this affects

Pi users who prefer explicitly controlled OpenSpec workflows, including those using skills-only delivery. This is a Pi-specific request, not a proposal to change invocation behavior for other agents.

Pi already loads full skill instructions lazily. The concern here is the names and descriptions advertised for automatic selection: they add workflow choices and potential distractions even during unrelated work, not the full skill bodies or a measured token/performance cost.

Alternatives considered

• Commands-only delivery: avoids advertising the skills, but removes explicit /skill:… access and doesn't cover skills-only installations.
• Manually editing frontmatter: adding disable-model-invocation: true makes a Pi skill explicit-only, but generated files can be overwritten by openspec update.

Why it's worth the added complexity

Explicit-only skills stay installed and usable without remaining in the model's automatic-discovery context. When the user invokes /skill:openspec-propose, Pi loads the instructions normally, with no manual file handling. This keeps OpenSpec available when requested without making it a standing workflow choice for every task.

There is a trade-off: making this the default would remove automatic natural-language discovery for Pi users who currently rely on it. I'd like maintainer input on whether that default is appropriate; I'm not assuming automatic discovery is a bug.

What I have in mind

Generate Pi-targeted OpenSpec skills with:

disable-model-invocation: true

Pi documents this field as keeping skills available through explicit invocation while excluding them from automatic model selection.

The suggested behavior would:

• Apply during initialization and updates, including skills-only delivery.
• Preserve explicit /skill:… invocation and existing Pi prompt commands where installed.
• Leave other agents unchanged, without adding a new user-facing flag.

Related work and contribution

• Are skills even necessary? why bloat context with 10 openspec skills? #611 discussed manual versus automatic workflow selection, including this frontmatter field. Making skill/command installation configurable addressed part of that discussion, but doesn't provide explicit-only skills.
• Move OpenSpec to Agent Skills only (deprecate generated commands) #2022 proposes skills-only delivery, where preserving explicit skill access matters independently of prompt commands.
• feat(skills): openspec-beta skills, installed once per machine with migration and revert #2134 overhauls beta skills but says today's generated skills remain unchanged.

Would you consider this appropriate for the existing Pi integration, or prefer addressing it through the skills overhaul? I'm happy to contribute a focused change if invited, and to adapt the approach based on the discussion.