@codyswann/lisa 1.86.3 → 1.87.0

package/package.json

@@ -78,7 +78,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "1.86.3",
+  "version": "1.87.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

package/plugins/lisa/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "1.86.3",
+  "version": "1.87.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/commands/build.md

@@ -5,6 +5,8 @@ argument-hint: "<description-or-ticket-id-or-url>"
 
 Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Implement** flow with the **Build** work type.
 
+**Orchestration: agent team.** Build runs a long multi-specialist sequence with parallel review. After echoing the flow and orchestration mode, your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.
+
 If the argument is a JIRA ticket ID or URL, hand off to the `jira-agent` which will read the ticket, extract context, and delegate back to the Implement flow.
 
 $ARGUMENTS

package/plugins/lisa/commands/fix.md

@@ -5,6 +5,8 @@ argument-hint: "<description-or-ticket-id-or-url>"
 
 Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Implement** flow with the **Fix** work type.
 
+**Orchestration: agent team.** Fix runs a long multi-specialist sequence with parallel review. After echoing the flow and orchestration mode, your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.
+
 If the argument is a JIRA ticket ID or URL, hand off to the `jira-agent` which will read the ticket, extract context, and delegate back to the Implement flow.
 
 $ARGUMENTS

package/plugins/lisa/commands/improve.md

@@ -5,6 +5,8 @@ argument-hint: "<target-description>"
 
 Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Implement** flow with the **Improve** work type.
 
+**Orchestration: agent team.** Improve runs a multi-specialist sequence with parallel review. After echoing the flow and orchestration mode, your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.
+
 For specific improvement types, you can also use:
 - `/lisa:plan:add-test-coverage` -- increase test coverage
 - `/lisa:plan:fix-linter-error` -- fix lint rule violations

package/plugins/lisa/commands/plan.md

@@ -5,6 +5,8 @@ argument-hint: "<description-or-ticket-id-or-url>"
 
 Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Plan** flow.
 
+**Orchestration: agent team.** Plan is a multi-specialist flow feeding a shared decomposition. After echoing the flow and orchestration mode, your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.
+
 If no PRD or specification exists, suggest running the **Research** flow first to produce one.
 
 If the argument is a JIRA ticket ID or URL, hand off to the `jira-agent` which will read the ticket and extract context.

package/plugins/lisa/commands/research.md

@@ -5,4 +5,6 @@ argument-hint: "<problem-statement-or-feature-idea>"
 
 Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Research** flow.
 
+**Orchestration: agent team.** Research is a multi-specialist flow feeding a shared PRD. After echoing the flow and orchestration mode, your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.
+
 $ARGUMENTS

package/plugins/lisa/rules/base-rules.md

@@ -2,6 +2,14 @@ Intent Routing (FIRST — before anything else):
 
 Before starting any work in a session, classify the user's initial request using the Intent Routing rule. Determine which flow applies (Research, Plan, Implement, Verify, or None) and check its readiness gate. Once a flow is established, all subsequent messages operate within it. Do not skip this step — even if the request seems simple. See the `intent-routing` rule for the full protocol.
 
+Orchestration Selection (SECOND — immediately after classifying the flow):
+
+After echoing the chosen flow and BEFORE doing any work, state the orchestration mode explicitly — either `Orchestration: agent team` or `Orchestration: single agent` — with a one-sentence justification. This echo is mandatory and must appear in the same message as the flow classification.
+
+Default to an agent team for Research, Plan, Implement (Build/Fix/Improve), and any flow that invokes the Review sub-flow. Use a single agent only for Verify (standalone), Monitor (standalone), and Investigate Only spikes. See the `intent-routing` rule's Orchestration section for the full decision matrix.
+
+When the mode is `agent team`, your FIRST tool call after the classification echo MUST be `TeamCreate`. Do not reach for `TaskCreate`, `Agent`, or direct tool calls before the team exists — those are bypass paths that skip durable task state and parallel review.
+
 Requirement Verification:
 
 Never assume the person providing instructions has given you complete, correct, or technically precise requirements. Treat every request as potentially underspecified. Before starting any work:

