@codyswann/lisa 1.81.7 → 1.82.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 (9) hide show
  1. package/package.json +1 -1
  2. package/plugins/lisa/.claude-plugin/plugin.json +1 -1
  3. package/plugins/lisa/rules/intent-routing.md +22 -15
  4. package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
  5. package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
  6. package/plugins/lisa-nestjs/.claude-plugin/plugin.json +1 -1
  7. package/plugins/lisa-rails/.claude-plugin/plugin.json +1 -1
  8. package/plugins/lisa-typescript/.claude-plugin/plugin.json +1 -1
  9. package/plugins/src/base/rules/intent-routing.md +22 -15
package/package.json CHANGED
@@ -76,7 +76,7 @@
76
76
  "lodash": ">=4.18.1"
77
77
  },
78
78
  "name": "@codyswann/lisa",
79
- "version": "1.81.7",
79
+ "version": "1.82.0",
80
80
  "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
81
81
  "main": "dist/index.js",
82
82
  "exports": {
package/plugins/lisa/.claude-plugin/plugin.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa",
3
- "version": "1.81.7",
3
+ "version": "1.82.0",
4
4
  "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
5
5
  "author": {
6
6
  "name": "Cody Swann"
package/plugins/lisa/rules/intent-routing.md CHANGED
@@ -13,7 +13,12 @@ This protocol runs **once per session**, on the first user message. After that,
13
13
  3. If you cannot confidently classify the request:
14
14
  - **Interactive session** (user is present): present a multiple choice using AskUserQuestion with options: Research, Plan, Implement, Verify, No flow.
15
15
  - **Headless/non-interactive session** (running with `-p` flag, in a CI pipeline, or as a scheduled agent): do NOT ask the user. Classify to the best of your ability from available context (ticket content, prompt text, current branch state). If you truly cannot classify, default to "No flow" and proceed with the request as-is.
16
- 4. Once a flow is selected, state it explicitly (e.g., *"Flow: Implement/Fix"*) and check its readiness gate before proceeding.
16
+ 4. Once a flow is selected, **echo it back explicitly** before doing anything else. State the flow, the work type (if applicable), and a one-sentence justification for why this flow was chosen. Example:
17
+
18
+ > **Flow: Implement/Fix**
19
+ > This is a bug report with a specific error and reproduction steps, so it routes to the Fix work type within the Implement flow.
20
+
21
+ This echo is mandatory. Do not skip it, abbreviate it, or bury it in other output. The user must see the flow classification before any work begins.
17
22
  5. If you are a subagent: your parent agent has already determined the flow -- do NOT ask the user to choose a flow. Execute your assigned work within the established flow context.
18
23
 
19
24
  ## Readiness Gate Protocol
@@ -45,9 +50,10 @@ Sequence:
45
50
  2. `product-specialist` -- define user goals, user flows (Gherkin), acceptance criteria, error states, UX concerns, and out-of-scope items
46
51
  3. `architecture-specialist` -- assess technical feasibility, identify constraints, map existing system boundaries
47
52
  4. Synthesize findings into a PRD document containing: problem statement, user stories, acceptance criteria, technical constraints, open questions, and proposed scope
48
- 5. `learner` -- capture discoveries for future sessions
53
+ 5. **Plan Phase Tooling** -- review all available skills and agents (project-defined, plugin-provided, and built-in) and determine which ones the Plan phase will need. For each recommended skill or agent, state why it is needed. If no skills or agents beyond the defaults are identified, explicitly justify why the standard set is sufficient. Include this as a "Recommended Tooling for Plan Phase" section in the PRD.
54
+ 6. `learner` -- capture discoveries for future sessions
49
55
 
50
- Output: A PRD document. If there is not enough context to produce a complete PRD, stop and report what is missing rather than producing an incomplete one.
56
+ Output: A PRD document that includes a "Recommended Tooling for Plan Phase" section listing the skills and agents the Plan phase should use. If there is not enough context to produce a complete PRD, stop and report what is missing rather than producing an incomplete one.
51
57
 
52
58
  ### Plan
53
59
 
@@ -63,16 +69,17 @@ Sequence:
63
69
  1. **Investigate sub-flow** -- explore codebase for architecture, patterns, dependencies relevant to the spec
64
70
  2. `product-specialist` -- validate and refine acceptance criteria for the whole scope
65
71
  3. `architecture-specialist` -- map dependencies, identify cross-cutting concerns, determine execution order
66
- 4. Decompose into ordered work items (epics, stories, tasks, spikes, bugs), each with:
72
+ 4. **Implement/Verify Phase Tooling** -- review all available skills and agents (project-defined, plugin-provided, and built-in) and determine which ones the Implement and Verify phases will need for each work item. For each recommended skill or agent, state why it is needed and which work items it applies to. If no skills or agents beyond the defaults are identified for a work item, explicitly justify why the standard set is sufficient.
73
+ 5. Decompose into ordered work items (epics, stories, tasks, spikes, bugs), each with:
67
74
  - Type (epic, story, task, spike, bug)
68
75
  - Acceptance criteria
69
76
  - Verification method
70
77
  - Dependencies
71
- - Skills required
72
- 5. Create work items in the tracker (JIRA, Linear, GitHub) with acceptance criteria and dependencies
73
- 6. `learner` -- capture discoveries for future sessions
78
+ - Skills and agents required (from step 4)
79
+ 6. Create work items in the tracker (JIRA, Linear, GitHub) with acceptance criteria, dependencies, and recommended skills/agents
80
+ 7. `learner` -- capture discoveries for future sessions
74
81
 
75
- Output: Work items in a tracker with acceptance criteria, ordered by dependency. If the specification cannot be decomposed without further clarification, stop and report what is missing.
82
+ Output: Work items in a tracker with acceptance criteria and recommended skills/agents, ordered by dependency. If the specification cannot be decomposed without further clarification, stop and report what is missing.
76
83
 
77
84
  ### Implement
78
85
 
@@ -93,7 +100,7 @@ Determine the work type and execute the matching variant:
93
100
  3. `architecture-specialist` -- design approach, map files to modify, identify reusable code
94
101
  4. `test-specialist` -- design test strategy (coverage, edge cases, TDD sequence)
95
102
  5. `builder` -- implement via TDD (acceptance criteria become tests)
96
- 6. Run validation: lint, typecheck, tests
103
+ 6. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
97
104
  7. `verification-specialist` -- verify locally (run the software, observe behavior)
98
105
  8. Write e2e test encoding the verification
99
106
  9. **Review sub-flow**
@@ -107,7 +114,7 @@ Determine the work type and execute the matching variant:
107
114
  4. `architecture-specialist` -- assess fix risk, identify files to change, check for ripple effects
108
115
  5. `test-specialist` -- design regression test strategy
109
116
  6. `bug-fixer` -- implement fix via TDD (reproduction becomes failing test)
110
- 7. Run validation: lint, typecheck, tests
117
+ 7. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
111
118
  8. `verification-specialist` -- verify locally (prove the bug is fixed)
112
119
  9. Write e2e test encoding the verification
113
120
  10. **Review sub-flow**
@@ -119,7 +126,7 @@ Determine the work type and execute the matching variant:
119
126
  2. `architecture-specialist` -- identify target, plan approach
120
127
  3. `test-specialist` -- ensure existing test coverage before refactoring (safety net)
121
128
  4. `builder` -- implement improvements via TDD
122
- 5. Run validation: lint, typecheck, tests
129
+ 5. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
123
130
  6. `verification-specialist` -- measure again, prove improvement over baseline
124
131
  7. Write e2e test encoding the verification (if applicable)
125
132
  8. **Review sub-flow**
@@ -132,16 +139,16 @@ Determine the work type and execute the matching variant:
132
139
  3. Recommend next action (Research, Plan, Implement, or escalate)
133
140
  4. `learner` -- capture discoveries
134
141
 
135
- Output: Code passing all validation + local empirical verification + e2e test (except for spikes, which produce findings only).
142
+ Output: Code passing all quality gates + local empirical verification + e2e test (except for spikes, which produce findings only).
136
143
 
137
144
  ### Verify
138
145
 
139
- When: Code is ready to ship. All local validation passes. Moving from "works on my machine" to "works in production".
146
+ When: Code is ready to ship. All quality gates pass and local empirical verification is complete. Moving from "works on my machine" to "works in production".
140
147
 
141
148
  Gate:
142
- - Code must pass local validation (lint, typecheck, tests)
149
+ - Code must pass quality gates (lint, typecheck, tests)
143
150
  - Local empirical verification must be complete
144
- - If local validation fails, go back to **Implement**
151
+ - If quality gates fail, go back to **Implement**
145
152
  - If no code changes exist, there is nothing to verify
146
153
 
147
154
  Sequence:
package/plugins/lisa-cdk/.claude-plugin/plugin.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-cdk",
3
- "version": "1.81.7",
3
+ "version": "1.82.0",
4
4
  "description": "AWS CDK-specific plugin",
5
5
  "author": {
6
6
  "name": "Cody Swann"
package/plugins/lisa-expo/.claude-plugin/plugin.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-expo",
3
- "version": "1.81.7",
3
+ "version": "1.82.0",
4
4
  "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
5
5
  "author": {
6
6
  "name": "Cody Swann"
package/plugins/lisa-nestjs/.claude-plugin/plugin.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-nestjs",
3
- "version": "1.81.7",
3
+ "version": "1.82.0",
4
4
  "description": "NestJS-specific skills (GraphQL, TypeORM)",
5
5
  "author": {
6
6
  "name": "Cody Swann"
package/plugins/lisa-rails/.claude-plugin/plugin.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-rails",
3
- "version": "1.81.7",
3
+ "version": "1.82.0",
4
4
  "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
5
5
  "author": {
6
6
  "name": "Cody Swann"
package/plugins/lisa-typescript/.claude-plugin/plugin.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-typescript",
3
- "version": "1.81.7",
3
+ "version": "1.82.0",
4
4
  "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
5
5
  "author": {
6
6
  "name": "Cody Swann"
package/plugins/src/base/rules/intent-routing.md CHANGED
@@ -13,7 +13,12 @@ This protocol runs **once per session**, on the first user message. After that,
13
13
  3. If you cannot confidently classify the request:
14
14
  - **Interactive session** (user is present): present a multiple choice using AskUserQuestion with options: Research, Plan, Implement, Verify, No flow.
15
15
  - **Headless/non-interactive session** (running with `-p` flag, in a CI pipeline, or as a scheduled agent): do NOT ask the user. Classify to the best of your ability from available context (ticket content, prompt text, current branch state). If you truly cannot classify, default to "No flow" and proceed with the request as-is.
16
- 4. Once a flow is selected, state it explicitly (e.g., *"Flow: Implement/Fix"*) and check its readiness gate before proceeding.
16
+ 4. Once a flow is selected, **echo it back explicitly** before doing anything else. State the flow, the work type (if applicable), and a one-sentence justification for why this flow was chosen. Example:
17
+
18
+ > **Flow: Implement/Fix**
19
+ > This is a bug report with a specific error and reproduction steps, so it routes to the Fix work type within the Implement flow.
20
+
21
+ This echo is mandatory. Do not skip it, abbreviate it, or bury it in other output. The user must see the flow classification before any work begins.
17
22
  5. If you are a subagent: your parent agent has already determined the flow -- do NOT ask the user to choose a flow. Execute your assigned work within the established flow context.
18
23
 
19
24
  ## Readiness Gate Protocol
@@ -45,9 +50,10 @@ Sequence:
45
50
  2. `product-specialist` -- define user goals, user flows (Gherkin), acceptance criteria, error states, UX concerns, and out-of-scope items
46
51
  3. `architecture-specialist` -- assess technical feasibility, identify constraints, map existing system boundaries
47
52
  4. Synthesize findings into a PRD document containing: problem statement, user stories, acceptance criteria, technical constraints, open questions, and proposed scope
48
- 5. `learner` -- capture discoveries for future sessions
53
+ 5. **Plan Phase Tooling** -- review all available skills and agents (project-defined, plugin-provided, and built-in) and determine which ones the Plan phase will need. For each recommended skill or agent, state why it is needed. If no skills or agents beyond the defaults are identified, explicitly justify why the standard set is sufficient. Include this as a "Recommended Tooling for Plan Phase" section in the PRD.
54
+ 6. `learner` -- capture discoveries for future sessions
49
55
 
50
- Output: A PRD document. If there is not enough context to produce a complete PRD, stop and report what is missing rather than producing an incomplete one.
56
+ Output: A PRD document that includes a "Recommended Tooling for Plan Phase" section listing the skills and agents the Plan phase should use. If there is not enough context to produce a complete PRD, stop and report what is missing rather than producing an incomplete one.
51
57
 
52
58
  ### Plan
53
59
 
@@ -63,16 +69,17 @@ Sequence:
63
69
  1. **Investigate sub-flow** -- explore codebase for architecture, patterns, dependencies relevant to the spec
64
70
  2. `product-specialist` -- validate and refine acceptance criteria for the whole scope
65
71
  3. `architecture-specialist` -- map dependencies, identify cross-cutting concerns, determine execution order
66
- 4. Decompose into ordered work items (epics, stories, tasks, spikes, bugs), each with:
72
+ 4. **Implement/Verify Phase Tooling** -- review all available skills and agents (project-defined, plugin-provided, and built-in) and determine which ones the Implement and Verify phases will need for each work item. For each recommended skill or agent, state why it is needed and which work items it applies to. If no skills or agents beyond the defaults are identified for a work item, explicitly justify why the standard set is sufficient.
73
+ 5. Decompose into ordered work items (epics, stories, tasks, spikes, bugs), each with:
67
74
  - Type (epic, story, task, spike, bug)
68
75
  - Acceptance criteria
69
76
  - Verification method
70
77
  - Dependencies
71
- - Skills required
72
- 5. Create work items in the tracker (JIRA, Linear, GitHub) with acceptance criteria and dependencies
73
- 6. `learner` -- capture discoveries for future sessions
78
+ - Skills and agents required (from step 4)
79
+ 6. Create work items in the tracker (JIRA, Linear, GitHub) with acceptance criteria, dependencies, and recommended skills/agents
80
+ 7. `learner` -- capture discoveries for future sessions
74
81
 
75
- Output: Work items in a tracker with acceptance criteria, ordered by dependency. If the specification cannot be decomposed without further clarification, stop and report what is missing.
82
+ Output: Work items in a tracker with acceptance criteria and recommended skills/agents, ordered by dependency. If the specification cannot be decomposed without further clarification, stop and report what is missing.
76
83
 
77
84
  ### Implement
78
85
 
@@ -93,7 +100,7 @@ Determine the work type and execute the matching variant:
93
100
  3. `architecture-specialist` -- design approach, map files to modify, identify reusable code
94
101
  4. `test-specialist` -- design test strategy (coverage, edge cases, TDD sequence)
95
102
  5. `builder` -- implement via TDD (acceptance criteria become tests)
96
- 6. Run validation: lint, typecheck, tests
103
+ 6. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
97
104
  7. `verification-specialist` -- verify locally (run the software, observe behavior)
98
105
  8. Write e2e test encoding the verification
99
106
  9. **Review sub-flow**
@@ -107,7 +114,7 @@ Determine the work type and execute the matching variant:
107
114
  4. `architecture-specialist` -- assess fix risk, identify files to change, check for ripple effects
108
115
  5. `test-specialist` -- design regression test strategy
109
116
  6. `bug-fixer` -- implement fix via TDD (reproduction becomes failing test)
110
- 7. Run validation: lint, typecheck, tests
117
+ 7. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
111
118
  8. `verification-specialist` -- verify locally (prove the bug is fixed)
112
119
  9. Write e2e test encoding the verification
113
120
  10. **Review sub-flow**
@@ -119,7 +126,7 @@ Determine the work type and execute the matching variant:
119
126
  2. `architecture-specialist` -- identify target, plan approach
120
127
  3. `test-specialist` -- ensure existing test coverage before refactoring (safety net)
121
128
  4. `builder` -- implement improvements via TDD
122
- 5. Run validation: lint, typecheck, tests
129
+ 5. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
123
130
  6. `verification-specialist` -- measure again, prove improvement over baseline
124
131
  7. Write e2e test encoding the verification (if applicable)
125
132
  8. **Review sub-flow**
@@ -132,16 +139,16 @@ Determine the work type and execute the matching variant:
132
139
  3. Recommend next action (Research, Plan, Implement, or escalate)
133
140
  4. `learner` -- capture discoveries
134
141
 
135
- Output: Code passing all validation + local empirical verification + e2e test (except for spikes, which produce findings only).
142
+ Output: Code passing all quality gates + local empirical verification + e2e test (except for spikes, which produce findings only).
136
143
 
137
144
  ### Verify
138
145
 
139
- When: Code is ready to ship. All local validation passes. Moving from "works on my machine" to "works in production".
146
+ When: Code is ready to ship. All quality gates pass and local empirical verification is complete. Moving from "works on my machine" to "works in production".
140
147
 
141
148
  Gate:
142
- - Code must pass local validation (lint, typecheck, tests)
149
+ - Code must pass quality gates (lint, typecheck, tests)
143
150
  - Local empirical verification must be complete
144
- - If local validation fails, go back to **Implement**
151
+ - If quality gates fail, go back to **Implement**
145
152
  - If no code changes exist, there is nothing to verify
146
153
 
147
154
  Sequence: