@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.
- package/package.json +1 -1
- package/plugins/lisa/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa/.codex-plugin/skills/lisa-automation-status/SKILL.md +14 -8
- package/plugins/lisa/.codex-plugin/skills/lisa-setup-automations/SKILL.md +116 -1
- package/plugins/lisa/.codex-plugin/skills/lisa-tear-down-automations/SKILL.md +25 -5
- package/plugins/lisa/scripts/automation-status-claude-adapter.mjs +36 -18
- package/plugins/lisa/scripts/automation-status-codex-adapter.mjs +50 -27
- package/plugins/lisa/scripts/automation-status-expected-fleet.mjs +149 -6
- package/plugins/lisa/skills/lisa-automation-status/SKILL.md +14 -8
- package/plugins/lisa/skills/lisa-setup-automations/SKILL.md +116 -1
- package/plugins/lisa/skills/lisa-tear-down-automations/SKILL.md +26 -6
- package/plugins/lisa/skills/lisa-tear-down-automations/agents/openai.yaml +2 -2
- package/plugins/lisa-agy/plugin.json +1 -1
- package/plugins/lisa-agy/scripts/automation-status-claude-adapter.mjs +36 -18
- package/plugins/lisa-agy/scripts/automation-status-codex-adapter.mjs +50 -27
- package/plugins/lisa-agy/scripts/automation-status-expected-fleet.mjs +149 -6
- package/plugins/lisa-agy/skills/lisa-automation-status/SKILL.md +14 -8
- package/plugins/lisa-agy/skills/lisa-setup-automations/SKILL.md +116 -1
- package/plugins/lisa-agy/skills/lisa-tear-down-automations/SKILL.md +26 -6
- package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-agy/plugin.json +1 -1
- package/plugins/lisa-cdk-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-copilot/scripts/automation-status-claude-adapter.mjs +36 -18
- package/plugins/lisa-copilot/scripts/automation-status-codex-adapter.mjs +50 -27
- package/plugins/lisa-copilot/scripts/automation-status-expected-fleet.mjs +149 -6
- package/plugins/lisa-copilot/skills/lisa-automation-status/SKILL.md +14 -8
- package/plugins/lisa-copilot/skills/lisa-setup-automations/SKILL.md +116 -1
- package/plugins/lisa-copilot/skills/lisa-tear-down-automations/SKILL.md +26 -6
- package/plugins/lisa-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cursor/scripts/automation-status-claude-adapter.mjs +36 -18
- package/plugins/lisa-cursor/scripts/automation-status-codex-adapter.mjs +50 -27
- package/plugins/lisa-cursor/scripts/automation-status-expected-fleet.mjs +149 -6
- package/plugins/lisa-cursor/skills/lisa-automation-status/SKILL.md +14 -8
- package/plugins/lisa-cursor/skills/lisa-setup-automations/SKILL.md +116 -1
- package/plugins/lisa-cursor/skills/lisa-tear-down-automations/SKILL.md +26 -6
- package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-agy/plugin.json +1 -1
- package/plugins/lisa-expo-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-agy/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs-agy/plugin.json +1 -1
- package/plugins/lisa-nestjs-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw-agy/plugin.json +1 -1
- package/plugins/lisa-openclaw-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser-agy/plugin.json +1 -1
- package/plugins/lisa-phaser-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-rails-agy/plugin.json +1 -1
- package/plugins/lisa-rails-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript-agy/plugin.json +1 -1
- package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki-agy/plugin.json +1 -1
- package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/src/base/scripts/automation-status-claude-adapter.mjs +36 -18
- package/plugins/src/base/scripts/automation-status-codex-adapter.mjs +50 -27
- package/plugins/src/base/scripts/automation-status-expected-fleet.mjs +149 -6
- package/plugins/src/base/skills/lisa-automation-status/SKILL.md +14 -8
- package/plugins/src/base/skills/lisa-setup-automations/SKILL.md +116 -1
- 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
|
|
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
|
|
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
|
-
|
|
22
|
-
- `
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
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
|
|
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
|
|
25
|
-
stable `lisa-auto-<project>-` name prefix
|
|
26
|
-
`
|
|
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
|
|
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
|
|
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
|
|
4
|
+
- "Use $lisa-tear-down-automations: Remove every recurring Lisa automation that /setup-automations registered for this project — whatever is actually registered under the…."
|
|
@@ -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 =
|
|
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
|
-
|
|
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
|
|
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
|
|