@codyswann/lisa 1.80.0 → 1.81.0

package/plugins/lisa/rules/verification.md

@@ -90,4 +90,15 @@ Every change requires one or more verification types. Classify the change first,
 
 ---
 
+## Local vs Remote Verification
+
+Verification happens at two stages in the workflow:
+
+- **Local verification** (part of the Implement flow): Run the full test suite, typecheck, lint, and empirically verify the change in a local or preview environment. This proves the change works before shipping. After local verification succeeds, encode it as an e2e test.
+- **Remote verification** (part of the Verify flow): After the PR is merged and deployed, repeat the same empirical verification against the target environment. This proves the change works in production, not just locally. If remote verification fails, fix and re-deploy.
+
+Both levels use the same verification types table above. The difference is the environment, not the rigor.
+
+---
+
 For the full verification lifecycle (classify, check tooling, plan, execute, loop), surfaces, escalation protocol, and proof artifact requirements, see the `verification-lifecycle` skill loaded by the `verification-specialist` agent.

package/plugins/lisa/skills/plan-execute/SKILL.md

@@ -35,17 +35,28 @@ Using the general-purpose agent in Team Lead session, Determine what branch to u
 2. Are we on a feature branch without an open pull request? Use the branch, but ask the human what branch to target for the PR
 3. Are we on an environment branch (dev, staging, main, prod, production)? Check out a feature branch named for this plan and set the target branch of the PR to the environment branch
 
-Using the general-purpose agent in Team Lead session, Determine what type of request this is for:
-1. Informational/Spike
-2. Task
-3. Bug
-4. Feature/Story
-5. Epic
-
-IF it's a bug, Using the general-purpose agent in Team Lead session, determine how you will replicate the bug empirically:
-1. Examples:
+Using the general-purpose agent in Team Lead session, Determine which flow applies:
+1. Research -- needs a PRD (no specification exists)
+2. Plan -- needs decomposition (specification exists but no work items)
+3. Implement -- has a well-defined work item
+4. Verify -- has code ready to ship
+
+If Implement, determine the work type:
+1. Build (feature, story, task)
+2. Fix (bug -- mandatory Reproduce sub-flow before investigation)
+3. Improve (refactoring, optimization, coverage improvement)
+4. Investigate Only (spike -- no code changes, just findings)
+
+Run the readiness gate check for the selected flow as defined in `.claude/rules/intent-routing.md`. If the gate fails, stop and report what is missing.
+
+IF it is a Fix (bug), execute the Reproduce sub-flow FIRST:
+1. Write a failing test that demonstrates the bug (preferred)
+2. If a failing test is not possible, write a minimal reproduction script
+3. Verify the reproduction is reliable (consistent failure)
+4. The reproduction MUST succeed before any investigation or fix attempt begins
+5. Examples of reproduction methods:
    1. Write a simple API client and call the offending API
-   2. Start the server on localhost and Use the Playwright CLI or Chrome DevTools
+   2. Start the server on localhost and use the Playwright CLI or Chrome DevTools
 
 Using the general-purpose agent in Team Lead session, determine how you will know that the task is fully complete
 1. Examples
@@ -78,12 +89,18 @@ Before any task is implemented, the agent team must explore the codebase for rel
 Each task must be reviewed by the team to make sure their verification passes.
 Each task must have their learnings reviewed by the learner subagent.
 
