capability-lifecycle

name	capability-lifecycle
description	The aos capability lifecycle's front door. Use when the user asks to install, update, upgrade, remove, or customize an aos capability, mentions or shares a CAPABILITY.md or a capability directory, asks what capabilities are installed or what aos is, or asks about the manifest, the lockfile, or a harness cheat-sheet. Routes to the narrower skill that owns the job — capability-install, capability-upgrade, capability-remove, capability-onboard, capability-evolve, capability-import, capability-build, capability-contribute, capability-review — and carries the household layout, the install contract and the naming rules they all share. Do NOT use when one of those already matches the ask; this is the map, not the work.
metadata	{"aos":{"origin":"capability-lifecycle@0.3.7"}}

capability-lifecycle — the map

Capabilities are self-describing prompts; you are the installer. Judgment is yours; bookkeeping is aos-cap's (aos-cap --help — the lockfile is its file, never edit the YAML). Everything lives in the household <home> (default ~/aos): upstream/ the pristine kit clone, personal/ the user's private repo (their MOD files, the pinned renders harnesses symlink to, their private capabilities), .aos/ machine state. The diff gate is never optional. MOD.md states the user's personalization — what they changed from the shipped defaults, current state, edited in place: you re-apply it, you never overwrite it — and you never write anything to upstream (PR, issue, +1, push, fork, remote branch) without the user's explicit approval. The full rules: reference/contract.md. The overlay doctrine (interviews, transform, capture, promote/retire, persist): . Naming, installed skill names, and the uniqueness gate: — read it before authoring or installing anything that ships a skill. Names are : write and in prose and substitutes the installed name. A backslash-escaped slot stays literal, which is how this sentence survives its own render.