package/plugins/lisa/rules/intent-routing.md

@@ -21,6 +21,19 @@ This protocol runs **once per session**, on the first user message. After that,
    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.
 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.
 
+## Orchestration Selection Protocol
+
+Immediately after echoing the flow (and before any work begins), state the orchestration mode in the same message. The format is:
+
+> **Orchestration: agent team** (or **single agent**)
+> One-sentence justification.
+
+This echo is mandatory. The user must see the orchestration mode before any work begins. See the **Orchestration** section below for the full decision matrix and team-setup protocol.
+
+Quick rule: Research, Plan, Implement (Build/Fix/Improve), and any flow invoking the Review sub-flow → **agent team**. Verify standalone, Monitor standalone, Investigate Only spikes → **single agent**. When in doubt, use a team.
+
+If the mode is `agent team`, the first tool call after the echo MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or direct implementation tools before the team exists.
+
 ## Readiness Gate Protocol
 
 Every flow begins with a gate check. The gate defines what information must be present before the flow can begin.
@@ -46,6 +59,7 @@ Gate:
 - If none is provided, ask: "What problem are you trying to solve or what capability are you trying to add?"
 
 Sequence:
+0. **Create agent team via `TeamCreate`** (see Orchestration section) -- Research is a multi-specialist flow; do this before any other work.
 1. **Investigate sub-flow** -- gather context from codebase, git history, existing behavior, and external sources
 2. `product-specialist` -- define user goals, user flows (Gherkin), acceptance criteria, error states, UX concerns, and out-of-scope items
 3. `architecture-specialist` -- assess technical feasibility, identify constraints, map existing system boundaries
@@ -66,6 +80,7 @@ Gate:
 - If the specification has unresolved ambiguities, stop and list them
 
 Sequence:
+0. **Create agent team via `TeamCreate`** (see Orchestration section) -- Plan is a multi-specialist flow feeding a shared decomposition; do this before any other work.
 1. **Investigate sub-flow** -- explore codebase for architecture, patterns, dependencies relevant to the spec
 2. `product-specialist` -- validate and refine acceptance criteria for the whole scope
 3. `architecture-specialist` -- map dependencies, identify cross-cutting concerns, determine execution order
@@ -95,6 +110,7 @@ Determine the work type and execute the matching variant:
 
 #### Build (features, stories, tasks)
 
+0. **Create agent team via `TeamCreate`** (see Orchestration section) -- Build runs a long sequence with parallel review; do this before any other work.
 1. **Investigate sub-flow** -- explore codebase for related code, patterns, dependencies
 2. `product-specialist` -- define acceptance criteria, user flows, error states
 3. `architecture-specialist` -- design approach, map files to modify, identify reusable code
@@ -108,6 +124,7 @@ Determine the work type and execute the matching variant:
 
 #### Fix (bugs)
 
+0. **Create agent team via `TeamCreate`** (see Orchestration section) -- Fix runs a long sequence with parallel review; do this before any other work.
 1. **Reproduce sub-flow** -- write failing test or script that demonstrates the bug (MANDATORY before any fix is attempted)
 2. **Investigate sub-flow** -- git history, root cause analysis
 3. `debug-specialist` -- prove root cause with evidence
@@ -122,6 +139,7 @@ Determine the work type and execute the matching variant:
 
 #### Improve (refactoring, optimization, coverage improvement)
 
+0. **Create agent team via `TeamCreate`** (see Orchestration section) -- Improve runs a long sequence with parallel review; do this before any other work.
 1. **Investigate sub-flow** -- understand current state, measure baseline
 2. `architecture-specialist` -- identify target, plan approach
 3. `test-specialist` -- ensure existing test coverage before refactoring (safety net)

