Add skills/instructions/workflows support extensions to support project cross-cutting concerns

[AlexanderAshitkin]

Problem Overview

In the current design extensions are vertical - they add a command, a hook, a tool integration. SpecKit extensions can ship capability, but not the knowledge of how to use it. For example, all 152 extensions advertise exactly two things — commands and hooks. Nothing else.

In reality capabilities inherently contain with a horizontal part - a reusable recipies for using that capability in this codebase. And that part currently has no convenient place to live inside the extension.

Consequently, extension installs the capability and after that the team separately hand-copies the guidance into every repo,
creating additional work and discrepancies.

Say I write an extension involving design of a specific database:

• The vertical part — "we always use additive migrations, never destructive ones" - something which could be put in a
  command.
• The horizontal part — logic to scaffold a migration, inspect a schema, generate a repository class. This is difficult
  to ship today.

This isn't specific to databases. It's the same for anything where "here's our rules" is only half of "here's how we
work with the tool." Also, please consider that many operations could be down through a pure vibe coding. Teams could
have reasonable expectations, that rules codified in extended spec-kit commands are not bypassed by general chat
sessions. The change also has a potential for context and tokens efficiency improvements.

Real life case

My team installs a secure-design extension alternating specify and some other commands. It contains skills for security
review in different subject areas (UI/Database/Backend).

Spec Kit can't install it, so we maintain a wrapper whose entire job is to reach into the installed extension, extract
the skill, and install it separately.

That wrapper is redundant and inconvenient:

• It routes around the CLI leading to inconsistencies.
• The extracted skill falls outside the extension lifecycle (e.g. specify extension remove doesn't clean it up).
• Every team that hits this writes their own scripts version.

Why the existing layers don't cover it

I want to pre-empt the obvious "just use X" answers, because I went looking for X first.

Why not a preset? Presets override templates and commands.

Why not a bundle? A bundle contains pointers to an existing Spec Kit primitive a bundle installs, it cannot extend them.

Why not skills, they already exist? There's no way to declare a skill that could serve as a universally applicable rule
for a repository once extension installed.

Proposed solution

Extend extension.yml and existing mechanisms to support installation of additional primitives:

provides:
  commands: [ ... ]        # today
  hooks: [ ... ]           # today
  templates: [ ... ]       # today

  skills: [ ... ]          # model-invoked guidance, no command behind it
  instructions: [ ... ]    # always-on guidance, harness-native
  workflows: [ ... ]       # repeatable procedures that ship with the capability

Instructions are harness-specific (Claude - .claude/rules/*.md, Copilot - .github/instructions/*.instructions.md,
Cursor- .cursor/rules/*.mdc), and that's up to discussion. So this can't be one path — it has to be specific
per-integration, and it has to degrade honestly on agents that can't do it rather than emulating something they'll
ignore.

Precedent

This wouldn't be a new kind of change to provides::

• Add support for extensions or variations #892, the founding extension proposal, included provides.memory alongside commands and templates. Templates
  shipped; memory was dropped during implementation without a recorded decision. I read this as descoped, not decided
  against.
• feat(presets): Pluggable preset system with catalog, resolver, and skills propagation #1708 → feat(presets): Pluggable preset system with catalog, resolver, and skills propagation #1787 extended provides: with templates for a directly analogous reason: "the extension system
  supports commands and hooks but has no way to provide custom artifact templates."

So the mechanism has been extended before, for this exact class of reason. This would be the next instance rather than a
novel design.

Questions to discuss

1. The horizontal/vertical notation - capability plus the knowledge of how to use it.
2. Which of the three is worth doing, and in what order?
3. Dealing with "instructions".
4. Implementation path.

I have a working prototype of the skills and instructions, but requesting a discussion as per CONTRIBUTING.md.