-Before shutting down the team:
-
-1. Commit ALL outstanding changes in logical batches on the branch (minus sensitive data/information) — not just changes made by the agent team. This includes pre-existing uncommitted changes that were on the branch before the plan started. Do NOT filter commits to only "task-related" files. If it shows up in git status, it gets committed (unless it contains secrets).
-2. Push the changes - if any pre-push hook blocks you, create a task for the agent team to fix the error/problem whether it was pre-existing or not
-3. Open a pull request with auto-merge on
-4. Monitor the PR. Create a task for the agent team to resolve any code review comments by either implementing the suggestions or commenting why they should not be implemented and close the comment. Fix any failing checks and repush. Continue all checks pass
-5. Monitor the deploy action that triggers automatically from the successful merge
-6. If it fails, create a task for the agent team to fix the failure, open a new PR and then go back to step 4
-7. Execute empirical verification. If empirical verification succeeds, you're finished, otherwise, create a task for the agent team to find out why it failed, fix it and return to step 1 (repeat this until you get all the way through)
+Before shutting down the team, execute the Verify flow:
+
+1. Run local validation: lint, typecheck, tests — all must pass
+2. `verification-specialist`: verify locally (empirical proof that the change works)
+3. Write e2e test encoding the verification
+4. Commit ALL outstanding changes in logical batches on the branch (minus sensitive data/information) — not just changes made by the agent team. This includes pre-existing uncommitted changes that were on the branch before the plan started. Do NOT filter commits to only "task-related" files. If it shows up in git status, it gets committed (unless it contains secrets).
+5. Push the changes - if any pre-push hook blocks you, create a task for the agent team to fix the error/problem whether it was pre-existing or not
+6. Open a pull request with auto-merge on
+7. PR Watch Loop: Monitor the PR. Create a task for the agent team to resolve any code review comments by either implementing the suggestions or commenting why they should not be implemented and close the comment. Fix any failing checks and repush. Continue until all checks pass.
+8. Merge the PR
+9. Monitor the deploy action that triggers automatically from the successful merge
+10. If deploy fails, create a task for the agent team to fix the failure, open a new PR and then go back to step 7
+11. Remote verification: `verification-specialist` verifies in target environment (same checks as local verification, but on remote)
+12. `ops-specialist`: post-deploy health check, monitor for errors in first minutes
+13. If remote verification fails, create a task for the agent team to find out why it failed, fix it and return to step 4 (repeat until you get all the way through)

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "1.80.0",
+  "version": "1.81.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.80.0",
+  "version": "1.81.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.80.0",
+  "version": "1.81.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "1.80.0",
+  "version": "1.81.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.80.0",
+  "version": "1.81.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/.claude-plugin/plugin.json

@@ -5,21 +5,16 @@
   "author": { "name": "Cody Swann" },
   "hooks": {
     "UserPromptSubmit": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/enforce-plan-rules.sh"
-          }
-        ]
-      },
       {
         "matcher": "",
         "hooks": [
           {
             "type": "command",
             "command": "command -v entire >/dev/null 2>&1 && entire hooks claude-code user-prompt-submit || true"
+          },
+          {
+            "type": "prompt",
+            "prompt": "Classify this user request into exactly one flow. Output ONLY valid JSON.\n\nFlows:\n- Research: User needs requirements defined, wants a PRD, exploring a problem space, open-ended feature idea\n- Plan: User has requirements and wants them broken into tickets/work items\n- Implement/Build: User has a specific feature/story/task to code\n- Implement/Fix: User has a bug to fix, something is broken\n- Implement/Improve: User wants to refactor, optimize, or improve existing code\n- Implement/Investigate: User wants to understand why something works a certain way (spike)\n- Verify: User has code ready to ship (PR, deploy, merge)\n- None: Simple question, config change, one-off task, or not enough context to classify\n\nOutput format: {\"hookSpecificOutput\":{\"hookEventName\":\"UserPromptSubmit\",\"additionalContext\":\"Flow classification: [FLOW]. Reason: [one sentence].\"}}\n\nUser request: $ARGUMENTS"
           }
         ]
       }
