@codyswann/lisa 2.98.0 → 2.99.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 +2 -2
- package/plugins/lisa/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa/commands/intake-explain.md +14 -0
- package/plugins/lisa/skills/intake-explain/SKILL.md +87 -0
- package/plugins/lisa/skills/intake-explain/agents/openai.yaml +4 -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/intake-explain.md +14 -0
- package/plugins/src/base/skills/intake-explain/SKILL.md +87 -0
package/package.json
CHANGED
|
@@ -82,7 +82,7 @@
|
|
|
82
82
|
"lodash": ">=4.18.1"
|
|
83
83
|
},
|
|
84
84
|
"name": "@codyswann/lisa",
|
|
85
|
-
"version": "2.
|
|
85
|
+
"version": "2.99.0",
|
|
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": {
|
|
@@ -199,7 +199,7 @@
|
|
|
199
199
|
"vitest": "^4.1.0"
|
|
200
200
|
},
|
|
201
201
|
"devDependencies": {
|
|
202
|
-
"@codyswann/lisa": "^2.
|
|
202
|
+
"@codyswann/lisa": "^2.98.0",
|
|
203
203
|
"@types/js-yaml": "^4.0.9",
|
|
204
204
|
"eslint-plugin-oxlint": "^1.62.0",
|
|
205
205
|
"js-yaml": "^4.1.1",
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "Inspect one PRD or build item, explain how Lisa classifies it right now, and report the exact intake or repair gate affecting it. Read-only by default."
|
|
3
|
+
argument-hint: "<item-ref>"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Use the /lisa:intake-explain skill to inspect a single repo-scoped PRD or build item, explain its current lifecycle role, and report whether Lisa would intake it, repair it, hold it, skip it, or leave it product-owned. $ARGUMENTS
|
|
7
|
+
|
|
8
|
+
Common operator usage:
|
|
9
|
+
|
|
10
|
+
- `/lisa:intake-explain https://github.com/acme/repo/issues/123`
|
|
11
|
+
- `/lisa:intake-explain PRD-456`
|
|
12
|
+
- `/lisa:intake-explain https://linear.app/acme/issue/ENG-123/example`
|
|
13
|
+
|
|
14
|
+
This surface is read-only in v1. Use it when you need a deterministic explanation for why one item is moving, waiting, blocked, skipped, or ignored before deciding whether to run `/lisa:intake`, `/lisa:repair-intake`, `/lisa:queue-status`, or a tracker-native fix.
|
|
@@ -0,0 +1,87 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: intake-explain
|
|
3
|
+
description: "Read-only operator surface for diagnosing one repo-scoped PRD or build item against Lisa's current intake and repair contracts. Resolves the item's queue family, lifecycle role, ownership boundary, and gate outcomes using the same source/tracker detection, lifecycle naming, leaf-only, dependency, staleness, and backoff semantics the write-side intake and repair flows already enforce."
|
|
4
|
+
allowed-tools: ["Skill", "Bash", "Read"]
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Intake Explain: $ARGUMENTS
|
|
8
|
+
|
|
9
|
+
`/lisa:intake-explain` is the operator-facing explanation surface for one specific item in the **current repo or project**. It answers the per-item diagnosis question Lisa's batch flows intentionally do not answer directly: what lifecycle lane the item belongs to, which Lisa rule or gate applies right now, whether the item is eligible for intake or repair, and what the next relevant action should be.
|
|
10
|
+
|
|
11
|
+
This command is **read-only** in v1. It does not claim, relabel, repair, transition, comment on, decompose, or otherwise mutate the item. It complements `/lisa:intake`, `/lisa:repair-intake`, `/lisa:queue-status`, `/lisa:automation-status`, and tracker-native inspection; it does not replace them.
|
|
12
|
+
|
|
13
|
+
## Confirmation policy
|
|
14
|
+
|
|
15
|
+
Do **not** ask for confirmation once invoked. This skill inspects one item and reports what the current Lisa contract says about it. There are no write-side effects in the v1 surface.
|
|
16
|
+
|
|
17
|
+
## Scope
|
|
18
|
+
|
|
19
|
+
Inspect exactly one repo-scoped item reference:
|
|
20
|
+
|
|
21
|
+
- a GitHub issue URL or `owner/repo#123` ref
|
|
22
|
+
- a Linear issue or project URL
|
|
23
|
+
- a JIRA issue key
|
|
24
|
+
- a Notion PRD/item URL
|
|
25
|
+
- a Confluence PRD page URL
|
|
26
|
+
|
|
27
|
+
The skill must determine whether the item belongs to the PRD lifecycle or the build lifecycle, then explain the item's status using the **same contract** Lisa already uses for `/lisa:intake` and `/lisa:repair-intake`. Do **not** invent a second source of truth for queue detection, lifecycle role naming, repo scoping, or repair eligibility.
|
|
28
|
+
|
|
29
|
+
## Contract reuse
|
|
30
|
+
|
|
31
|
+
Resolve item family, queue source/tracker, and lifecycle role names from `.lisa.config.json` plus the same defaults the active intake and repair flows already consume.
|
|
32
|
+
|
|
33
|
+
Reuse the existing execution-side semantics instead of recreating them by hand:
|
|
34
|
+
|
|
35
|
+
- queue/source detection and lifecycle naming from intake + repair-intake
|
|
36
|
+
- product-owned versus Lisa-owned lifecycle roles
|
|
37
|
+
- leaf-only and repo-scope build eligibility
|
|
38
|
+
- active dependency holds
|
|
39
|
+
- repair staleness thresholds and activity signals
|
|
40
|
+
- repair backoff / loop-prevention suppression
|
|
41
|
+
|
|
42
|
+
Work from the same vendor families Lisa already supports for intake and repair: GitHub, Linear, JIRA, Notion, and Confluence.
|
|
43
|
+
|
|
44
|
+
## What to report
|
|
45
|
+
|
|
46
|
+
Render a stable terminal-first diagnosis for one item:
|
|
47
|
+
|
|
48
|
+
1. Item identity and resolved lifecycle family (`PRD` or `BUILD`).
|
|
49
|
+
2. The current lifecycle role and whether that role is product-owned or Lisa-owned.
|
|
50
|
+
3. The exact rule, gate, or ownership boundary currently driving behavior.
|
|
51
|
+
4. A verdict such as `ELIGIBLE_FOR_INTAKE`, `ELIGIBLE_FOR_REPAIR`, `WAITING_ON_STALENESS`, `HELD_BY_BLOCKERS`, `NON_LEAF_CONTAINER`, `PRODUCT_OWNED_STATE`, or `MISCONFIGURED`.
|
|
52
|
+
5. The smallest useful next action, such as `/lisa:intake`, `/lisa:repair-intake`, decomposition, blocker resolution, or manual product clarification.
|
|
53
|
+
|
|
54
|
+
Keep observable item facts separate from the recommended next step so operators can tell what Lisa knows versus what Lisa suggests.
|
|
55
|
+
|
|
56
|
+
## Gate and ownership expectations
|
|
57
|
+
|
|
58
|
+
The explanation must stay aligned with existing Lisa rules:
|
|
59
|
+
|
|
60
|
+
- If a build item is a parent/container or a childless Epic/Story/Spike, explain the leaf-only gate and say direct build pickup is not allowed.
|
|
61
|
+
- If a build item has active blockers, list the blocker refs and explain that intake would hold or skip it until they clear.
|
|
62
|
+
- If a PRD is in a product-owned role such as `draft`, `shipped`, or `verified`, explain why intake or repair will not mutate it.
|
|
63
|
+
- If a claimed, in-review, or blocked item is not yet repairable, explain the relevant staleness or backoff condition at a human-readable level.
|
|
64
|
+
- If the repo or lifecycle namespace is unresolved, report `MISCONFIGURED` instead of pretending the item is idle or actionable.
|
|
65
|
+
|
|
66
|
+
## Output shape
|
|
67
|
+
|
|
68
|
+
Use a stable grouped shape so one diagnosis is easy to scan:
|
|
69
|
+
|
|
70
|
+
```text
|
|
71
|
+
Item: <identity>
|
|
72
|
+
Lifecycle: <PRD|BUILD>
|
|
73
|
+
Role: <current role> (<product-owned|Lisa-owned>)
|
|
74
|
+
Verdict: <VERDICT>
|
|
75
|
+
Why: <rule or gate explanation>
|
|
76
|
+
Next action: <smallest useful follow-up>
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
When helpful, include one short `Signals:` or `Relevant refs:` line for the exact blockers, staleness timestamps, parent/child classification, or repair markers that justify the verdict.
|
|
80
|
+
|
|
81
|
+
## Rules
|
|
82
|
+
|
|
83
|
+
- Stay **read-only**. Never claim, relabel, transition, comment on, create, decompose, or repair work from this skill.
|
|
84
|
+
- Keep the explanation repo-scoped to the current project rather than aggregating unrelated repos or trackers.
|
|
85
|
+
- Reuse intake and repair-intake contract semantics so diagnosis and execution do not drift.
|
|
86
|
+
- Prefer existing vendor read surfaces and validators over creating a second lifecycle engine.
|
|
87
|
+
- If the current runtime or vendor surface cannot expose a needed signal, say that explicitly instead of guessing.
|
|
@@ -0,0 +1,4 @@
|
|
|
1
|
+
display_name: "Intake Explain"
|
|
2
|
+
short_description: "Read-only operator surface for diagnosing one repo-scoped PRD or build item against Lisa's current intake and repair contracts"
|
|
3
|
+
default_prompt:
|
|
4
|
+
- "Use $intake-explain: Read-only operator surface for diagnosing one repo-scoped PRD or build item against Lisa's current intake and repair contracts."
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.99.0",
|
|
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.
|
|
3
|
+
"version": "2.99.0",
|
|
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"
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "Inspect one PRD or build item, explain how Lisa classifies it right now, and report the exact intake or repair gate affecting it. Read-only by default."
|
|
3
|
+
argument-hint: "<item-ref>"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Use the /lisa:intake-explain skill to inspect a single repo-scoped PRD or build item, explain its current lifecycle role, and report whether Lisa would intake it, repair it, hold it, skip it, or leave it product-owned. $ARGUMENTS
|
|
7
|
+
|
|
8
|
+
Common operator usage:
|
|
9
|
+
|
|
10
|
+
- `/lisa:intake-explain https://github.com/acme/repo/issues/123`
|
|
11
|
+
- `/lisa:intake-explain PRD-456`
|
|
12
|
+
- `/lisa:intake-explain https://linear.app/acme/issue/ENG-123/example`
|
|
13
|
+
|
|
14
|
+
This surface is read-only in v1. Use it when you need a deterministic explanation for why one item is moving, waiting, blocked, skipped, or ignored before deciding whether to run `/lisa:intake`, `/lisa:repair-intake`, `/lisa:queue-status`, or a tracker-native fix.
|
|
@@ -0,0 +1,87 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: intake-explain
|
|
3
|
+
description: "Read-only operator surface for diagnosing one repo-scoped PRD or build item against Lisa's current intake and repair contracts. Resolves the item's queue family, lifecycle role, ownership boundary, and gate outcomes using the same source/tracker detection, lifecycle naming, leaf-only, dependency, staleness, and backoff semantics the write-side intake and repair flows already enforce."
|
|
4
|
+
allowed-tools: ["Skill", "Bash", "Read"]
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Intake Explain: $ARGUMENTS
|
|
8
|
+
|
|
9
|
+
`/lisa:intake-explain` is the operator-facing explanation surface for one specific item in the **current repo or project**. It answers the per-item diagnosis question Lisa's batch flows intentionally do not answer directly: what lifecycle lane the item belongs to, which Lisa rule or gate applies right now, whether the item is eligible for intake or repair, and what the next relevant action should be.
|
|
10
|
+
|
|
11
|
+
This command is **read-only** in v1. It does not claim, relabel, repair, transition, comment on, decompose, or otherwise mutate the item. It complements `/lisa:intake`, `/lisa:repair-intake`, `/lisa:queue-status`, `/lisa:automation-status`, and tracker-native inspection; it does not replace them.
|
|
12
|
+
|
|
13
|
+
## Confirmation policy
|
|
14
|
+
|
|
15
|
+
Do **not** ask for confirmation once invoked. This skill inspects one item and reports what the current Lisa contract says about it. There are no write-side effects in the v1 surface.
|
|
16
|
+
|
|
17
|
+
## Scope
|
|
18
|
+
|
|
19
|
+
Inspect exactly one repo-scoped item reference:
|
|
20
|
+
|
|
21
|
+
- a GitHub issue URL or `owner/repo#123` ref
|
|
22
|
+
- a Linear issue or project URL
|
|
23
|
+
- a JIRA issue key
|
|
24
|
+
- a Notion PRD/item URL
|
|
25
|
+
- a Confluence PRD page URL
|
|
26
|
+
|
|
27
|
+
The skill must determine whether the item belongs to the PRD lifecycle or the build lifecycle, then explain the item's status using the **same contract** Lisa already uses for `/lisa:intake` and `/lisa:repair-intake`. Do **not** invent a second source of truth for queue detection, lifecycle role naming, repo scoping, or repair eligibility.
|
|
28
|
+
|
|
29
|
+
## Contract reuse
|
|
30
|
+
|
|
31
|
+
Resolve item family, queue source/tracker, and lifecycle role names from `.lisa.config.json` plus the same defaults the active intake and repair flows already consume.
|
|
32
|
+
|
|
33
|
+
Reuse the existing execution-side semantics instead of recreating them by hand:
|
|
34
|
+
|
|
35
|
+
- queue/source detection and lifecycle naming from intake + repair-intake
|
|
36
|
+
- product-owned versus Lisa-owned lifecycle roles
|
|
37
|
+
- leaf-only and repo-scope build eligibility
|
|
38
|
+
- active dependency holds
|
|
39
|
+
- repair staleness thresholds and activity signals
|
|
40
|
+
- repair backoff / loop-prevention suppression
|
|
41
|
+
|
|
42
|
+
Work from the same vendor families Lisa already supports for intake and repair: GitHub, Linear, JIRA, Notion, and Confluence.
|
|
43
|
+
|
|
44
|
+
## What to report
|
|
45
|
+
|
|
46
|
+
Render a stable terminal-first diagnosis for one item:
|
|
47
|
+
|
|
48
|
+
1. Item identity and resolved lifecycle family (`PRD` or `BUILD`).
|
|
49
|
+
2. The current lifecycle role and whether that role is product-owned or Lisa-owned.
|
|
50
|
+
3. The exact rule, gate, or ownership boundary currently driving behavior.
|
|
51
|
+
4. A verdict such as `ELIGIBLE_FOR_INTAKE`, `ELIGIBLE_FOR_REPAIR`, `WAITING_ON_STALENESS`, `HELD_BY_BLOCKERS`, `NON_LEAF_CONTAINER`, `PRODUCT_OWNED_STATE`, or `MISCONFIGURED`.
|
|
52
|
+
5. The smallest useful next action, such as `/lisa:intake`, `/lisa:repair-intake`, decomposition, blocker resolution, or manual product clarification.
|
|
53
|
+
|
|
54
|
+
Keep observable item facts separate from the recommended next step so operators can tell what Lisa knows versus what Lisa suggests.
|
|
55
|
+
|
|
56
|
+
## Gate and ownership expectations
|
|
57
|
+
|
|
58
|
+
The explanation must stay aligned with existing Lisa rules:
|
|
59
|
+
|
|
60
|
+
- If a build item is a parent/container or a childless Epic/Story/Spike, explain the leaf-only gate and say direct build pickup is not allowed.
|
|
61
|
+
- If a build item has active blockers, list the blocker refs and explain that intake would hold or skip it until they clear.
|
|
62
|
+
- If a PRD is in a product-owned role such as `draft`, `shipped`, or `verified`, explain why intake or repair will not mutate it.
|
|
63
|
+
- If a claimed, in-review, or blocked item is not yet repairable, explain the relevant staleness or backoff condition at a human-readable level.
|
|
64
|
+
- If the repo or lifecycle namespace is unresolved, report `MISCONFIGURED` instead of pretending the item is idle or actionable.
|
|
65
|
+
|
|
66
|
+
## Output shape
|
|
67
|
+
|
|
68
|
+
Use a stable grouped shape so one diagnosis is easy to scan:
|
|
69
|
+
|
|
70
|
+
```text
|
|
71
|
+
Item: <identity>
|
|
72
|
+
Lifecycle: <PRD|BUILD>
|
|
73
|
+
Role: <current role> (<product-owned|Lisa-owned>)
|
|
74
|
+
Verdict: <VERDICT>
|
|
75
|
+
Why: <rule or gate explanation>
|
|
76
|
+
Next action: <smallest useful follow-up>
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
When helpful, include one short `Signals:` or `Relevant refs:` line for the exact blockers, staleness timestamps, parent/child classification, or repair markers that justify the verdict.
|
|
80
|
+
|
|
81
|
+
## Rules
|
|
82
|
+
|
|
83
|
+
- Stay **read-only**. Never claim, relabel, transition, comment on, create, decompose, or repair work from this skill.
|
|
84
|
+
- Keep the explanation repo-scoped to the current project rather than aggregating unrelated repos or trackers.
|
|
85
|
+
- Reuse intake and repair-intake contract semantics so diagnosis and execution do not drift.
|
|
86
|
+
- Prefer existing vendor read surfaces and validators over creating a second lifecycle engine.
|
|
87
|
+
- If the current runtime or vendor surface cannot expose a needed signal, say that explicitly instead of guessing.
|