capability-remove

capability-remove

Not in context yet? Load the capability-lifecycle skill first — the map, the contract, and the Experience rules.

1. aos-cap show <id> → the entry: artifacts, links and uses_links (including the capability's tool binary, recorded as an artifact), cron_owned, config keys, env variable names, scripts.
2. Scope: removing the capability entirely, or from one harness while it stays installed elsewhere? Per-harness removal: run step 4 for that harness only and skip its render deletion (the render is shared — it stays), then re-record the reduced set (start from aos-cap show, drop that harness's links/artifacts/jobs, keep everything else), then step 6's verify scoped to that harness. The lockfile entry and the MOD file both stay. Skip step 5. Step 3's dependents check still applies scoped to this harness (a capability installed here that depends on this one). Note the lockfile's cron_owned is a flat id list with no harness dimension (§5.5), so identify this harness's jobs by introspecting the harness, not by reading the lockfile. Whole removal continues below.
3. Dependents check: another entry in aos-cap list whose manifest depends.capabilities or uses names this one → say so; stop unless the user insists (then remove dependents first). A dependent's uses_links point into this render, so removing it first is what keeps them from dangling.
4. Un-write per the cheat-sheet's Removal section (load the capability-lifecycle skill's reference/harness-<harness-runtime>.md now), in its stated order — typically: jobs → skill symlinks (delete the links and uses_links; then send only <aos_home>/rendered/<id>/ to the OS trash — gio trash, trash-put, or the platform's own; never rm -rf, never anything under personal/, and never the MOD.md — recoverable from the trash) → marker blocks → config keys → .env lines (ask first) → agents this capability created and nothing else uses (never an adopted one — contract) → scripts/hooks (revoke each hook's consent record first) → its tool (uv tool uninstall). A recorded link into <aos_home>/vendor is a referenced third-party skill: unlink it, and offer to drop the vendor clone only if no other entry links into it. Its machine-local state under <aos_home>/.aos/ is not in the lockfile, so nothing walks it backwards — removing kb leaves kb-principal.yml and kb-registry.yaml behind. Offer to delete them, and say what each is: the principal list (who authors writes on this machine) and the registry (the list of every base). Both are the user's, not the capability's — an unasked deletion loses answers they gave; a re-install would adopt the old values silently, which is right often enough to be worth asking about.
5. Tell the user their MOD.md stays: "your answers survive — in your personal repo, reinstalling brings it back personalized."
6. Verify: re-introspect until no metadata.aos.origin, aos: names, marker blocks, or links into rendered/<id>/ remain; aos-cap remove <id>; friendly close.