@@ -63,7 +58,8 @@
       { "matcher": "", "hooks": [{ "type": "command", "command": "command -v entire >/dev/null 2>&1 && entire hooks claude-code session-start || true" }] }
     ],
     "SubagentStart": [
-      { "matcher": "", "hooks": [{ "type": "command", "command": "${CLAUDE_PLUGIN_ROOT}/hooks/inject-rules.sh" }] }
+      { "matcher": "", "hooks": [{ "type": "command", "command": "${CLAUDE_PLUGIN_ROOT}/hooks/inject-rules.sh" }] },
+      { "matcher": "", "hooks": [{ "type": "command", "command": "${CLAUDE_PLUGIN_ROOT}/hooks/inject-flow-context.sh" }] }
     ],
     "SessionEnd": [
       { "matcher": "", "hooks": [{ "type": "command", "command": "command -v entire >/dev/null 2>&1 && entire hooks claude-code session-end || true" }] }

package/plugins/src/base/agents/bug-fixer.md

@@ -14,7 +14,7 @@ You are a bug fix specialist. Your job is to turn a diagnosed bug into a verifie
 
 ## Prerequisites
 
-You receive a diagnosed bug from the Fix flow with:
+You receive a diagnosed bug from the **Implement** flow (Fix work type) with:
 - **Root cause** — what is causing the bug and where (file:line)
 - **Reproduction** — how to trigger the bug reliably
 - **Test strategy** — what regression tests to write (from `test-specialist`)

package/plugins/src/base/agents/builder.md

@@ -14,7 +14,7 @@ You are a feature build specialist. Your job is to turn acceptance criteria into
 
 ## Prerequisites
 
-You receive a task from the Build flow with:
+You receive a task from the **Implement** flow (Build or Improve work type) with:
 - **Acceptance criteria** — what the feature must do (from `product-specialist`)
 - **Architecture plan** — which files to create/modify, design decisions, reusable code (from `architecture-specialist`)
 - **Test strategy** — coverage targets, edge cases, TDD sequence (from `test-specialist`)

package/plugins/src/base/agents/jira-agent.md

@@ -1,6 +1,6 @@
 ---
 name: jira-agent
-description: JIRA lifecycle agent. Reads tickets, determines intent (Bug → Fix, Story/Task → Build, Epic → Plan), delegates to the appropriate flow, syncs progress at milestones, and posts evidence at completion.
+description: JIRA lifecycle agent. Reads tickets, determines intent (Bug → Implement/Fix, Story/Task → Implement/Build, Epic → Plan, Spike → Implement/Investigate), delegates to the appropriate flow, syncs progress at milestones, and posts evidence at completion.
 tools: Read, Grep, Glob, Bash
 skills:
   - jira-sync
@@ -55,15 +55,16 @@ If not triaged:
 
 Map the ticket type to a flow:
 
-| Ticket Type | Flow | Entry Agent |
-|-------------|------|-------------|
-| Bug | Fix | `git-history-analyzer` → `debug-specialist` → `bug-fixer` |
-| Story | Build | `product-specialist` → `architecture-specialist` → `builder` |
-| Task | Build | `product-specialist` → `architecture-specialist` → `builder` |
-| Epic | Plan | `product-specialist` → `architecture-specialist` → break down |
-| Spike | Investigate | `git-history-analyzer` → `debug-specialist` |
+| Ticket Type | Flow | Work Type |
+|-------------|------|-----------|
+| Epic | Plan | -- |
+| Story | Implement | Build |
+| Task | Implement | Build |
+| Bug | Implement | Fix |
+| Spike | Implement | Investigate Only |
+| Improvement | Implement | Improve |
 
-If the ticket type is ambiguous, read the description to classify. A "Task" that describes broken behavior is a Fix, not a Build.
+If the ticket type is ambiguous, read the description to classify. A "Task" that describes broken behavior is a Fix, not a Build. A "Bug" that requests new functionality is a Build.
 
 ### 5. Delegate to Flow
 

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

@@ -1,10 +1,10 @@
 ---
-description: "Build a feature. Defines acceptance criteria, researches codebase, implements via TDD, reviews, verifies, and ships."
+description: "Build a feature. Defines acceptance criteria, researches codebase, implements via TDD, verifies locally, and reviews."
 argument-hint: "<description-or-ticket-id-or-url>"
 ---
 
-Read `.claude/rules/intent-routing.md` and execute the **Build** flow.
+Read `.claude/rules/intent-routing.md` and execute the **Implement** flow with the **Build** work type.
 
-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 Build flow.
+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

@@ -1,10 +1,10 @@
 ---
-description: "Fix a bug. Analyzes git history, reproduces, finds root cause, implements fix via TDD, verifies, and ships."
+description: "Fix a bug. Reproduces, analyzes git history, finds root cause, implements fix via TDD, verifies locally, and reviews."
 argument-hint: "<description-or-ticket-id-or-url>"
 ---
 
-Read `.claude/rules/intent-routing.md` and execute the **Fix** flow.
+Read `.claude/rules/intent-routing.md` and execute the **Implement** flow with the **Fix** work type.
 
-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 Fix flow.
+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

@@ -1,16 +1,16 @@
 ---
-description: "Improve existing code. Identifies target, measures baseline, implements improvements via TDD, measures again, and ships."
+description: "Improve existing code. Measures baseline, implements improvements via TDD, measures again, and reviews."
 argument-hint: "<target-description>"
 ---
 
-Read `.claude/rules/intent-routing.md` and execute the **Improve** flow.
+Read `.claude/rules/intent-routing.md` and execute the **Implement** flow with the **Improve** work type.
 
 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
-- `/lisa:plan:lower-code-complexity` — reduce cognitive complexity
-- `/lisa:plan:reduce-max-lines` — reduce file length
-- `/lisa:plan:reduce-max-lines-per-function` — reduce function length
-- `/lisa:plan:improve-tests` — improve test quality
+- `/lisa:plan:add-test-coverage` -- increase test coverage
+- `/lisa:plan:fix-linter-error` -- fix lint rule violations
+- `/lisa:plan:lower-code-complexity` -- reduce cognitive complexity
+- `/lisa:plan:reduce-max-lines` -- reduce file length
+- `/lisa:plan:reduce-max-lines-per-function` -- reduce function length
+- `/lisa:plan:improve-tests` -- improve test quality
 
 $ARGUMENTS

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

@@ -3,7 +3,7 @@ description: "Investigate an issue. Analyzes git history, reproduces, traces exe
 argument-hint: "<description-or-ticket-id-or-url>"
 ---
 
-Read `.claude/rules/intent-routing.md` and execute the **Investigate** flow.
+Read `.claude/rules/intent-routing.md` and execute the **Implement** flow with the **Investigate Only** work type (spike).
 
 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/monitor.md

@@ -3,8 +3,8 @@ description: "Monitor application health. Checks health endpoints, logs, errors,
 argument-hint: "[environment]"
 ---
 
-Read `.claude/rules/intent-routing.md` and execute the **Monitor** flow.
+Read `.claude/rules/intent-routing.md` and execute the **Monitor** sub-flow.
 
-Delegates to `ops-specialist` for health checks, log inspection, error monitoring, and performance analysis.
+This sub-flow is also invoked as part of the Verify flow's remote verification step. Delegates to `ops-specialist` for health checks, log inspection, error monitoring, and performance analysis.
 
 $ARGUMENTS

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

@@ -3,4 +3,6 @@ description: "Creates an implementation plan from a ticket URL, file path, or te
 argument-hint: "<ticket-url | @file-path | description>"
 ---
 
-Read `.claude/rules/intent-routing.md` and execute the **Plan** flow on $ARGUMENTS
+Read `.claude/rules/intent-routing.md` and execute the **Plan** flow on $ARGUMENTS.
+
+If requirements are ambiguous or no specification exists, suggest running the **Research** flow first.

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

@@ -3,4 +3,4 @@ description: "Deploys an agent team to research, implement, review and deploy a
 argument-hint: "<ticket-url | @file-path | description>"
 ---
 
-Read `.claude/rules/intent-routing.md` and determine the appropriate flow for $ARGUMENTS. Execute the full flow including implementation, review, and ship sub-flows.
+Read `.claude/rules/intent-routing.md` and determine the appropriate flow for $ARGUMENTS. Execute the full flow including implementation, review, and verify flows.

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

@@ -1,10 +1,12 @@
 ---
-description: "Plan work. Defines acceptance criteria, researches codebase, maps dependencies, and breaks down into ordered tasks."
+description: "Plan work. Defines acceptance criteria, researches codebase, maps dependencies, and breaks down into ordered work items."
 argument-hint: "<description-or-ticket-id-or-url>"
 ---
 
 Read `.claude/rules/intent-routing.md` and execute the **Plan** flow.
 
+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.
 
 $ARGUMENTS

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

@@ -0,0 +1,8 @@
+---
+description: "Research a problem space and produce a PRD. Investigates codebase, defines user flows, assesses technical feasibility."
+argument-hint: "<problem-statement-or-feature-idea>"
+---
+
+Read `.claude/rules/intent-routing.md` and execute the **Research** flow.
+
+$ARGUMENTS

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

@@ -3,8 +3,8 @@ description: "Review code changes. Runs quality, security, performance, product,
 argument-hint: "[pr-link-or-branch]"
 ---
 
-Read `.claude/rules/intent-routing.md` and execute the **Review** flow.
+Read `.claude/rules/intent-routing.md` and execute the **Review** sub-flow.
 
-Runs `quality-specialist`, `security-specialist`, and `performance-specialist` in parallel, followed by `product-specialist` and `test-specialist`. Consolidates all findings ranked by severity.
+This sub-flow is also invoked automatically by the Implement flow. It runs `quality-specialist`, `security-specialist`, and `performance-specialist` in parallel, followed by `product-specialist` and `test-specialist`. Consolidates all findings ranked by severity.
 
 $ARGUMENTS

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

@@ -1,10 +1,8 @@
 ---
-description: "Ship current changes. Commits, opens PR, handles review feedback loop, deploys, verifies, and monitors."
+description: "Ship current changes. Alias for /verify."
 argument-hint: "[commit-message-hint]"
 ---
 
-Read `.claude/rules/intent-routing.md` and execute the **Ship** flow.
-
-This includes: atomic commits, PR creation, review-fix loop (fix failed checks, resolve merge conflicts, handle bot review feedback until mergeable), merge, deploy, post-deploy verification, and monitoring.
+Read `.claude/rules/intent-routing.md` and execute the **Verify** flow.
 
 $ARGUMENTS

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

@@ -0,0 +1,10 @@
+---
+description: "Ship and verify code. Commits, opens PR, handles review loop, merges, deploys, and verifies in target environment."
+argument-hint: "[commit-message-hint]"
+---
+
+Read `.claude/rules/intent-routing.md` and execute the **Verify** flow.
+
+This includes: atomic commits, PR creation, CI/review-fix loop, merge, deploy monitoring, and remote verification.
+
+$ARGUMENTS

package/plugins/src/base/hooks/inject-flow-context.sh

@@ -0,0 +1,12 @@
+#!/usr/bin/env bash
+# Tells subagents not to ask users for flow selection.
+# The parent agent has already determined the flow and work type.
+# Used by SubagentStart hook.
+set -euo pipefail
+
+jq -n '{
+  "hookSpecificOutput": {
+    "hookEventName": "SubagentStart",
+    "additionalContext": "You are a subagent operating within an established flow. Your parent agent has already determined the flow and work type. Do NOT ask the user to choose a flow or classify the request. Execute your assigned work within the context provided by your parent agent."
+  }
+}'

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

@@ -1,3 +1,7 @@
+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.
+
 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: