@codyswann/lisa 2.252.0 → 2.253.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (85) hide show
  1. package/package.json +1 -1
  2. package/plugins/lisa/.claude-plugin/plugin.json +1 -1
  3. package/plugins/lisa/.codex-plugin/plugin.json +1 -1
  4. package/plugins/lisa/.codex-plugin/skills/lisa-automation-status/SKILL.md +14 -8
  5. package/plugins/lisa/.codex-plugin/skills/lisa-setup-automations/SKILL.md +116 -1
  6. package/plugins/lisa/.codex-plugin/skills/lisa-tear-down-automations/SKILL.md +25 -5
  7. package/plugins/lisa/scripts/automation-status-claude-adapter.mjs +36 -18
  8. package/plugins/lisa/scripts/automation-status-codex-adapter.mjs +50 -27
  9. package/plugins/lisa/scripts/automation-status-expected-fleet.mjs +149 -6
  10. package/plugins/lisa/skills/lisa-automation-status/SKILL.md +14 -8
  11. package/plugins/lisa/skills/lisa-setup-automations/SKILL.md +116 -1
  12. package/plugins/lisa/skills/lisa-tear-down-automations/SKILL.md +26 -6
  13. package/plugins/lisa/skills/lisa-tear-down-automations/agents/openai.yaml +2 -2
  14. package/plugins/lisa-agy/plugin.json +1 -1
  15. package/plugins/lisa-agy/scripts/automation-status-claude-adapter.mjs +36 -18
  16. package/plugins/lisa-agy/scripts/automation-status-codex-adapter.mjs +50 -27
  17. package/plugins/lisa-agy/scripts/automation-status-expected-fleet.mjs +149 -6
  18. package/plugins/lisa-agy/skills/lisa-automation-status/SKILL.md +14 -8
  19. package/plugins/lisa-agy/skills/lisa-setup-automations/SKILL.md +116 -1
  20. package/plugins/lisa-agy/skills/lisa-tear-down-automations/SKILL.md +26 -6
  21. package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
  22. package/plugins/lisa-cdk/.codex-plugin/plugin.json +1 -1
  23. package/plugins/lisa-cdk-agy/plugin.json +1 -1
  24. package/plugins/lisa-cdk-copilot/.claude-plugin/plugin.json +1 -1
  25. package/plugins/lisa-cdk-cursor/.claude-plugin/plugin.json +1 -1
  26. package/plugins/lisa-copilot/.claude-plugin/plugin.json +1 -1
  27. package/plugins/lisa-copilot/scripts/automation-status-claude-adapter.mjs +36 -18
  28. package/plugins/lisa-copilot/scripts/automation-status-codex-adapter.mjs +50 -27
  29. package/plugins/lisa-copilot/scripts/automation-status-expected-fleet.mjs +149 -6
  30. package/plugins/lisa-copilot/skills/lisa-automation-status/SKILL.md +14 -8
  31. package/plugins/lisa-copilot/skills/lisa-setup-automations/SKILL.md +116 -1
  32. package/plugins/lisa-copilot/skills/lisa-tear-down-automations/SKILL.md +26 -6
  33. package/plugins/lisa-cursor/.claude-plugin/plugin.json +1 -1
  34. package/plugins/lisa-cursor/scripts/automation-status-claude-adapter.mjs +36 -18
  35. package/plugins/lisa-cursor/scripts/automation-status-codex-adapter.mjs +50 -27
  36. package/plugins/lisa-cursor/scripts/automation-status-expected-fleet.mjs +149 -6
  37. package/plugins/lisa-cursor/skills/lisa-automation-status/SKILL.md +14 -8
  38. package/plugins/lisa-cursor/skills/lisa-setup-automations/SKILL.md +116 -1
  39. package/plugins/lisa-cursor/skills/lisa-tear-down-automations/SKILL.md +26 -6
  40. package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
  41. package/plugins/lisa-expo/.codex-plugin/plugin.json +1 -1
  42. package/plugins/lisa-expo-agy/plugin.json +1 -1
  43. package/plugins/lisa-expo-copilot/.claude-plugin/plugin.json +1 -1
  44. package/plugins/lisa-expo-cursor/.claude-plugin/plugin.json +1 -1
  45. package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json +1 -1
  46. package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json +1 -1
  47. package/plugins/lisa-harper-fabric-agy/plugin.json +1 -1
  48. package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json +1 -1
  49. package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json +1 -1
  50. package/plugins/lisa-nestjs/.claude-plugin/plugin.json +1 -1
  51. package/plugins/lisa-nestjs/.codex-plugin/plugin.json +1 -1
  52. package/plugins/lisa-nestjs-agy/plugin.json +1 -1
  53. package/plugins/lisa-nestjs-copilot/.claude-plugin/plugin.json +1 -1
  54. package/plugins/lisa-nestjs-cursor/.claude-plugin/plugin.json +1 -1
  55. package/plugins/lisa-openclaw/.claude-plugin/plugin.json +1 -1
  56. package/plugins/lisa-openclaw/.codex-plugin/plugin.json +1 -1
  57. package/plugins/lisa-openclaw-agy/plugin.json +1 -1
  58. package/plugins/lisa-openclaw-copilot/.claude-plugin/plugin.json +1 -1
  59. package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json +1 -1
  60. package/plugins/lisa-phaser/.claude-plugin/plugin.json +1 -1
  61. package/plugins/lisa-phaser/.codex-plugin/plugin.json +1 -1
  62. package/plugins/lisa-phaser-agy/plugin.json +1 -1
  63. package/plugins/lisa-phaser-copilot/.claude-plugin/plugin.json +1 -1
  64. package/plugins/lisa-phaser-cursor/.claude-plugin/plugin.json +1 -1
  65. package/plugins/lisa-rails/.claude-plugin/plugin.json +1 -1
  66. package/plugins/lisa-rails/.codex-plugin/plugin.json +1 -1
  67. package/plugins/lisa-rails-agy/plugin.json +1 -1
  68. package/plugins/lisa-rails-copilot/.claude-plugin/plugin.json +1 -1
  69. package/plugins/lisa-rails-cursor/.claude-plugin/plugin.json +1 -1
  70. package/plugins/lisa-typescript/.claude-plugin/plugin.json +1 -1
  71. package/plugins/lisa-typescript/.codex-plugin/plugin.json +1 -1
  72. package/plugins/lisa-typescript-agy/plugin.json +1 -1
  73. package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json +1 -1
  74. package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json +1 -1
  75. package/plugins/lisa-wiki/.claude-plugin/plugin.json +1 -1
  76. package/plugins/lisa-wiki/.codex-plugin/plugin.json +1 -1
  77. package/plugins/lisa-wiki-agy/plugin.json +1 -1
  78. package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json +1 -1
  79. package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json +1 -1
  80. package/plugins/src/base/scripts/automation-status-claude-adapter.mjs +36 -18
  81. package/plugins/src/base/scripts/automation-status-codex-adapter.mjs +50 -27
  82. package/plugins/src/base/scripts/automation-status-expected-fleet.mjs +149 -6
  83. package/plugins/src/base/skills/lisa-automation-status/SKILL.md +14 -8
  84. package/plugins/src/base/skills/lisa-setup-automations/SKILL.md +116 -1
  85. package/plugins/src/base/skills/lisa-tear-down-automations/SKILL.md +26 -6
@@ -37,10 +37,86 @@ export const AUTOMATION_EXPECTED_CADENCES = {
37
37
  human: "once a day",
38
38
  rrule: "FREQ=DAILY;INTERVAL=1",
39
39
  },
40
+ monitor: {
41
+ human: "once a day",
42
+ rrule: "FREQ=DAILY;INTERVAL=1",
43
+ },
44
+ "learnings-audit": {
45
+ human: "once a week",
46
+ rrule: "FREQ=WEEKLY;INTERVAL=1",
47
+ },
40
48
  };
41
49
 
42
50
  export const EXPLORATORY_QA_STACK_PRIORITY = ["expo", "rails", "harper-fabric"];
43
51
 
52
+ /**
53
+ * Directory (repo-relative) holding the checked-in per-loop runbooks scaffolded
54
+ * by `/lisa:setup-automations` per the `automation-runbook-contract` rule.
55
+ */
56
+ export const AUTOMATION_RUNBOOK_DIRECTORY = ".lisa/automations";
57
+
58
+ /**
59
+ * Every fleet group, in render order, with the operator-facing title each one
60
+ * carries in the status report. This is the single source of truth for group
61
+ * membership: adapters bin entries with {@link createAutomationGroupBins} and
62
+ * render with {@link renderAutomationGroups}, so adding a group here surfaces it
63
+ * everywhere instead of silently dropping its entries.
64
+ */
65
+ export const AUTOMATION_FLEET_GROUP_TITLES = {
66
+ core: "Core automations",
67
+ exploratory: "Exploratory automations",
68
+ "opt-in": "Opt-in automations",
69
+ };
70
+
71
+ /**
72
+ * Create one empty bin per known fleet group.
73
+ *
74
+ * @returns {Map<string, object[]>}
75
+ */
76
+ export function createAutomationGroupBins() {
77
+ return new Map(
78
+ Object.keys(AUTOMATION_FLEET_GROUP_TITLES).map(group => [group, []])
79
+ );
80
+ }
81
+
82
+ /**
83
+ * Add a rendered status item to its group bin.
84
+ *
85
+ * Throws on an unknown group rather than dropping the item: a silently skipped
86
+ * entry is indistinguishable from a healthy fleet, which is exactly how the
87
+ * opt-in gardener went missing from both runtime adapters.
88
+ *
89
+ * @param {Map<string, object[]>} bins
90
+ * @param {string} group
91
+ * @param {object} item
92
+ * @returns {void}
93
+ */
94
+ export function assignToAutomationGroup(bins, group, item) {
95
+ const bin = bins.get(group);
96
+ if (!bin) {
97
+ throw new Error(
98
+ `Unknown automation fleet group "${group}" for ${item?.id ?? "an automation"}. Add it to AUTOMATION_FLEET_GROUP_TITLES so the status report can render it.`
99
+ );
100
+ }
101
+ bin.push(item);
102
+ }
103
+
104
+ /**
105
+ * Render the group bins as the numbered report groups, in declaration order.
106
+ *
107
+ * @param {Map<string, object[]>} bins
108
+ * @returns {readonly { readonly id: string, readonly title: string, readonly items: readonly object[] }[]}
109
+ */
110
+ export function renderAutomationGroups(bins) {
111
+ return Object.entries(AUTOMATION_FLEET_GROUP_TITLES).map(
112
+ ([group, title], index) => ({
113
+ id: String(index + 1),
114
+ title,
115
+ items: bins.get(group) ?? [],
116
+ })
117
+ );
118
+ }
119
+
44
120
  /**
45
121
  * @typedef {{
46
122
  * readonly id: string
@@ -48,19 +124,52 @@ export const EXPLORATORY_QA_STACK_PRIORITY = ["expo", "rails", "harper-fabric"];
48
124
  * readonly expectedCadence: string
49
125
  * readonly expectedRRule: string
50
126
  * readonly expectedCommand: string
51
- * readonly group: "core" | "exploratory"
127
+ * readonly group: "core" | "exploratory" | "opt-in"
128
+ * readonly runbookPath: string
52
129
  * }} ExpectedAutomationEntry
53
130
  *
54
131
  * @typedef {{
55
132
  * readonly id: string
56
133
  * readonly automationId: string
57
- * readonly group: "core" | "exploratory"
134
+ * readonly group: "core" | "exploratory" | "opt-in"
58
135
  * readonly reason: string
59
136
  * readonly expectedCadence: string
60
137
  * readonly expectedRRule: string
138
+ * readonly runbookPath: string
61
139
  * }} UnsupportedAutomationEntry
62
140
  */
63
141
 
142
+ /**
143
+ * Infer whether this project opted into the weekly gardener, from what is
144
+ * actually registered on the scheduler.
145
+ *
146
+ * Membership is registration, not configuration: there is no config key to
147
+ * read, so a read-only caller decides by looking for the registration itself.
148
+ * Pass the result as `learningsAudit` to {@link resolveExpectedAutomationFleet}
149
+ * so an opted-in project compares its gardener like any other loop instead of
150
+ * reporting it `UNSUPPORTED` forever.
151
+ *
152
+ * @param {{
153
+ * readonly automationPrefix: string
154
+ * readonly observedAutomationIds?: readonly string[]
155
+ * }} input
156
+ * @returns {boolean}
157
+ */
158
+ export function inferLearningsAuditRegistration(input) {
159
+ const target = `${input.automationPrefix}learnings-audit`;
160
+ return (input.observedAutomationIds ?? []).includes(target);
161
+ }
162
+
163
+ /**
164
+ * Resolve the repo-relative runbook path for a loop id.
165
+ *
166
+ * @param {string} id
167
+ * @returns {string}
168
+ */
169
+ export function resolveAutomationRunbookPath(id) {
170
+ return `${AUTOMATION_RUNBOOK_DIRECTORY}/${id}.runbook.md`;
171
+ }
172
+
64
173
  /**
65
174
  * Resolve the stable project identifier and automation prefix used by
66
175
  * `/lisa:setup-automations`.
@@ -101,7 +210,15 @@ export function resolveAutomationProjectIdentity(input = {}) {
101
210
  * readonly detectedTypes?: readonly string[]
102
211
  * readonly autoStartPrds?: boolean | string
103
212
  * readonly autoStartTickets?: boolean | string
213
+ * readonly learningsAudit?: boolean | string
104
214
  * }} input
215
+ *
216
+ * `learningsAudit` has no config home by design — the gardener is opted into at
217
+ * registration time, and membership is registration, not configuration. A
218
+ * read-only caller (the status surface) therefore INFERS it: pass `true` when a
219
+ * `<automationPrefix>learnings-audit` entry is observed on the runtime
220
+ * scheduler. Without that inference an opted-in project would report the
221
+ * gardener `UNSUPPORTED` forever instead of comparing it like any other loop.
105
222
  * @returns {{
106
223
  * readonly owner: string
107
224
  * readonly repo: string
@@ -116,6 +233,7 @@ export function resolveExpectedAutomationFleet(input = {}) {
116
233
  const identity = resolveAutomationProjectIdentity(input);
117
234
  const autoStartPrds = normalizeBooleanFlag(input.autoStartPrds);
118
235
  const autoStartTickets = normalizeBooleanFlag(input.autoStartTickets);
236
+ const learningsAudit = normalizeBooleanFlag(input.learningsAudit);
119
237
  const detectedTypes = input.detectedTypes ?? [];
120
238
 
121
239
  const tracker = config.tracker;
@@ -166,6 +284,7 @@ export function resolveExpectedAutomationFleet(input = {}) {
166
284
  `/lisa:intake ${buildQueue}`,
167
285
  "core"
168
286
  ),
287
+ createExpectedEntry(identity, "monitor", "/lisa:monitor", "core"),
169
288
  createExpectedEntry(
170
289
  identity,
171
290
  "exploratory-prds",
@@ -191,7 +310,28 @@ export function resolveExpectedAutomationFleet(input = {}) {
191
310
  createUnsupportedEntry(
192
311
  identity,
193
312
  "exploratory-bugs",
194
- "This repository does not ship an exploratory-qa command surface."
313
+ "This project ships no exploratory-qa command, so there is nothing for this loop to run. No action needed unless the project adds one.",
314
+ "exploratory"
315
+ )
316
+ );
317
+ }
318
+
319
+ if (learningsAudit) {
320
+ expected.push(
321
+ createExpectedEntry(
322
+ identity,
323
+ "learnings-audit",
324
+ "/lisa:learnings:audit",
325
+ "opt-in"
326
+ )
327
+ );
328
+ } else {
329
+ unsupported.push(
330
+ createUnsupportedEntry(
331
+ identity,
332
+ "learnings-audit",
333
+ "The weekly gardener loop is opt-in and this project has not opted in, so nobody is auditing its knowledge surfaces. Run /lisa:setup-automations learnings-audit=true to enable it.",
334
+ "opt-in"
195
335
  )
196
336
  );
197
337
  }
@@ -222,7 +362,7 @@ export function resolveExploratoryQaStack(detectedTypes = []) {
222
362
  * @param {{ readonly automationPrefix: string }} identity
223
363
  * @param {string} id
224
364
  * @param {string} expectedCommand
225
- * @param {"core" | "exploratory"} group
365
+ * @param {"core" | "exploratory" | "opt-in"} group
226
366
  * @returns {ExpectedAutomationEntry}
227
367
  */
