Skip to content

Allow opting out of model invocation for installed skills (large monorepo skill-budget pain) #2654

Closed

Description

@echarrod

Problem

Since v0.8.4 (PR #2099, closing #2098), specify init --ai claude writes disable-model-invocation: false on every generated SKILL.md, and the toggle was removed as "redundant" because the new default opts skills into auto-invocation. There is no opt-out flag.

This is a real problem in large monorepos that already register many domain skills. Claude Code reserves a small fraction of context for the skill-listing budget; when that budget is exhausted, lower-priority skills get truncated and Claude loses visibility on them entirely. Adding the 11 spec-kit skills as model-invocable pushes us over the limit and silently drops other skills we use far more often.

Two specific pain points:

  1. Skill-listing budget exhaustion. With ~50 skills already in play (CI helpers, MR workflows, service tooling, etc.), the spec-kit 11 push us past the default skillListingBudgetFraction. The cheapest fix is to make spec-kit skills user-invocable only, so they cost nothing in the listing.
  2. Over-triggering on generic prompts. Several spec-kit skill descriptions (speckit-implement, speckit-tasks, speckit-plan) are generic enough that Claude auto-invokes them on prompts that have nothing to do with SDD — e.g. someone asking to "implement" or "plan" something unrelated.

Workaround

We've patched our internally bundled copy to set disable-model-invocation: true on all 11 skills. But every fresh specify init reverts this, so we either lose the fix on upgrade or have to maintain a long-running patch.

Proposal

Add a --no-model-invocation flag to specify init (and persist to the init-options file) that emits disable-model-invocation: true in generated SKILL.md frontmatter. Default behaviour stays as-is (model-invocable). Opt-in users get manual /speckit.* invocation only.

Alternatively, a per-skill override in a config file would also solve it.

Happy to send a PR if the direction is welcome.

Activity

  1. mnriem commented on May 22, 2026

    @mnriem
    Collaborator

    Thanks for the detailed write-up — the skill-listing budget exhaustion problem is real and we'd welcome a PR for this.

    One scope adjustment: rather than a top-level --no-model-invocation flag on specify init, this should be delivered as a Claude-specific integration option via --integration-options:

    specify init my-project --integration claude --integration-options="--no-model-invocation"

    The extension point is ClaudeIntegration.options() — same pattern Codex and Copilot use for their --skills flag. Implementation would be:

    1. Add a --no-model-invocation option in ClaudeIntegration.options()
    2. Thread the parsed flag through setup() → post_process_skill_content() to flip the hardcoded "false" to "true"
    3. Update tests in tests/integrations/test_integration_claude.py

    Default behavior stays as-is (model-invocable). The flag should also persist through init-options so specify integration update claude respects it.

    Happy to answer questions on the integration internals if you hit any snags.

  2. github-actions commented on Sep 11, 2026

    @github-actions
    Contributor

    This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed in 30 days if no further activity occurs.

  3. github-actions commented on Oct 11, 2026

    @github-actions
    Contributor

    This issue has been automatically closed after 90 days without activity. To request reconsideration, please provide updated reproduction details, the currently affected version or environment, and the present impact. Ask a maintainer to reopen this issue if it is fundamentally the same problem. If the scope or reproduction has materially changed, create a new issue, link this one, and explain what has changed.

  4. echarrod commented on Oct 11, 2026

    @echarrod
    ContributorAuthor

    Picked this up following the direction above: #4919 adds --no-model-invocation as a Claude integration option, touching only Claude integration files (per the review on #2866). Could this issue be reopened so the PR can close it? If the approach is accepted, I'm happy to follow with equivalent PRs for Droid, Alquimia, Vibe, Copilot and Codex. (Comment drafted by Claude Code (claude-opus-5-5, autonomous) for @echarrod.)

  5. reopened this on Oct 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions