@codyswann/lisa 2.257.1 → 2.258.0

package/plugins/lisa-cursor/skills/lisa-tear-down-automations/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lisa-tear-down-automations
-description: "Remove every recurring Lisa automation that /setup-automations registered for this project — whatever is actually registered under the lisa-auto-<project>-* prefix, including the opt-in learnings-audit gardener — using the CURRENT runtime's native scheduler — Codex automations or, on Claude, /schedule. This skill is a declarative specification: it identifies WHICH automations to remove; it does not run teardown scripts. Carries no fixed list of loops: the registration set is the roster. Removes only this project's Lisa automations — never other projects' automations or non-Lisa ones. Leaves checked-in runbook files on disk. The inverse of /setup-automations."
+description: "Remove recurring Lisa automations that /setup-automations registered for this project — either the whole lisa-auto-<project>-* fleet by default, or one named loop registration when approving a policy-obsolete proposal — using the CURRENT runtime's native scheduler — Codex automations or, on Claude, /schedule. This skill is a declarative specification: it identifies WHICH automations to remove; it does not run teardown scripts. Carries no fixed list of loops for fleet teardown: the registration set is the roster. Removes only this project's Lisa automations — never other projects' automations or non-Lisa ones. Leaves checked-in runbook files on disk. The inverse of /setup-automations."
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
 
@@ -8,7 +8,9 @@ allowed-tools: ["Skill", "Bash", "Read"]
 
 This skill is a **specification, not a script.** It tells the current runtime which recurring Lisa
 automations to remove — the ones `/setup-automations` created for THIS project — and the runtime
-removes them with its **native** scheduling mechanism.
+removes them with its **native** scheduling mechanism. With no loop argument it removes the whole
+project fleet. With a loop id argument (for example `monitor` or `learnings-audit`) it removes only
+that one registered loop.
 
 ## Runtime scheduler (branch on the current runtime)
 
@@ -21,11 +23,15 @@ removes them with its **native** scheduling mechanism.
 
 ## Scope (remove only what setup created)
 
-- Remove **every** automation `/setup-automations` registered for the current project — the whole
+- By default, remove **every** automation `/setup-automations` registered for the current project — the whole
   set found under the stable `lisa-auto-<project>-` name prefix, whatever it currently contains.
   **Membership is registration, not a roster** (`automation-runbook-contract`): sweep the prefix and
   remove what is there. Do **not** work from a fixed list of loop names — a list drifts the moment a
   loop is added, which is exactly how the opt-in gardener came to be orphaned.
+- When `$ARGUMENTS` names a loop id from a `policy-obsolete` teardown proposal, remove only that
+  loop's registration under the same prefix, e.g. `lisa-auto-<project>-monitor`. Report every other
+  project automation left in place. If the named loop is absent, that single-loop teardown is a clean
+  no-op; do not widen it into a fleet teardown.
 - This explicitly includes the opt-in **`learnings-audit`** gardener when it is registered:
   `/setup-automations learnings-audit=true` registers it under the same prefix, so teardown removes
   it with the rest. A conditionally-skipped loop (e.g. `exploratory-bugs` on a stack without
@@ -40,6 +46,31 @@ removes them with its **native** scheduling mechanism.
   loops did. Teardown removes scheduler registrations only; it never deletes, edits, or moves a
   runbook file. An operator who wants them gone removes them deliberately, in git.
 
+## Answering a `policy-obsolete` teardown proposal
+
+Running this skill with the proposing loop id is the **approve** answer to a loop's own retirement
+proposal. When a registered loop's runbook **Retirement condition** trips, that loop records the
+`policy-obsolete` run outcome and files exactly one ticket recommending its own teardown
+(`automation-runbook-contract`) — and then keeps running at its normal cadence, because a loop never
+removes its own registration.
+Teardown is **always human-invoked**: it is never
+triggered by a loop, on any schedule, for any outcome. The operator has three answers, and only the
+first brings you here. The proposal authorizes only that loop's registration unless the human
+explicitly asks for fleet teardown.
+
+1. **Approve** — run this skill with the proposal's loop id, e.g.
+   `/lisa:tear-down-automations monitor`. When it has run, close the proposal as **Completed**: the
+   loop-scoped teardown it asked for actually happened, and Completed is the close reason that says
+   so.
+2. **Decline** — close the proposal as **Not planned** (that close reason is what stops the loop
+   re-raising it; **Completed** would leave a later re-file open). The loop simply continues at its
+   normal cadence, and nothing is removed.
+3. **Re-cadence** — you pick the longer cadence and re-register the loop with
+   `/lisa:setup-automations`; the loop never adjusts its own schedule. The proposal's evidence
+   carries the loop's **current cadence** as the baseline to choose against, plus a one-line summary
+   of its recent runs. Then close the proposal as **Completed** — the schedule change is the action
+   it asked for.
+
 ## Report
 
 List each automation removed by name. For "already absent", compare against the one source of truth

package/plugins/lisa-expo/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.257.1",
+  "version": "2.258.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/rules/eager/automation-runbook-contract.md

@@ -34,7 +34,8 @@ Health and operator action are **orthogonal** — a healthy run can still need a
   capability, then close the escalation item.
 - `policy-obsolete` — the loop's own retirement policy (the retirement condition written in its
   runbook) tripped, so it proposed its own teardown. **Healthy.** Operator action: approve the
-  teardown, decline it (close the proposal; the loop keeps running at cadence), or re-cadence it.
+  teardown, decline it (close the proposal as **Not planned**; the loop keeps running at cadence),
+  or re-cadence it.
 
 ## A run outcome is NOT a work-item lifecycle terminal state (CRITICAL)
 

package/plugins/src/base/rules/reference/automation-runbook-contract.md

@@ -84,6 +84,11 @@ Retirement condition
   cadence until someone approves, declines, or re-cadences it.
 ```
 
+That example's 30-day retirement row is **illustration of the shape, not the shipped default**: the
+seed `lisa-setup-automations` writes declares the three `intake-*` loops structural to the factory,
+whose runbooks state plainly that they do not retire. The mechanism below is normative; the numbers
+above are only a filled-in example.
+
 ## The six run outcomes
 
 Exactly one per run. The one-line operator summary is not optional — it is what the status surface
@@ -99,7 +104,7 @@ only `recovery-required` means the machinery itself is broken.
 | `change-proved` | The loop made a change and proved it with evidence. | Healthy | None — informational. | What changed and the evidence that proves it. |
 | `approval-requested` | The loop reached its autonomous/approval boundary and asked a human. | Healthy | Answer the approval question. | What is waiting, on whom, and what happens if nobody answers. |
 | `recovery-required` | The loop itself could not complete: access, tooling, or substrate is broken. | **Not healthy** — needs a human | Restore the named capability, then close the escalation item. | What broke, and the escalation item to act on. |
-| `policy-obsolete` | The loop's own retirement policy — the retirement condition written in its runbook — tripped, so it proposed its own teardown. | Healthy | Decide: approve the teardown, decline it (close the proposal; the loop continues at cadence), or re-cadence it. | Why it looks obsolete and the teardown-proposal item. |
+| `policy-obsolete` | The loop's own retirement policy — the retirement condition written in its runbook — tripped, so it proposed its own teardown. | Healthy | Decide: approve the teardown, decline it (close the proposal as **Not planned**; the loop continues at cadence), or re-cadence it. | Why it looks obsolete and the teardown-proposal item. |
 
 ### Exemplar one-line summaries
 
@@ -189,7 +194,9 @@ teardown-proposal item — matched on the marker, never the title — carrying t
 result and this run's summary as evidence, and proposing either a longer cadence or
 `lisa-tear-down-automations`. The loop **keeps running at its normal cadence** until an operator
 flips that proposal one of three ways: **approve** it (`lisa-tear-down-automations` runs and the
-registration goes away), **decline** it (close the proposal — the loop simply continues), or
+registration goes away), **decline** it (close the proposal as **Not planned** — closing it as
+**Completed** leaves a later re-file open, per `rejection-detection`'s proposal rejection memory;
+either way the loop simply continues), or
 **re-cadence** it (register it at the longer cadence instead of tearing it down). Retirement is a
 recommendation like any other, **never a self-executed exit**: a loop never deletes its own
 registration, and a proposal nobody answers changes nothing.

package/plugins/src/base/skills/lisa-exploratory-qa/SKILL.md

@@ -104,8 +104,13 @@ and records it, so a quiet run and a broken run are never mistaken for each othe
 | Findings filed — one or more `Bug` / `Improvement` tickets created or referenced (§6) | `candidate-proposed` |
 | Clean pass — explored the personas and surfaces, nothing worth filing — **or** every candidate was suppressed by a prior decline (`rejection-detection` **Proposal rejection memory**): the summary MUST name the suppression count | `nothing-needed` |
 | Tracker unconfigured — the §1 stop path; findings cannot be filed — **or** the open-and-closed rejection-memory marker search could not run (tracker unreachable / credentials revoked): a memory check that could not run is a broken loop, never a silent `nothing-needed` | `recovery-required` |
+| The runbook's **Retirement condition** tripped — the trailing quiet window is empty AND this pass found nothing to file AND the project no longer ships an exploratory-qa surface — this row supersedes the `nothing-needed` row when it applies | `policy-obsolete` |
 | A degradation that still let the pass explore (e.g. Kane unavailable, one persona unreachable) | the outcome it actually reached above, with the summary **leading with the degradation** — degradation never mints a seventh token |
 
+Before invoking the run-record CLI, evaluate the **Retirement condition** first. If it applies,
+select `policy-obsolete` as the sole outcome and do not record a prior `nothing-needed` result;
+otherwise select the ordinary outcome from the table.
+
 Record **exactly one** outcome per invocation through the run-record CLI, naming this loop's runbook
 (the `--summary` is the operator-readable one-liner in the contract's exemplar voice — plain,
 specific, actionable, e.g. `Explored 4 personas; nothing confusing to file.` — or, when a decline suppressed the only candidates, `Explored 4 personas; 2 candidates suppressed by a prior decline — nothing new to propose.` — for `nothing-needed`; and for a `recovery-required` from an unreadable decline check, `Tracker unreachable during the decline check — restore credentials; nothing was filed this run.`):
@@ -123,6 +128,42 @@ If `${CLAUDE_PLUGIN_ROOT}` is unset, resolve the plugin scripts directory direct
 abort** (per `automation-runbook-contract`): note the recording failure in the run output and finish
 the cycle — a recording failure is a degradation to report, never a reason to block the loop.
 
+**Retirement evaluation (every run).** Evaluate this loop's runbook **Retirement condition** on
+every run, exactly as the `automation-runbook-contract` rule's Retirement section defines it — this
+skill conforms to that text and never restates or diverges from it. On top of the contract's two
+conditions the runbook seeds a third **domain conjunct** — the project no longer ships an
+exploratory-qa command surface to explore — which only tightens the test and never replaces it: a
+quiet month on a product nobody broke is quality holding, not a reason to stop looking. Evaluate all
+three. When all three hold, record `policy-obsolete` and file **exactly ONE** marker-deduped
+teardown proposal through `lisa-tracker-write` (per `tracked-work` + `integration-access-layer`):
+
+- **Marker** `<!-- [lisa-automation-retire] key=exploratory-bugs -->` plus a visible prose line;
+  matched on the marker, never the title; searched **open AND closed** per `rejection-detection`'s
+  **Proposal rejection memory**. Treat matches by close state: **open** suppresses another proposal;
+  **Not planned** suppresses another proposal unless new evidence postdates the rejection;
+  **Completed** means the prior approved action happened, so a later recurrence may be re-filed.
+  When an existing proposal suppresses filing, **the run still records `policy-obsolete` and files
+  nothing** — the outcome describes this run, while the ticket is filed exactly once.
+- **Labels** `status:blocked` + `human-needed`, carrying the contract's decision-ready packet. The
+  `human-needed` label marks the proposal human-owned: `lisa-repair-intake` recognizes it and never
+  re-dispatches it as stalled work.
+- **Evidence** the date-filtered search result, this run's summary, **the loop's current cadence**
+  (the baseline an operator needs to choose a longer one), and a one-line summary of recent runs
+  read from `.lisa/automations/runs/exploratory-bugs.jsonl`. Fill the rest of the packet the same
+  way every time: *Work already attempted* is the searches this run ran, and *Risk of inaction* is
+  that the loop keeps consuming schedule slots and tokens for nothing.
+- **How to answer** names the three operator responses: **approve** — run
+  `/lisa:tear-down-automations exploratory-bugs` and only that loop registration goes away;
+  **decline** — close the proposal as
+  **Not planned** (closing it as **Completed** leaves a later re-file open) and the loop simply
+  continues; **re-cadence** — pick a longer cadence off that evidence and re-register with
+  `/lisa:setup-automations` instead of tearing down.
+- **Operator footer**, verbatim, as on every loop-filed proposal (`rejection-detection`):
+  > To stop this from being raised again, close it as **Not planned**. Close it as **Completed** if it was fixed — a later recurrence may be re-filed as a regression.
+
+The loop **keeps running at its normal cadence** until a human acts, and never deletes its own
+registration.
+
 ## Quality bar
 
 - Explore as a true first-time user — judge clarity, not whether you (who can read the code) can figure it out.

package/plugins/src/base/skills/lisa-intake/SKILL.md

@@ -131,6 +131,7 @@ matches the mode this cycle ran in: **`intake-prd`** (PRD-side dispatch) or **`i
 | A build cycle that shipped and verified (merged PR + evidence), or a shipped PRD moved to `verified` | `change-proved` |
 | A protected deployment (or other autonomy boundary the lifecycle hits) waiting on a human approval | `approval-requested` |
 | The queue itself is misconfigured or unreadable — missing required input (step 1) or an unreachable Status/workflow (step 2/`3` misconfig) so the cycle could not run | `recovery-required` |
+| The runbook's **Retirement condition** tripped | `policy-obsolete` — **never reached by design for either intake loop-id** (see Retirement evaluation below) |
 
 **Seam warning (the #1 misread in this ticket).** A run outcome describes this *cycle*; `Blocked` is
 a *work item's* lifecycle terminal state — the two never merge in the summary. When Intake correctly
@@ -156,6 +157,13 @@ If `${CLAUDE_PLUGIN_ROOT}` is unset, resolve the plugin scripts directory direct
 abort** (per `automation-runbook-contract`): note the recording failure in the run output and finish
 the cycle — a recording failure is a degradation to report, never a reason to block the loop.
 
+**Retirement evaluation (every run).** Both loop-ids this skill backs are **structural to the
+factory — they do not retire.** Their runbooks say so plainly instead of leaving the Retirement
+condition blank, so the `automation-runbook-contract` rule's two-part retirement test never fires
+here: neither `intake-prd` nor `intake-tickets` ever records `policy-obsolete`, and neither ever
+files a teardown proposal. An operator who wants intake to stop runs `/lisa:tear-down-automations`
+themselves — the loop never removes its own registration.
+
 ## Schedule examples
 
 ```text