Canonical skill model and loader (metadata + body; tool-base + per-project)

[Ryan-Atkinson87]

Build the canonical skill model and loader — the single, provider-neutral rule library that all instruction files are rendered from (Spec §17.1 solves the drift problem by having one canonical set, never two hand-maintained copies).

Spec §17.3 (Layer 1 — canonical skills), §17.6 (where the canonical set lives), §17.2 (three-layer overview).

Acceptance criteria

• A structured Skill model carrying the Spec §17.3 metadata: id, stage, executor (ai | engine), applies_to (neutral | provider list), specialities (optional list), and body (Markdown).
• stage is constrained to the Spec §17.3 lifecycle stages: plan, implement, test, contract-verify, review, qa, integrate, escalate, cross-cutting.
• A loader reads the tool-level base skill set (versioned with the tool, applied to every project) and merges per-project additions/overrides declared in the execution profile (§17.6).
• Override semantics are defined and tested: a per-project skill with the same id replaces the base skill; new ids are added.
• Malformed skill metadata (unknown stage, bad executor value) fails fast with a clear error.
• The model is the seed for mapping the existing Trive/code_runner skills onto stages (Spec §4.1 table) — loader can ingest the current .claude/skills shape or a defined canonical format (document which).
• Unit tests: base load, per-project override by id, neutral vs provider applies_to, speciality filtering field present and queryable.

Notes

This issue defines and loads the skills; composition into personas is #20 and rendering is #22. Keep it provider-neutral — applies_to tags carry provider specificity, the model itself stays generic.

Depends on: #1