package/plugins/lisa-cdk/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "1.86.3",
+  "version": "1.87.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "1.86.3",
+  "version": "1.87.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "1.86.3",
+  "version": "1.87.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "1.86.3",
+  "version": "1.87.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "1.86.3",
+  "version": "1.87.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/commands/build.md

@@ -5,6 +5,8 @@ argument-hint: "<description-or-ticket-id-or-url>"
 
 Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Implement** flow with the **Build** work type.
 
+**Orchestration: agent team.** Build runs a long multi-specialist sequence with parallel review. After echoing the flow and orchestration mode, your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.
+
 If the argument is a JIRA ticket ID or URL, hand off to the `jira-agent` which will read the ticket, extract context, and delegate back to the Implement flow.
 
 $ARGUMENTS

package/plugins/src/base/commands/fix.md

@@ -5,6 +5,8 @@ argument-hint: "<description-or-ticket-id-or-url>"
 
 Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Implement** flow with the **Fix** work type.
 
+**Orchestration: agent team.** Fix runs a long multi-specialist sequence with parallel review. After echoing the flow and orchestration mode, your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.
+
 If the argument is a JIRA ticket ID or URL, hand off to the `jira-agent` which will read the ticket, extract context, and delegate back to the Implement flow.
 
 $ARGUMENTS

package/plugins/src/base/commands/improve.md

@@ -5,6 +5,8 @@ argument-hint: "<target-description>"
 
 Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Implement** flow with the **Improve** work type.
 
+**Orchestration: agent team.** Improve runs a multi-specialist sequence with parallel review. After echoing the flow and orchestration mode, your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.
+
 For specific improvement types, you can also use:
 - `/lisa:plan:add-test-coverage` -- increase test coverage
 - `/lisa:plan:fix-linter-error` -- fix lint rule violations

package/plugins/src/base/commands/plan.md

@@ -5,6 +5,8 @@ argument-hint: "<description-or-ticket-id-or-url>"
 
 Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Plan** flow.
 
+**Orchestration: agent team.** Plan is a multi-specialist flow feeding a shared decomposition. After echoing the flow and orchestration mode, your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.
+
 If no PRD or specification exists, suggest running the **Research** flow first to produce one.
 
 If the argument is a JIRA ticket ID or URL, hand off to the `jira-agent` which will read the ticket and extract context.

package/plugins/src/base/commands/research.md

@@ -5,4 +5,6 @@ argument-hint: "<problem-statement-or-feature-idea>"
 
 Apply the `intent-routing` rule (loaded via the lisa plugin) and execute the **Research** flow.
 
+**Orchestration: agent team.** Research is a multi-specialist flow feeding a shared PRD. After echoing the flow and orchestration mode, your FIRST tool call MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or implementation tools before the team exists.
+
 $ARGUMENTS

package/plugins/src/base/rules/base-rules.md

@@ -2,6 +2,14 @@ Intent Routing (FIRST — before anything else):
 
 Before starting any work in a session, classify the user's initial request using the Intent Routing rule. Determine which flow applies (Research, Plan, Implement, Verify, or None) and check its readiness gate. Once a flow is established, all subsequent messages operate within it. Do not skip this step — even if the request seems simple. See the `intent-routing` rule for the full protocol.
 
+Orchestration Selection (SECOND — immediately after classifying the flow):
+
+After echoing the chosen flow and BEFORE doing any work, state the orchestration mode explicitly — either `Orchestration: agent team` or `Orchestration: single agent` — with a one-sentence justification. This echo is mandatory and must appear in the same message as the flow classification.
+
+Default to an agent team for Research, Plan, Implement (Build/Fix/Improve), and any flow that invokes the Review sub-flow. Use a single agent only for Verify (standalone), Monitor (standalone), and Investigate Only spikes. See the `intent-routing` rule's Orchestration section for the full decision matrix.
+
+When the mode is `agent team`, your FIRST tool call after the classification echo MUST be `TeamCreate`. Do not reach for `TaskCreate`, `Agent`, or direct tool calls before the team exists — those are bypass paths that skip durable task state and parallel review.
+
 Requirement Verification:
 
 Never assume the person providing instructions has given you complete, correct, or technically precise requirements. Treat every request as potentially underspecified. Before starting any work:

