@codyswann/lisa 2.97.0 → 2.97.1
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/README.md +4 -0
- 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/commands/queue-status.md +22 -1
- package/plugins/lisa/skills/queue-status/SKILL.md +38 -0
- package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.codex-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-nestjs/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.codex-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-rails/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.codex-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-wiki/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.codex-plugin/plugin.json +1 -1
- package/plugins/src/base/commands/queue-status.md +22 -1
- package/plugins/src/base/skills/queue-status/SKILL.md +38 -0
package/README.md
CHANGED
|
@@ -79,6 +79,10 @@ Most users only ever call `/lisa:research`, `/lisa:plan`, and `/lisa:implement`.
|
|
|
79
79
|
| Command | What it does |
|
|
80
80
|
| --- | --- |
|
|
81
81
|
| `/lisa:intake <queue-url>` | Scans a Ready queue (Notion PRD database, JIRA project, GitHub repo, Linear team, Confluence space) and dispatches each item through the right lifecycle command. Designed as the cron target for unattended runs. |
|
|
82
|
+
| `/lisa:queue-status [queue=prd|queue=build]` | Read-only queue inspection for the current repo. Distinguishes idle vs misconfigured queues, highlights the most actionable item, and points operators to `/lisa:intake`, `/lisa:repair-intake`, `/lisa:automation-status`, or `/lisa:verify-prd`. |
|
|
83
|
+
| `/lisa:repair-intake <queue-url>` | Read/write recovery scan for blocked, stale, or inconsistent queue state when normal intake is not the right next move. |
|
|
84
|
+
| `/lisa:automation-status` | Read-only inspection of the repo's expected Lisa automation fleet so operators can distinguish empty queues from stale, drifted, or failing scheduler jobs. |
|
|
85
|
+
| `/lisa:verify-prd <prd>` | Initiative-level acceptance pass for shipped PRDs. Verifies the shipped surface against the PRD and reopens to ticketed with fix work on failure. |
|
|
82
86
|
|
|
83
87
|
PRD intake records generated work with native hierarchy where the source and tracker support it, and with a durable generated-work fallback everywhere else. The vendor matrix for GitHub, Linear, JIRA/Atlassian, Confluence, Notion, and cross-vendor queues lives in `plugins/src/base/rules/prd-lifecycle-rollup.md`.
|
|
84
88
|
|
package/package.json
CHANGED
|
@@ -82,7 +82,7 @@
|
|
|
82
82
|
"lodash": ">=4.18.1"
|
|
83
83
|
},
|
|
84
84
|
"name": "@codyswann/lisa",
|
|
85
|
-
"version": "2.97.
|
|
85
|
+
"version": "2.97.1",
|
|
86
86
|
"description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
|
|
87
87
|
"main": "dist/index.js",
|
|
88
88
|
"exports": {
|
|
@@ -10,4 +10,25 @@ Common operator usage:
|
|
|
10
10
|
- `/lisa:queue-status queue=prd`
|
|
11
11
|
- `/lisa:queue-status queue=build`
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
Use this when you need to answer:
|
|
14
|
+
|
|
15
|
+
- Is the queue actually idle, or is Lisa misconfigured?
|
|
16
|
+
- Which queue item is the most actionable next?
|
|
17
|
+
- Should the next command be `/lisa:intake`, `/lisa:repair-intake`, `/lisa:automation-status`, or `/lisa:verify-prd`?
|
|
18
|
+
|
|
19
|
+
This surface is read-only in v1. Use it to understand whether the repo's PRD and build queues are idle, healthy, attention-needed, or misconfigured before deciding whether to run `/lisa:intake`, `/lisa:repair-intake`, `/lisa:automation-status`, `/lisa:verify-prd`, or deeper tracker-native investigation.
|
|
20
|
+
|
|
21
|
+
Quick interpretation guide:
|
|
22
|
+
|
|
23
|
+
- `IDLE`: the queue resolved correctly and nothing actionable is waiting. No immediate Lisa action is required.
|
|
24
|
+
- `HEALTHY`: the queue resolved correctly and normal work is present. Follow the highlighted next step, usually `/lisa:intake`.
|
|
25
|
+
- `ATTENTION_NEEDED`: blocked, stalled, or aging work needs operator follow-up. Use the highlighted item and remediation hint to choose the next command, usually `/lisa:repair-intake`.
|
|
26
|
+
- `MISCONFIGURED`: queue resolution or lifecycle adoption is broken. Fix config, labels/statuses, or scheduler drift before trusting queue state.
|
|
27
|
+
|
|
28
|
+
Highlighted-item semantics:
|
|
29
|
+
|
|
30
|
+
- A highlighted item is the single oldest or most actionable queue item for that section, not a full dump of all matching work.
|
|
31
|
+
- `ready` highlights usually point to `/lisa:intake`.
|
|
32
|
+
- `blocked`, stalled, or long-claimed highlights usually point to `/lisa:repair-intake`.
|
|
33
|
+
- Shipped PRD highlights usually point to `/lisa:verify-prd`.
|
|
34
|
+
- If queue behavior looks wrong for both PRD and build lanes, inspect `/lisa:automation-status` before assuming the queue itself is the problem.
|
|
@@ -29,6 +29,24 @@ Support a repo-scoped queue selector when requested:
|
|
|
29
29
|
- `queue=prd`: inspect only the PRD queue
|
|
30
30
|
- `queue=build`: inspect only the build queue
|
|
31
31
|
|
|
32
|
+
## Operator usage
|
|
33
|
+
|
|
34
|
+
Typical entrypoints:
|
|
35
|
+
|
|
36
|
+
```text
|
|
37
|
+
/lisa:queue-status
|
|
38
|
+
/lisa:queue-status queue=prd
|
|
39
|
+
/lisa:queue-status queue=build
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
Use this command when an operator needs to answer one of these questions for the current repo:
|
|
43
|
+
|
|
44
|
+
- "Is this queue truly idle, or is it misconfigured?"
|
|
45
|
+
- "Which item is the most actionable next?"
|
|
46
|
+
- "Should I run `/lisa:intake`, `/lisa:repair-intake`, `/lisa:automation-status`, or `/lisa:verify-prd` next?"
|
|
47
|
+
|
|
48
|
+
Keep the report terminal-first and immediately actionable: observable queue facts first, then the smallest useful next command.
|
|
49
|
+
|
|
32
50
|
## What to report
|
|
33
51
|
|
|
34
52
|
Render the report in **grouped sections** so operators can scan it top-down without reading raw tracker dumps:
|
|
@@ -48,6 +66,19 @@ For each inspected queue, report:
|
|
|
48
66
|
|
|
49
67
|
The report should stay terminal-first and immediately actionable: observable queue facts first, then the smallest useful next step.
|
|
50
68
|
|
|
69
|
+
## Highlight semantics
|
|
70
|
+
|
|
71
|
+
Each queue section may include one or more highlighted items. A highlight is not a raw dump of every issue in that role; it is the single oldest or otherwise most actionable item Lisa can justify surfacing without mutating work.
|
|
72
|
+
|
|
73
|
+
Interpret highlights by role:
|
|
74
|
+
|
|
75
|
+
- `ready`: work is waiting to be claimed. The usual next step is `/lisa:intake <queue>`.
|
|
76
|
+
- `blocked`: work is stuck behind an explicit blocker or failed pre-flight. The usual next step is `/lisa:repair-intake <queue>` after validating the blocker context.
|
|
77
|
+
- `claimed` or in-review/review states: work is in motion but may be aging. The usual next step is to inspect the active implementation or review path before escalating to `/lisa:repair-intake <queue>`.
|
|
78
|
+
- `shipped`: PRD work looks ready for initiative-level acceptance. The usual next step is `/lisa:verify-prd <prd-ref>`.
|
|
79
|
+
|
|
80
|
+
If both queues look unexpectedly quiet or stale, mention `/lisa:automation-status` as the scheduler-health follow-up before implying the queues themselves are empty or broken.
|
|
81
|
+
|
|
51
82
|
## Output shape
|
|
52
83
|
|
|
53
84
|
Use a stable terminal-friendly shape:
|
|
@@ -86,6 +117,13 @@ Status-specific remediation guidance:
|
|
|
86
117
|
- `ATTENTION_NEEDED`: identify the most actionable blocked or stalled items and suggest the next Lisa or tracker-native command to investigate.
|
|
87
118
|
- `MISCONFIGURED`: show which queue contract is missing or unresolved and recommend fixing `.lisa.config.json`, adopting the lifecycle namespace, or rerunning the relevant setup flow.
|
|
88
119
|
|
|
120
|
+
Command handoff expectations:
|
|
121
|
+
|
|
122
|
+
- Prefer `/lisa:intake <queue>` when the actionable highlight is `ready` work.
|
|
123
|
+
- Prefer `/lisa:repair-intake <queue>` when the actionable highlight is blocked, stalled, or suspiciously old claimed/review work.
|
|
124
|
+
- Prefer `/lisa:verify-prd <prd-ref>` when the PRD side surfaces shipped work that appears ready for initiative-level verification.
|
|
125
|
+
- Prefer `/lisa:automation-status` when queue output suggests scheduler drift, stale unattended execution, or a mismatch between expected and observed queue activity.
|
|
126
|
+
|
|
89
127
|
## Rules
|
|
90
128
|
|
|
91
129
|
- Stay **read-only**. Never create, update, claim, relabel, repair, transition, or comment on queue items from this skill.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.97.
|
|
3
|
+
"version": "2.97.1",
|
|
4
4
|
"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",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.97.
|
|
3
|
+
"version": "2.97.1",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -10,4 +10,25 @@ Common operator usage:
|
|
|
10
10
|
- `/lisa:queue-status queue=prd`
|
|
11
11
|
- `/lisa:queue-status queue=build`
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
Use this when you need to answer:
|
|
14
|
+
|
|
15
|
+
- Is the queue actually idle, or is Lisa misconfigured?
|
|
16
|
+
- Which queue item is the most actionable next?
|
|
17
|
+
- Should the next command be `/lisa:intake`, `/lisa:repair-intake`, `/lisa:automation-status`, or `/lisa:verify-prd`?
|
|
18
|
+
|
|
19
|
+
This surface is read-only in v1. Use it to understand whether the repo's PRD and build queues are idle, healthy, attention-needed, or misconfigured before deciding whether to run `/lisa:intake`, `/lisa:repair-intake`, `/lisa:automation-status`, `/lisa:verify-prd`, or deeper tracker-native investigation.
|
|
20
|
+
|
|
21
|
+
Quick interpretation guide:
|
|
22
|
+
|
|
23
|
+
- `IDLE`: the queue resolved correctly and nothing actionable is waiting. No immediate Lisa action is required.
|
|
24
|
+
- `HEALTHY`: the queue resolved correctly and normal work is present. Follow the highlighted next step, usually `/lisa:intake`.
|
|
25
|
+
- `ATTENTION_NEEDED`: blocked, stalled, or aging work needs operator follow-up. Use the highlighted item and remediation hint to choose the next command, usually `/lisa:repair-intake`.
|
|
26
|
+
- `MISCONFIGURED`: queue resolution or lifecycle adoption is broken. Fix config, labels/statuses, or scheduler drift before trusting queue state.
|
|
27
|
+
|
|
28
|
+
Highlighted-item semantics:
|
|
29
|
+
|
|
30
|
+
- A highlighted item is the single oldest or most actionable queue item for that section, not a full dump of all matching work.
|
|
31
|
+
- `ready` highlights usually point to `/lisa:intake`.
|
|
32
|
+
- `blocked`, stalled, or long-claimed highlights usually point to `/lisa:repair-intake`.
|
|
33
|
+
- Shipped PRD highlights usually point to `/lisa:verify-prd`.
|
|
34
|
+
- If queue behavior looks wrong for both PRD and build lanes, inspect `/lisa:automation-status` before assuming the queue itself is the problem.
|
|
@@ -29,6 +29,24 @@ Support a repo-scoped queue selector when requested:
|
|
|
29
29
|
- `queue=prd`: inspect only the PRD queue
|
|
30
30
|
- `queue=build`: inspect only the build queue
|
|
31
31
|
|
|
32
|
+
## Operator usage
|
|
33
|
+
|
|
34
|
+
Typical entrypoints:
|
|
35
|
+
|
|
36
|
+
```text
|
|
37
|
+
/lisa:queue-status
|
|
38
|
+
/lisa:queue-status queue=prd
|
|
39
|
+
/lisa:queue-status queue=build
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
Use this command when an operator needs to answer one of these questions for the current repo:
|
|
43
|
+
|
|
44
|
+
- "Is this queue truly idle, or is it misconfigured?"
|
|
45
|
+
- "Which item is the most actionable next?"
|
|
46
|
+
- "Should I run `/lisa:intake`, `/lisa:repair-intake`, `/lisa:automation-status`, or `/lisa:verify-prd` next?"
|
|
47
|
+
|
|
48
|
+
Keep the report terminal-first and immediately actionable: observable queue facts first, then the smallest useful next command.
|
|
49
|
+
|
|
32
50
|
## What to report
|
|
33
51
|
|
|
34
52
|
Render the report in **grouped sections** so operators can scan it top-down without reading raw tracker dumps:
|
|
@@ -48,6 +66,19 @@ For each inspected queue, report:
|
|
|
48
66
|
|
|
49
67
|
The report should stay terminal-first and immediately actionable: observable queue facts first, then the smallest useful next step.
|
|
50
68
|
|
|
69
|
+
## Highlight semantics
|
|
70
|
+
|
|
71
|
+
Each queue section may include one or more highlighted items. A highlight is not a raw dump of every issue in that role; it is the single oldest or otherwise most actionable item Lisa can justify surfacing without mutating work.
|
|
72
|
+
|
|
73
|
+
Interpret highlights by role:
|
|
74
|
+
|
|
75
|
+
- `ready`: work is waiting to be claimed. The usual next step is `/lisa:intake <queue>`.
|
|
76
|
+
- `blocked`: work is stuck behind an explicit blocker or failed pre-flight. The usual next step is `/lisa:repair-intake <queue>` after validating the blocker context.
|
|
77
|
+
- `claimed` or in-review/review states: work is in motion but may be aging. The usual next step is to inspect the active implementation or review path before escalating to `/lisa:repair-intake <queue>`.
|
|
78
|
+
- `shipped`: PRD work looks ready for initiative-level acceptance. The usual next step is `/lisa:verify-prd <prd-ref>`.
|
|
79
|
+
|
|
80
|
+
If both queues look unexpectedly quiet or stale, mention `/lisa:automation-status` as the scheduler-health follow-up before implying the queues themselves are empty or broken.
|
|
81
|
+
|
|
51
82
|
## Output shape
|
|
52
83
|
|
|
53
84
|
Use a stable terminal-friendly shape:
|
|
@@ -86,6 +117,13 @@ Status-specific remediation guidance:
|
|
|
86
117
|
- `ATTENTION_NEEDED`: identify the most actionable blocked or stalled items and suggest the next Lisa or tracker-native command to investigate.
|
|
87
118
|
- `MISCONFIGURED`: show which queue contract is missing or unresolved and recommend fixing `.lisa.config.json`, adopting the lifecycle namespace, or rerunning the relevant setup flow.
|
|
88
119
|
|
|
120
|
+
Command handoff expectations:
|
|
121
|
+
|
|
122
|
+
- Prefer `/lisa:intake <queue>` when the actionable highlight is `ready` work.
|
|
123
|
+
- Prefer `/lisa:repair-intake <queue>` when the actionable highlight is blocked, stalled, or suspiciously old claimed/review work.
|
|
124
|
+
- Prefer `/lisa:verify-prd <prd-ref>` when the PRD side surfaces shipped work that appears ready for initiative-level verification.
|
|
125
|
+
- Prefer `/lisa:automation-status` when queue output suggests scheduler drift, stale unattended execution, or a mismatch between expected and observed queue activity.
|
|
126
|
+
|
|
89
127
|
## Rules
|
|
90
128
|
|
|
91
129
|
- Stay **read-only**. Never create, update, claim, relabel, repair, transition, or comment on queue items from this skill.
|