228
368
  function createExpectedEntry(identity, id, expectedCommand, group) {
@@ -234,6 +374,7 @@ function createExpectedEntry(identity, id, expectedCommand, group) {
234
374
  expectedRRule: cadence.rrule,
235
375
  expectedCommand,
236
376
  group,
377
+ runbookPath: resolveAutomationRunbookPath(id),
237
378
  };
238
379
  }
239
380
 
@@ -241,17 +382,19 @@ function createExpectedEntry(identity, id, expectedCommand, group) {
241
382
  * @param {{ readonly automationPrefix: string }} identity
242
383
  * @param {string} id
243
384
  * @param {string} reason
385
+ * @param {"core" | "exploratory" | "opt-in"} group
244
386
  * @returns {UnsupportedAutomationEntry}
245
387
  */
246
- function createUnsupportedEntry(identity, id, reason) {
388
+ function createUnsupportedEntry(identity, id, reason, group) {
247
389
  const cadence = AUTOMATION_EXPECTED_CADENCES[id];
248
390
  return {
249
391
  id,
250
392
  automationId: `${identity.automationPrefix}${id}`,
251
393
  expectedCadence: cadence.human,
252
394
  expectedRRule: cadence.rrule,
253
- group: "exploratory",
395
+ group,
254
396
  reason,
397
+ runbookPath: resolveAutomationRunbookPath(id),
255
398
  };
256
399
  }
257
400
 
@@ -16,14 +16,20 @@ Do **not** ask for confirmation once invoked. This skill inspects scheduler stat
16
16
 
17
17
  ## Scope
18
18
 
19
- Inspect only the Lisa automation fleet for the current project:
20
-
21
- - `intake-repair`
22
- - `intake-prd`
23
- - `intake-tickets`
24
- - `exploratory-bugs` when the current stack supports `exploratory-qa`
25
- - `exploratory-prds`
26
- - `monitor`
19
+ Inspect only the Lisa automation fleet for the current project. Derive that fleet from
20
+ `scripts/automation-status-expected-fleet.mjs` (`resolveExpectedAutomationFleet`), which resolves
21
+ exactly what `setup-automations` registers for this repo — including the stack-guarded
22
+ `exploratory-bugs` and the opt-in `learnings-audit` gardener. **Membership is registration, not a
23
+ roster** (`automation-runbook-contract`): carry no fixed list of loop names here, so a loop added to
24
+ or removed from the registration set flows through without editing this skill.
25
+
26
+ The gardener is opted into at registration time and has no config key, so **infer it from the
27
+ scheduler**: list the project's automations first, then call
28
+ `inferLearningsAuditRegistration({ automationPrefix, observedAutomationIds })` and pass the result
29
+ as `learningsAudit` when resolving the fleet. A `lisa-auto-<project>-learnings-audit` entry on the
30
+ scheduler means the project opted in, so the gardener is compared like any other loop; no such entry
31
+ means it is reported `UNSUPPORTED` (opted out), never `MISSING`. This skill stays read-only — it
32
+ infers, it never writes the flag anywhere.
27
33
 
28
34
  Resolve the expected project identifier, fleet naming prefix, queue arguments, cadence, and stack-support rules from the same contract used by `setup-automations` and `tear-down-automations`. Do **not** invent a second source of truth for fleet naming or queue resolution.
29
35
 
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  name: lisa-setup-automations
3
3
  description: "Set up the recurring Lisa automations on the local workstation using the CURRENT runtime's native scheduler — Codex automations (the native automations / automation_update mechanism) or, on Claude, /schedule. This skill is a declarative specification: it states WHICH automations to create, how often, and with which parameters; it does not template schedule files or run scheduling code itself — the runtime's native automation mechanism does the creating. Creates six default automations: intake-repair (every 60 min), intake PRD (every 60 min), intake tickets (every 10 min), exploratory-bugs (once a day), exploratory-prds (once a day), monitor (once a day) — plus opt-in learnings-audit (once a week, the gardener). Three flags: auto-start-prds and auto-start-tickets control whether ideated PRDs / filed bug tickets are created auto-pickup-ready (prd_ready / ready, default true) or left for human review; learnings-audit (default false) opts into the weekly gardener loop. Tear down with /tear-down-automations."
4
- allowed-tools: ["Skill", "Bash", "Read"]
4
+ allowed-tools: ["Skill", "Bash", "Read", "Write", "Edit"]
5
5
  ---
6
6
 
7
7
  # Set up Lisa automations: $ARGUMENTS
@@ -105,6 +105,19 @@ the scheduled commands (for example `/lisa:intake acme/frontend intake_mode=prd`
105
105
  config/read-context failure cannot silently redirect the cron. A short queueRepo is normalized to
106
106
  `github.org` before writing the automation.
107
107
 
108
+ **Registration prompt shape (so status can read the command back).** Whatever prose the prompt
109
+ carries, it must contain the **literal Lisa command on a line of its own**, exactly as scheduled and
110
+ with every `owner/repo` already baked in:
111
+
112
+ ```text
113
+ /lisa:intake acme/planning intake_mode=build
114
+ ```
115
+
116
+ This holds for loops that take **no arguments** too — `/lisa:monitor` and `/lisa:learnings:audit`
117
+ are written the same way, on their own line, with nothing after them. `/lisa:automation-status`
118
+ reads that line back to compare the live registration against this contract; a loop whose command
119
+ cannot be read back reports as drifted even though it is registered correctly.
120
+
108
121
  **Naming + scope (so teardown is precise).** Name each automation with the stable prefix
109
122
  `lisa-auto-<project>-` (e.g. `lisa-auto-<project>-intake-tickets`), where `<project>` identifies this
110
123
  repo, and scope each Codex automation to the durable project automation checkout described above.
@@ -115,6 +128,91 @@ repos (don't rely on a bare repo basename when it could collide; qualify it, e.g
115
128
  **Idempotent.** Re-running this skill updates the existing `lisa-auto-<project>-*` automations in
116
129
  place (same names) rather than creating duplicates.
117
130
 
131
+ ## Runbook scaffolding
132
+
133
+ Registration is what pulls a loop under the `automation-runbook-contract` rule, so registration is
134
+ what must produce its runbook. For **every automation actually registered above** — including the
135
+ conditionally-guarded `exploratory-bugs` and the opt-in `learnings-audit` — write a checked-in
136
+ runbook at:
137
+
138
+ ```text
139
+ .lisa/automations/<loop-id>.runbook.md
140
+ ```
141
+
142
+ `<loop-id>` is the automation's suffix, not its full name: `intake-tickets`, not
143
+ `lisa-auto-<project>-intake-tickets`. These files are **project knowledge and belong in git**, like
144
+ `.lisa/PROJECT_LEARNINGS.md` — commit them; they are not scratch output. Derive the set of runbooks
145
+ from what was registered on this run: a loop that was **skipped gets no runbook**, and a loop
146
+ registered later gets one when this skill next runs. Never write a runbook from a fixed list of
147
+ loop names.
148
+
149
+ Follow the `automation-runbook-contract` rule for the runbook's shape: its ten sections, in its
150
+ order, in its prose register. **Do not restate the template, the run outcomes, or the escalation
151
+ packet here** — cite the rule and instantiate it.
152
+
153
+ **File shape — two halves with different owners.**
154
+
155
+ 1. A **machine-resolved header block**, delimited exactly by
156
+ `<!-- lisa:machine-resolved:start -->` and `<!-- lisa:machine-resolved:end -->`, written first
157
+ in the file. Lisa owns it: on every run it is **rewritten wholesale** from the values resolved
158
+ above. It carries the project identity (`<owner>/<repo>` and the `<project>` token), the loop
159
+ id, the full automation name, the exact scheduled command with every `owner/repo` already baked
160
+ in (never a placeholder), the human cadence and its `rrule`, the resolved queue arguments, and
161
+ the resolved flag values that shaped the command (`auto-start-prds` / `auto-start-tickets` /
162
+ `learnings-audit`). Its **first line inside the delimiters is a visible sentence**, so the
163
+ ownership boundary survives rendering to markdown where HTML comments disappear:
164
+
165
+ ```text
166
+ Lisa rewrites this section on every /lisa:setup-automations run — edits here are lost. Your prose
167
+ belongs in the sections below.
168
+ ```
169
+
170
+ Immediately **below** the closing delimiter, write one more visible line — `Everything below is
171
+ yours.` — so an operator reading the rendered page knows where their half starts.
172
+ 2. The **ten contract sections** below it. Lisa owns them **only on first write**, then they belong
173
+ to the operator. Seed them deterministically, never improvised:
174
+ - **Intent, Sources of truth, Candidate selection, Scope/bounds, Retirement condition** come
175
+ from the per-loop seed table below.
176
+ - **Proof, Autonomous-vs-approval boundary, Escalation, Recovery, Next-run state** are derived
177
+ from **that loop's own SKILL.md** — named per loop in the table's last column — so the runbook
178
+ describes what the loop actually does rather than a generic paraphrase. Quote its behavior in
179
+ the operator's voice; if the skill file is unreadable, write one sentence saying the section
180
+ was not derivable and which file to read, and continue.
181
+
182
+ Every seeded sentence is written for a non-technical operator (`factory-model` rule 5).
183
+
184
+ ### Per-loop seed defaults
185
+
186
+ One line each; expand them into the operator's voice, keep the meaning.
187
+
188
+ | Loop | Intent | Sources of truth | Candidate selection | Scope/bounds | Retirement condition | Derive the other five from |
189
+ |---|---|---|---|---|---|---|
190
+ | **intake-repair** | Keeps the queues unstuck: work that stalled mid-flight gets diagnosed and moved again. | The PRD and build queues for this project, read through the tracker access layer. | Stuck or half-closed items — stalled in an in-progress role, terminal-labeled but still open, rollups whose children are all done — up to the `max_candidates` cap. | Only this project's configured queues; it repairs lifecycle state, never invents or closes real work. | Propose teardown when nothing has needed repair for a long quiet window AND this run found nothing. | `lisa-repair-intake/SKILL.md` |
191
+ | **intake-prd** | Keeps PRDs moving: a PRD a human marked ready gets validated and decomposed into work items. | The configured PRD queue and its lifecycle roles, read through the source access layer. | The oldest PRD in the ready role, one per run. | Only this project's PRD queue; it never authors product intent, only validates and decomposes it. | Propose teardown when no PRD has entered the queue for a long quiet window AND this run proposed nothing. | `lisa-intake/SKILL.md` |
192
+ | **intake-tickets** | Keeps the build queue moving: work items a human marked ready get built, reviewed, and shipped. | The configured tracker's build queue lanes plus each item's comments and linked PRs. | The oldest eligible leaf work item in the ready lane, one per run. | Only this repo's configured queue; containers with open children are repaired out, never built. | Propose teardown when no work item has entered this queue for a long quiet window AND this run proposed nothing. | `lisa-intake/SKILL.md` |
193
+ | **monitor** | Keeps production honest: observability regressions become tracked work instead of silent decay. | The connected observability providers, each through its access layer, plus this project's `monitor.gapTiers` config. | The regressions and coverage gaps this cycle surfaced, capped per run. | Only this project's own services and dashboards; it files findings, it never changes production. | Propose teardown when the project has no connected observability surfaces AND this run found nothing. | `lisa-monitor/SKILL.md` |
194
+ | **exploratory-prds** | Keeps the idea pipeline fed: the product's own gaps become PRDs when the PRD queue has room. | The PRD queue's pressure roles (the same ones `/lisa:queue-status` reports) and the project's own product surfaces. | One ideated PRD per run, and only when the pressure gate says the queue has capacity. | Never more than one PRD per run, and nothing at all while unresolved PRD pressure exists. | Propose teardown when the queue has been at pressure — or the project has shipped no new surface — across a long quiet window AND this run proposed nothing. | `lisa-project-ideation/SKILL.md` |
195
+ | **exploratory-bugs** | Keeps quality visible: bugs and usability problems get found by using the product, before a customer does. | The running application through its exploratory-qa surface, plus this project's existing bug queue for dedupe. | The findings of one exploratory session, capped per run and deduped against already-filed items. | Only this project's own app; it files tickets, it never changes product code. | Propose teardown when no session has produced a finding across a long quiet window AND this run found nothing. | `lisa-exploratory-qa/SKILL.md` (the stack's own copy) |
196
+ | **learnings-audit** | Keeps the project's knowledge true: stale, duplicated, or contradicted knowledge gets proposed for promotion, demotion, or retirement. | The learnings ledger, the rules trees, the skills, and the wiki — the project's knowledge surfaces. | The knowledge entries this audit judged stale, duplicated, or contradicted, capped per run. | It only proposes; every promote/demote/retire decision is a human-gated tracker ticket. | Propose teardown when the audit has proposed nothing across a long quiet window AND this run proposed nothing. | `lisa-learnings-audit/SKILL.md` |
197
+
198
+ A loop not in this table — one registered later — seeds all ten sections from its own SKILL.md the
199
+ same way. The table is seed prose for first write only; it is **not** a roster and never decides
200
+ which automations exist.
201
+
202
+ **Re-run rule (idempotent, never clobber).** When the file already exists: rewrite the
203
+ machine-resolved block in place and **leave every one of the ten sections exactly as found** — an
204
+ operator's edited Intent paragraph survives verbatim. If a contract section is **missing** from an
205
+ existing file, insert it **at its position in the contract's ten-section order** (never merely
206
+ appended at the end, which would leave the file permanently out of order) with its seeded default.
207
+ Never overwrite, reorder, reword, or delete prose already on disk. If the machine-resolved
208
+ delimiters are absent (a hand-written file), insert the block at the top and touch nothing else.
209
+
210
+ **Never a precondition.** A runbook that cannot be written is a **degradation, not a blocker**:
211
+ report the failure and continue registering automations. A loop with a missing runbook still runs —
212
+ on the contract's defaults, saying so in its one-line summary — per the contract's
213
+ never-block-always-degrade rule. Scaffolding failure never aborts setup and never leaves an
214
+ automation unregistered.
215
+
118
216
  ## Conditions / guards
119
217
 
120
218
  - **exploratory-bugs** is created only when the project ships an `exploratory-qa` command (the
@@ -134,3 +232,20 @@ place (same names) rather than creating duplicates.
134
232
 
135
233
  List each automation created or updated (name, the command it runs, cadence, and the resolved
136
234
  `auto-start-prds` / `auto-start-tickets` values), plus any automation skipped and why.
235
+
236
+ Then list each runbook written, by path (`.lisa/automations/<loop-id>.runbook.md`), saying for each
237
+ whether it was **created** (seeded fresh) or **refreshed** (machine-resolved block rewritten,
238
+ operator prose left untouched). Name every skipped loop again here and state plainly that it has no
239
+ runbook because it was not registered, and why — for example, "exploratory-bugs was skipped because
240
+ this project ships no exploratory-qa command, so no runbook was written for it."
241
+
242
+ Close with the two lines that tell the operator what to do next:
243
+
244
+ - When any runbook was newly created: "N new files were written under `.lisa/automations/` — commit
245
+ them so the whole team sees them."
246
+ - When a runbook could not be written: name which one and what failed, then the consequence and the
247
+ fix — "that loop runs on defaults and its summaries will lead with 'Runbook missing' — re-run
248
+ `/lisa:setup-automations` to fix." The automation itself is still registered and still runs.
249
+
250
+ Every line states the consequence and the action, in words a non-technical operator can act on
251
+ without reading code.
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: lisa-tear-down-automations
3
- description: "Remove every recurring Lisa automation that /setup-automations created for this project (the lisa-auto-<project>-* set: intake-repair, intake-prd, intake-tickets, exploratory-bugs, exploratory-prds, monitor) 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. Removes only this project's Lisa automations — never other projects' automations or non-Lisa ones. The inverse of /setup-automations."
3
+ 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."
4
4
  allowed-tools: ["Skill", "Bash", "Read"]
5
5
  ---
6
6
 
@@ -21,14 +21,34 @@ removes them with its **native** scheduling mechanism.
21
21
 
22
22
  ## Scope (remove only what setup created)
23
23
 
24
- - Remove the six automations `/setup-automations` creates for the current project, matched by the
25
- stable `lisa-auto-<project>-` name prefix: `intake-repair`, `intake-prd`, `intake-tickets`,
26
- `exploratory-bugs`, `exploratory-prds`, `monitor`.
24
+ - Remove **every** automation `/setup-automations` registered for the current project the whole
25
+ set found under the stable `lisa-auto-<project>-` name prefix, whatever it currently contains.
26
+ **Membership is registration, not a roster** (`automation-runbook-contract`): sweep the prefix and
27
+ remove what is there. Do **not** work from a fixed list of loop names — a list drifts the moment a
28
+ loop is added, which is exactly how the opt-in gardener came to be orphaned.
29
+ - This explicitly includes the opt-in **`learnings-audit`** gardener when it is registered:
30
+ `/setup-automations learnings-audit=true` registers it under the same prefix, so teardown removes
31
+ it with the rest. A conditionally-skipped loop (e.g. `exploratory-bugs` on a stack without
32
+ `exploratory-qa`) simply is not in the sweep.
27
33
  - **Never** remove automations for a different project, or any non-Lisa automation (e.g. unrelated
28
34
  crawlers/ingestors). Match strictly on the `lisa-auto-<project>-` prefix for THIS project; when in
29
35
  doubt about an automation's ownership, leave it and report it rather than deleting it.
30
- - **Idempotent** — an automation that is already absent is a no-op, not an error.
36
+ - **Idempotent** — an automation that is already absent is a no-op, not an error. Re-running when
37
+ the prefix sweep finds nothing is a clean, successful no-op.
38
+ - **Leave the runbooks alone.** The checked-in `.lisa/automations/<loop-id>.runbook.md` files that
39
+ `/setup-automations` scaffolded are project knowledge and the historical record of what these
40
+ loops did. Teardown removes scheduler registrations only; it never deletes, edits, or moves a
41
+ runbook file. An operator who wants them gone removes them deliberately, in git.
31
42
 
32
43
  ## Report
33
44
 
34
- List each automation removed, and any in the expected set that were already absent.
45
+ List each automation removed by name. For "already absent", compare against the one source of truth
46
+ — the fleet `scripts/automation-status-expected-fleet.mjs` (`resolveExpectedAutomationFleet`)
47
+ resolves for this project — and name anything it expects that the sweep did not find; that is a
48
+ no-op, not an error. Do not invent an expected set of your own.
49
+
50
+ Then state, in the operator's words, that the runbook files under `.lisa/automations/` were left on
51
+ disk **and why**: they are the written record of what those jobs did, kept on purpose, and if you
52
+ do not want them you delete them yourself in git. Finally, confirm that nothing outside this
53
+ project's `lisa-auto-<project>-` prefix was touched. Write it so a non-technical operator can
54
+ confirm what happened without reading code.
@@ -1,4 +1,4 @@
1
1
  display_name: "Tear Down Automations"
2
- short_description: "Remove every recurring Lisa automation that /setup-automations created for this project (the lisa-auto-<project>-* set: intake-repair…"
2
+ short_description: "Remove every recurring Lisa automation that /setup-automations registered for this project whatever is actually registered under the…"
3
3
  default_prompt:
4
- - "Use $lisa-tear-down-automations: Remove every recurring Lisa automation that /setup-automations created for this project (the lisa-auto-<project>-* set: intake-repair…."
4
+ - "Use $lisa-tear-down-automations: Remove every recurring Lisa automation that /setup-automations registered for this project whatever is actually registered under the…."
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa",
3
- "version": "2.252.0",
3
+ "version": "2.253.0",
4
4
  "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -10,6 +10,11 @@
10
10
  */
11
11
 
12
12
  import { compareAutomationFleet } from "./automation-status-contract-drift.mjs";
13
+ import {
14
+ assignToAutomationGroup,
15
+ createAutomationGroupBins,
16
+ renderAutomationGroups,
17
+ } from "./automation-status-expected-fleet.mjs";
13
18
 
14
19
  const CLAUDE_RUNTIME_LABEL = "Claude /schedule";
15
20
  const CLAUDE_ACTIVE_STATUSES = new Set([
@@ -75,10 +80,7 @@ export function inspectClaudeAutomationFleet(input) {
75
80
  automationPrefix: expectedFleet.automationPrefix,
76
81
  });
77
82
 
78
- const expectedGroups = new Map([
79
- ["core", []],
80
- ["exploratory", []],
81
- ]);
83
+ const expectedGroups = createAutomationGroupBins();
82
84
 
83
85
  const comparisons = compareAutomationFleet({
84
86
  expectedAutomations: expectedFleet.expected,
@@ -87,7 +89,9 @@ export function inspectClaudeAutomationFleet(input) {
87
89
 
88
90
  for (const [index, expected] of expectedFleet.expected.entries()) {
89
91
  const comparison = comparisons[index];
90
- expectedGroups.get(expected.group)?.push(
92
+ assignToAutomationGroup(
93
+ expectedGroups,
94
+ expected.group,
91
95
  createObservedStatusItem({
92
96
  expected,
93
97
  comparison,
@@ -97,7 +101,7 @@ export function inspectClaudeAutomationFleet(input) {
97
101
  }
98
102
 
99
103
  for (const unsupported of expectedFleet.unsupported) {
100
- expectedGroups.get(unsupported.group)?.push({
104
+ assignToAutomationGroup(expectedGroups, unsupported.group, {
101
105
  id: unsupported.automationId,
102
106
  status: "UNSUPPORTED",
103
107
  summary: unsupported.reason,
@@ -109,18 +113,7 @@ export function inspectClaudeAutomationFleet(input) {
109
113
  return {
110
114
  runtime: `${CLAUDE_RUNTIME_LABEL} listing`,
111
115
  generatedAt: now.toISOString(),
112
- groups: [
113
- {
114
- id: "1",
115
- title: "Core automations",
116
- items: expectedGroups.get("core") ?? [],
117
- },
118
- {
119
- id: "2",
120
- title: "Exploratory automations",
121
- items: expectedGroups.get("exploratory") ?? [],
122
- },
123
- ],
116
+ groups: renderAutomationGroups(expectedGroups),
124
117
  observedAutomations,
125
118
  };
126
119
  }
@@ -487,6 +480,13 @@ function normalizeClaudeRRule(value) {
487
480
  ) {
488
481
  return "FREQ=DAILY;INTERVAL=1";
489
482
  }
483
+ if (
484
+ cadence === "once a week" ||
485
+ cadence === "every week" ||
486
+ cadence === "weekly"
487
+ ) {
488
+ return "FREQ=WEEKLY;INTERVAL=1";
489
+ }
490
490
 
491
491
  const everyMinutes = cadence.match(/every (\d+) minutes?/);
492
492
  if (everyMinutes?.[1]) {
@@ -503,6 +503,11 @@ function normalizeClaudeRRule(value) {
503
503
  return `FREQ=DAILY;INTERVAL=${everyDays[1]}`;
504
504
  }
505
505
 
506
+ const everyWeeks = cadence.match(/every (\d+) weeks?/);
507
+ if (everyWeeks?.[1]) {
508
+ return `FREQ=WEEKLY;INTERVAL=${everyWeeks[1]}`;
509
+ }
510
+
506
511
  return undefined;
507
512
  }
508
513
 
@@ -527,6 +532,9 @@ function humanizeClaudeCadence(value) {
527
532
  if (normalized === "every day") {
528
533
  return "once a day";
529
534
  }
535
+ if (normalized === "weekly" || normalized === "every week") {
536
+ return "once a week";
537
+ }
530
538
  return normalized;
531
539
  }
532
540
 
@@ -556,6 +564,11 @@ function humanizeRRule(rrule) {
556
564
  return Number(daily[1]) === 1 ? "once a day" : `every ${daily[1]} days`;
557
565
  }
558
566
 
567
+ const weekly = rrule.match(/^FREQ=WEEKLY;INTERVAL=(\d+)$/);
568
+ if (weekly?.[1]) {
569
+ return Number(weekly[1]) === 1 ? "once a week" : `every ${weekly[1]} weeks`;
570
+ }
571
+
559
572
  return rrule;
560
573
  }
561
574
 
@@ -574,6 +587,11 @@ function cadenceLabelToIntervalMs(label) {
574
587
  return 24 * 60 * 60_000;
575
588
  }
576
589
 
590
+ const oncePerWeek = new Set(["once a week", "weekly"]);
591
+ if (oncePerWeek.has(label)) {
592
+ return 7 * 24 * 60 * 60_000;
593
+ }
594
+
577
595
  return null;
578
596
  }
579
597