package/plugins/src/base/rules/intent-routing.md

@@ -21,6 +21,19 @@ This protocol runs **once per session**, on the first user message. After that,
    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.
 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.
 
+## Orchestration Selection Protocol
+
+Immediately after echoing the flow (and before any work begins), state the orchestration mode in the same message. The format is:
+
+> **Orchestration: agent team** (or **single agent**)
+> One-sentence justification.
+
+This echo is mandatory. The user must see the orchestration mode before any work begins. See the **Orchestration** section below for the full decision matrix and team-setup protocol.
+
+Quick rule: Research, Plan, Implement (Build/Fix/Improve), and any flow invoking the Review sub-flow → **agent team**. Verify standalone, Monitor standalone, Investigate Only spikes → **single agent**. When in doubt, use a team.
+
+If the mode is `agent team`, the first tool call after the echo MUST be `TeamCreate`. Do not call `TaskCreate`, `Agent`, or direct implementation tools before the team exists.
+
 ## Readiness Gate Protocol
 
 Every flow begins with a gate check. The gate defines what information must be present before the flow can begin.
@@ -46,6 +59,7 @@ Gate:
 - If none is provided, ask: "What problem are you trying to solve or what capability are you trying to add?"
 
 Sequence:
+0. **Create agent team via `TeamCreate`** (see Orchestration section) -- Research is a multi-specialist flow; do this before any other work.
 1. **Investigate sub-flow** -- gather context from codebase, git history, existing behavior, and external sources
 2. `product-specialist` -- define user goals, user flows (Gherkin), acceptance criteria, error states, UX concerns, and out-of-scope items
 3. `architecture-specialist` -- assess technical feasibility, identify constraints, map existing system boundaries
@@ -66,6 +80,7 @@ Gate:
 - If the specification has unresolved ambiguities, stop and list them
 
 Sequence:
+0. **Create agent team via `TeamCreate`** (see Orchestration section) -- Plan is a multi-specialist flow feeding a shared decomposition; do this before any other work.
 1. **Investigate sub-flow** -- explore codebase for architecture, patterns, dependencies relevant to the spec
 2. `product-specialist` -- validate and refine acceptance criteria for the whole scope
 3. `architecture-specialist` -- map dependencies, identify cross-cutting concerns, determine execution order
@@ -95,6 +110,7 @@ Determine the work type and execute the matching variant:
 
 #### Build (features, stories, tasks)
 
+0. **Create agent team via `TeamCreate`** (see Orchestration section) -- Build runs a long sequence with parallel review; do this before any other work.
 1. **Investigate sub-flow** -- explore codebase for related code, patterns, dependencies
 2. `product-specialist` -- define acceptance criteria, user flows, error states
 3. `architecture-specialist` -- design approach, map files to modify, identify reusable code
@@ -108,6 +124,7 @@ Determine the work type and execute the matching variant:
 
 #### Fix (bugs)
 
+0. **Create agent team via `TeamCreate`** (see Orchestration section) -- Fix runs a long sequence with parallel review; do this before any other work.
 1. **Reproduce sub-flow** -- write failing test or script that demonstrates the bug (MANDATORY before any fix is attempted)
 2. **Investigate sub-flow** -- git history, root cause analysis
 3. `debug-specialist` -- prove root cause with evidence
@@ -122,6 +139,7 @@ Determine the work type and execute the matching variant:
 
 #### Improve (refactoring, optimization, coverage improvement)
 
+0. **Create agent team via `TeamCreate`** (see Orchestration section) -- Improve runs a long sequence with parallel review; do this before any other work.
 1. **Investigate sub-flow** -- understand current state, measure baseline
 2. `architecture-specialist` -- identify target, plan approach
 3. `test-specialist` -- ensure existing test coverage before refactoring (safety net)