retirelisted

# Retiring a project Adoption's reverse, run per project. Uninstalling the plugin removes the skills and hooks and nothing else — it never touches a project — so the manifest, the sweep cache and the records stay behind without this. The scripts do the deleting; this skill is the sequence around them: the snapshot question first, then exactly the boxes the user checked, in dependency order. **Slash-invoked only, by design.** Like `/wss:lane-record-sync`, it has no flag and must never fire from a phrase, a batch or another skill — "we should clean this up" is not a request to delete a project's records. The user types `/wss:retire` or nothing happens. ## What it is not **Not the plugin uninstall itself.** That one is the harness's command and the user's to run; the *checkout* removal is this skill's. Either way it is the *last* step, not the first — run early it removes the skill mid-walkthrough. **Not a writer.** Orchestrator, owns nothing — [`WSS.OWNERSHIP.md`](../../wss/workflow/WSS.OWNERSHIP.md). The scripts delete, the export script archives; this skill decides, asks and reports. It does not commit: the deletions land as a dirty tree, and what to do with that tree is the user's call, stated in the close-out. **Not for the suite's own repository — as a *project*.** `wss-retire-workflow.sh` refuses a `--dir` resolving to the suite's tree outright; do not work around it. `--suite` is a different act on a different target: it removes the installation rather than retirin