Are skills even necessary? why bloat context with 10 openspec skills?

[da1z]

just updated to 1.0 and to be honest it looks like having 10 dedicated to openspec skills looks like over engineering. do we even need them? why bloat context with 10 skills? are they there so agent can decide to use them instead of me manualy invoking commands? so if i want to just use manual flow where i propose, apply, archieve myself then i can just remove skills?

[TabishB]

@da1z skills are progressively disclosed the context bloat is extremely minimal. The only thing that gets added is skill name + description.

In Claude Code for example skills and clash commands have now become the same thing and are treated the same way. A lot of coding agents are going down this route as well.

We're still figuring out how to handle this in the future, but this is less up to us as much as it is just following the standards being set in the industry.

[da1z]

To clarify by "context bloat" I mean decision surface area, not token count. I have 5 skills tailored to my tech stack and workflow. Adding 10 OpenSpec skills means the LLM now picks from 15 options, which can dilute how often it reaches for my domain-specific tools.

Maybe openspec skills can be consolidated into one skill with index and progressive disclosure of sub skills?

[evilsamaritan]

@TabishB
I was wondering the same thing. #590

The thing is, skills work like lazy context — and I'm working in a huge monorepo where there could potentially be 100+ skills. When I saw 10 openspec-* skills, I was a bit shocked 😄 Even if the context optimization gains aren't huge, it would still be a much better developer experience.

A couple of thoughts on what might work better — and could actually enable an approach where you have 1 skill with multiple flows:

1) I've already tested this (just a bit, but it seems to work) — if you use commands as bindings to a skill, you don't need to repeat the entire prompt.

.command/opsx/archive.md

Load and follow the `openspec-archive-change` skill. 
If already loaded in this conversation, skip loading and follow the existing instructions.

That's roughly how it looks. In some agents you don't even need this — you can trigger skills directly.

2) Haven't tested this one myself yet, but both Claude's own docs and some top-tier skills (e.g. Vercel) use this structure:

{{name}}/
  SKILL.md
  references/...

So the skill could provide general context on how to use OpenSpec — given that most OpenSpec commands will be needed anyway. The context will load most of the "knowledge" regardless, if anyone on the team uses this approach.

So my plan is to test this when I have time (or feel free to try it yourselves) — consolidate everything into one general skill + flows for each command. Then commands like archive.md would just instruct to use the skill + a specific flow.

In theory, this should work great. Something like this:

.skills/openspec/
  SKILL.md                    # general context + how to use OpenSpec
  flows/
    archive-change.md
    create-feature.md
    implement-task.md
    ...

.commands/opsx/
  archive.md                  # "Load openspec skill, follow archive-change flow"
  feature.md                  # "Load openspec skill, follow create-feature flow"
  implement.md            # "Load openspec skill, follow implement-task flow"

[antonio-ivanovski]

Using primary opencode. For opencode the init generates almost identical files under skills and commands. Mostly what I can see that the commands are bit more verbose compared to skills. Why have this duplication?

Personally will be removing the skills and rely just on the commands for the time being. Hopefully OC can merge commands+skills and have consistency.

[TabishB]

Thanks for the feedback everyone, this is under active investigation. We're looking at finding a better way to do this.

@antonio-ivanovski

Mostly what I can see that the commands are bit more verbose compared to skills. Why have this duplication?

Because some folks like to use natural language vs some like to have commands. In some agents skills and commands are the same thing, in others this isn't true.

There's just a lot of preferences to cater for here. I think the way to handle this is to just make this configurable for users so they can choose what to install / uninstall.