Add skills extension type for bundling agent/human guidance documents

Problem Statement

Extensions can bundle models, reports, workflows, vaults, datastores, and drivers — but there is no way to bundle guidance documents (markdown skills) that tell agents and humans how to use model methods effectively within a specific organizational context.

Today, if an extension author writes workflow guidance (e.g., story creation templates, hypothesis-driven task formats, design session checklists), they have two options: embed it in the model description (too long, always loaded), or ship loose markdown files with no discovery or loading mechanism.

This matters because the same model often supports very different workflows. A generic Redmine model serves any Redmine user, but an org-specific skill pack encodes that org's conventions (subject line format, templates, WIP limits, security checklists) on top of it. Skills need to be distributable separately from the model they extend.

Proposed Solution

Add a skills extension type — markdown guidance documents with YAML frontmatter, declared in the manifest, registered at install time, and loadable via CLI.

Manifest declaration

Flat list, consistent with other extension types:

skills:
  - skills/create-story.md
  - skills/create-task.md
  - skills/hypothesis-task.md

Skill file format

Standard markdown with YAML frontmatter:

---
name: create-story
description: Use when creating a Redmine story issue with the @webframp/redmine model
---

# Create Story
...

Validation: paths relative (no ..), files end in .md, frontmatter requires name and description, name uses letters/numbers/hyphens only, description under 500 characters.

Discovery (generated CLAUDE.md)

When swamp repo init runs, installed skills appear in the managed CLAUDE.md section, grouped by source extension:

## Skills

From `@webframp/redmine-appsvc-workflow`:
- `create-story` - Use when creating a Redmine story issue
- `create-task` - Use when creating a procedural Redmine task
- `hypothesis-task` - Use when creating a hypothesis-driven task
- `design-session-checklist` - Use when facilitating a design session

This keeps token cost minimal (one line per skill) while giving agents enough context to decide when to load a skill.

CLI commands

swamp skill list                    # List all installed skills
swamp skill show create-story       # Print full skill content to stdout
swamp skill show @ext:create-story  # Disambiguate across extensions

swamp skill show is the primary loading mechanism for both agents (via shell) and humans (in terminal). Name collisions across extensions require the qualified @extension:name form.

Runtime behavior

Skills are passive — swamp never executes them. It registers metadata at install time, surfaces descriptions in CLAUDE.md for discovery, and serves content via swamp skill show. The agent or human decides when to load and follow them.

Separation of concerns

Skills enable a clean split between generic integrations and opinionated workflows:

@webframp/redmine                    ← generic model, anyone can use
@webframp/redmine-appsvc-workflow    ← org-specific skills, depends on @webframp/redmine
@corp/redmine-security-review        ← another org's skill pack, same model

A skills-only extension needs no TypeScript, no deno.json, no tests — just a manifest and markdown files.

Alternatives Considered

1. Embed guidance in model descriptions — always loaded, bloats token context, cannot be org-specific without forking the model
2. Ship as loose markdown in repo — no discovery, no swamp extension pull, agents don't know the files exist
3. Structured manifest metadata (inline name/description/tags) — more verbose, duplicates frontmatter, not consistent with other extension types
4. Formal dependency graph between skills — over-engineering for markdown documents; agents resolve cross-references naturally by name

Context

We built this design while creating a @webframp/redmine extension with 4 workflow skills (create-story, create-task, hypothesis-task, design-session-checklist). The skills encode a prescriptive Kanban-based workflow with hypothesis-driven development, and are currently shipped as plain markdown in the extension repo with no formal integration.