@codyswann/lisa 1.68.0 → 1.69.0

package/README.md

@@ -1,77 +1,72 @@
-# NPM
+# Lisa
 
-Developers write specs and answer questions. Agents implement, test, verify, question, and document.
+Lisa is a governance layer for AI-assisted software development. It ensures that AI agents — whether running on a developer's machine or in CI/CD — follow the same standards, workflows, and quality gates.
 
-## About This Project
+## What Lisa Does
 
-> Ask Claude: "What is the purpose of this project and how does it work?"
+### Intent Routing
 
-## Step 1: Install Claude Code
+When a request comes in (from a human, a JIRA ticket, or a scheduled job), Lisa classifies it and routes it to the appropriate **flow**. Flows are ordered sequences of specialized agents, each with a defined role.
 
-```bash
-brew install claude-code
-# Or: npm install -g @anthropic-ai/claude-code
-```
-
-## Step 2: Set Up This Project
-
-> Ask Claude: "I just cloned this repo. Walk me through the full setup including installing dependencies, environment variables, and any other configuration."
-
-## Step 3: Build and Test
+A request to fix a bug routes to a different flow than a request to build a feature or reduce code complexity. The routing is automatic based on context, but can be overridden explicitly via slash commands.
 
-> Ask Claude: "How do I build this package and run the tests?"
+### Flows and Agents
 
-## Step 4: Work on a Feature
+A flow is a pipeline. Each step in the pipeline is an **agent** — a scoped AI with specific tools and skills. One agent investigates git history, another reproduces bugs, another writes code, another verifies the result.
 
-> Ask Claude: "I have Jira ticket [TICKET-ID]. Research the codebase, create a plan, and implement it."
+Agents delegate domain-specific work to **skills** — reusable instruction sets that can be invoked by agents, by slash commands, or by CI workflows. The same skill that triages a JIRA ticket interactively is the same skill invoked by the nightly triage workflow.
 
-Or with utility commands:
+Flows can nest. A build flow includes a verification sub-flow, which includes a ship sub-flow. This composition keeps each flow focused while enabling complex end-to-end workflows.
 
-- `/plan:add-test-coverage` - Increase test coverage to a threshold
-- `/plan:fix-linter-error` - Fix ESLint rule violations
-- `/plan:local-code-review` - Review local branch changes
-- `/plan:lower-code-complexity` - Reduce cognitive complexity
-- `/plan:reduce-max-lines` - Reduce max file lines threshold
-- `/plan:reduce-max-lines-per-function` - Reduce max function lines
+### Quality Gates
 
-## Lisa Commands
+Lisa enforces quality through layered gates:
 
-> Ask Claude: "What Lisa commands are available, and how do I use them? Read HUMAN.md and give me a summary."
+- **Rules** are loaded into every AI session automatically. They define coding standards, architectural patterns, and behavioral expectations. The AI follows them because they're part of its context.
+- **Git hooks** are hard stops. Pre-commit hooks run linting, formatting, and type checking. Pre-push hooks run tests, coverage checks, security audits, and dead code detection. Nothing ships without passing.
+- **Claude hooks** bridge AI actions to project tooling — ensuring that when the AI commits, pushes, or creates a PR, the project's quality infrastructure runs.
 
-## Common Tasks
+### Location Agnostic
 
-### Code Review
+The same rules, skills, and quality gates apply everywhere:
 
-> Ask Claude: "Review the changes on this branch and suggest improvements."
+- On a developer's workstation running Claude Code interactively
+- In a GitHub Action running a nightly improvement job
+- In a CI workflow responding to a PR review comment
 
-### Submit a PR
+The analytical logic lives in skills. The enforcement lives in hooks and rules. The orchestration adapts to context — using MCP integrations locally and REST APIs in CI — but the standards don't change.
 
-> Ask Claude: "Commit my changes and open a pull request."
+### Template Governance
 
-### Fix Lint Errors
+Lisa distributes its standards to downstream projects as templates. When a project installs Lisa, it receives:
 
-> Ask Claude: "Run the linter and fix all errors."
+- Linting, formatting, and type checking configurations
+- Test and coverage infrastructure
+- CI/CD workflows
+- Git hooks
+- AI agent definitions, skills, and rules
 
-### Add Test Coverage
+Templates follow governance rules: some files are overwritten on every update (enforced standards), some are created once and left alone (project customization), and some are merged (shared defaults with project additions).
 
-> Ask Claude: "Increase test coverage for the files I changed."
+## Quick Start
 
-### Publish to npm
-
-> Ask Claude: "Walk me through publishing a new version of this package to npm."
-
-### Deploy
-
-> Ask Claude: "Walk me through deploying this project."
+```bash
+brew install claude-code
+```
 
-## Project Standards
+> Ask Claude: "I just cloned this repo. Walk me through setup."
 
-> Ask Claude: "What coding standards and conventions does this project follow?"
+## Working With Lisa
 
-## Architecture
+> Ask Claude: "I have JIRA ticket [TICKET-ID]. Research, plan, and implement it."
 
-> Ask Claude: "Explain the architecture of this project, including key components and how they interact."
+Or use slash commands directly:
 
-## Troubleshooting
+- `/fix` — route through the bug fix flow
+- `/build` — route through the feature build flow
+- `/improve` — route through the improvement flow
+- `/investigate` — route through the investigation flow
+- `/jira:triage <TICKET-ID>` — analytical triage gate: detect ambiguities, edge cases, and verification methodology
+- `/plan:improve-tests <target>` — improve test quality by analyzing and strengthening weak or brittle tests
 
-> Ask Claude: "I'm having an issue with [describe problem]. Help me debug it."
+> Ask Claude: "What commands are available?"

package/all/copy-overwrite/.claude/rules/intent-routing.md

@@ -94,6 +94,16 @@ Sequence:
 5. **Ship sub-flow**
 6. `learner` — capture discoveries
 
+#### Improve: Test Quality
+When: "Improve tests", "strengthen test suite", "fix weak tests", test quality improvement.
+
+Sequence:
+1. `test-specialist` — scan tests, identify weak/brittle tests, rank by improvement impact
+2. `builder` — implement test improvements
+3. **Verify sub-flow**
+4. **Ship sub-flow**
+5. `learner` — capture discoveries
+
 ### Monitor
 When: "Check the logs", "Any errors?", health checks, production monitoring.
 
@@ -106,9 +116,10 @@ Sequence:
 When the request references a JIRA ticket (ticket ID like PROJ-123 or a JIRA URL):
 
 1. Hand off to `jira-agent`
-2. `jira-agent` reads the ticket, validates quality, determines intent
-3. `jira-agent` delegates to the appropriate flow above
-4. `jira-agent` syncs progress at milestones and posts evidence at completion
+2. `jira-agent` reads the ticket, validates structural quality, and runs analytical triage
+3. If triage finds unresolved ambiguities, `jira-agent` posts findings and STOPS — no work begins
+4. `jira-agent` determines intent and delegates to the appropriate flow above
+5. `jira-agent` syncs progress at milestones and posts evidence at completion
 
 ## Sub-flow Usage
 

package/all/copy-overwrite/.claude/rules/security-audit-handling.md

@@ -0,0 +1,17 @@
+# Security Audit Handling
+
+If `git push` fails because the pre-push hook reports security vulnerabilities, follow these steps. Never use `--no-verify` to bypass the security audit.
+
+## Node.js Projects (GHSA advisories)
+
+1. Note the GHSA ID(s), affected package(s), and advisory URL from the error output
+2. Check the advisory URL to determine if a patched version of the vulnerable package exists
+3. If a patched version exists: add a resolution/override in package.json to force the patched version (add to both `resolutions` and `overrides` sections), then run the package manager install command to regenerate the lockfile, commit the changes, and retry the push
+4. If no patched version exists and the vulnerability is safe for this project (e.g., transitive dependency with no untrusted input, devDeps only, or build tool only): add an exclusion entry to `audit.ignore.local.json` with the format `{"id": "GHSA-xxx", "package": "pkg-name", "reason": "why this is safe for this project"}`, then commit and retry the push
+
+## Rails Projects (bundler-audit)
+
+1. Note the advisory ID, affected gem, and advisory URL from the error output
+2. Check if a patched version of the gem exists
+3. If a patched version exists: update the gem in Gemfile, run `bundle update <gem>`, commit the changes, and retry the push
+4. If no patched version exists and the vulnerability is safe for this project: document the exception and retry the push

package/package.json

@@ -74,7 +74,7 @@
     "flatted": "^3.4.2"
   },
   "name": "@codyswann/lisa",
-  "version": "1.68.0",
+  "version": "1.69.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.68.0",
+  "version": "1.69.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/agents/jira-agent.md

@@ -7,6 +7,7 @@ skills:
   - jira-evidence
   - jira-verify
   - jira-add-journey
+  - ticket-triage
 ---
 
 # JIRA Agent
@@ -33,7 +34,24 @@ Use the `jira-verify` skill to check:
 
 If validation fails, update the ticket with what's missing and escalate.
 
-### 3. Determine Intent
+### 3. Analytical Triage Gate
+
+Determine the repo name: `basename $(git rev-parse --show-toplevel)`
+
+Check if the ticket already has the `claude-triaged-{repo}` label. If yes, skip to Step 4.
+
+If not triaged:
+1. Fetch the full ticket details (summary, description, acceptance criteria, comments, labels)
+2. Invoke the `ticket-triage` skill with the ticket details in context
+3. Post the skill's findings (ambiguities, edge cases, verification methodology) as comments on the ticket using Atlassian MCP tools. Prefix all comments with `[{repo}]`.
+4. Add the `claude-triaged-{repo}` label to the ticket
+
+**Gating behavior:**
+- If the verdict is `BLOCKED` (ambiguities found): post the ambiguities, do NOT proceed to implementation. Report to the human: "This ticket has unresolved ambiguities. Triage posted findings as comments. Please resolve the ambiguities and retry."
+- If the verdict is `NOT_RELEVANT`: add the label and report "Ticket is not relevant to this repository."
+- If the verdict is `PASSED` or `PASSED_WITH_FINDINGS`: proceed to Step 4.
+
+### 4. Determine Intent
 
 Map the ticket type to a flow:
 
@@ -47,11 +65,11 @@ Map the ticket type to a flow:
 
 If the ticket type is ambiguous, read the description to classify. A "Task" that describes broken behavior is a Fix, not a Build.
 
-### 4. Delegate to Flow
+### 5. Delegate to Flow
 
 Hand off to the appropriate flow as defined in `.claude/rules/intent-routing.md`. Pass the full ticket context (description, acceptance criteria, credentials, reproduction steps) to the first agent in the flow.
 
-### 5. Sync Progress at Milestones
+### 6. Sync Progress at Milestones
 
 Use the `jira-sync` skill to update the ticket at these milestones:
 - **Plan created** — post plan summary, branch name
@@ -59,14 +77,14 @@ Use the `jira-sync` skill to update the ticket at these milestones:
 - **PR ready** — post PR link, summary of changes
 - **PR merged** — post final summary
 
-### 6. Post Evidence at Completion
+### 7. Post Evidence at Completion
 
 Use the `jira-evidence` skill to:
 - Upload verification evidence to the GitHub PR
 - Post evidence summary as a JIRA comment
 - Transition the ticket to Code Review
 
-### 7. Suggest Status Transition
+### 8. Suggest Status Transition
 
 Based on the milestone, suggest (but don't auto-transition):
 

package/plugins/lisa/commands/improve.md

@@ -11,5 +11,6 @@ For specific improvement types, you can also use:
 - `/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/lisa/commands/jira/triage.md

@@ -0,0 +1,7 @@
+---
+description: "Analytical triage of a JIRA ticket -- ambiguity detection, edge case analysis, verification methodology"
+allowed-tools: ["Skill"]
+argument-hint: "<TICKET-ID>"
+---
+
+Use the /lisa:ticket-triage skill to run analytical triage on the JIRA ticket. $ARGUMENTS

package/plugins/lisa/commands/plan/improve-tests.md

@@ -0,0 +1,7 @@
+---
+description: "Improve test quality by analyzing and strengthening weak, brittle, or poorly-written tests"
+allowed-tools: ["Skill"]
+argument-hint: "<target-description>"
+---
+
+Use the /lisa:plan-improve-tests skill to improve test quality. $ARGUMENTS

package/plugins/lisa/skills/nightly-add-test-coverage/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: nightly-add-test-coverage
+description: "Nightly direct-execution skill for increasing test coverage. Receives pre-computed threshold data, writes tests targeting coverage gaps, updates thresholds, commits, and creates a PR."
+allowed-tools: ["Edit", "MultiEdit", "Write", "Read", "Glob", "Grep", "Bash"]
+---
+
+# Nightly Test Coverage Improvement
+
+The caller provides pre-computed context:
+- **Package manager** (`npm`, `yarn`, or `bun`)
+- **Thresholds file** path (vitest.thresholds.json or jest.thresholds.json)
+- **Current thresholds** (statements, branches, functions, lines percentages)
+- **Proposed thresholds** (each metric increased by the coverage increment, capped at 90%)
+- **Metrics being bumped** (which metrics are below target)
+
+## Instructions
+
+1. Read CLAUDE.md and package.json for project conventions
+2. Run the project's coverage script with the provided package manager (e.g., `npm run test:cov`, `yarn test:cov`, or `bun run test:cov`) to get the coverage report -- identify gaps BEFORE reading any source files
+3. Parse the coverage output to identify the specific files and lines with the lowest coverage. Prioritize files with the most uncovered lines/branches.
+4. Read only the uncovered sections of source files using the coverage report line numbers -- do not explore the codebase broadly
+5. Write new tests to increase coverage enough to meet the proposed thresholds. Focus on the metrics being bumped -- write tests that cover untested branches, statements, functions, and lines.
+6. Re-run the coverage script with the provided package manager to verify the new thresholds pass
+7. Update the thresholds file with the proposed new threshold values
+8. Re-run the coverage script with the provided package manager to confirm the updated thresholds pass
+9. Commit all changes (new tests + updated thresholds file) with conventional commit messages
+10. Create a PR with `gh pr create` with a title like "test: increase test coverage: [metrics being bumped]" summarizing coverage improvements

package/plugins/lisa/skills/nightly-improve-tests/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: nightly-improve-tests
+description: "Nightly direct-execution skill for improving test quality. In nightly mode, focuses on tests for recently changed files. In general mode, scans all tests for the weakest ones. Commits and creates a PR."
+allowed-tools: ["Edit", "MultiEdit", "Write", "Read", "Glob", "Grep", "Bash"]
+---
+
+# Nightly Test Quality Improvement
+
+The caller provides:
+- **Mode**: "nightly" or "general"
+- **Changed files** (nightly mode only): list of source files changed in the last 24 hours
+
+## Nightly Mode
+
+1. Read CLAUDE.md and package.json for project conventions
+2. For each changed source file, find its corresponding test file(s)
+3. Analyze those test files for: missing edge cases, weak assertions (toBeTruthy instead of specific values), missing error path coverage, tests that test implementation rather than behavior
+4. Improve the test files with the most impactful changes
+5. Run the full test suite to verify all tests pass
+6. Commit changes with conventional commit messages
+7. Create a PR with `gh pr create` summarizing what was improved and why
+
+## General Mode
+
+1. Read CLAUDE.md and package.json for project conventions
+2. Scan the test files to find weak, brittle, or poorly-written tests
+3. Look for: missing edge cases, weak assertions (toBeTruthy instead of specific values), missing error path coverage, tests that test implementation rather than behavior
+4. Improve 3-5 test files with the most impactful changes
+5. Run the full test suite to verify all tests pass
+6. Commit changes with conventional commit messages
+7. Create a PR with `gh pr create` summarizing what was improved and why

package/plugins/lisa/skills/nightly-lower-code-complexity/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: nightly-lower-code-complexity
+description: "Nightly direct-execution skill for reducing code complexity thresholds. Receives pre-computed threshold data, refactors violations, updates thresholds, commits, and creates a PR."
+allowed-tools: ["Edit", "MultiEdit", "Write", "Read", "Glob", "Grep", "Bash"]
+---
+
+# Nightly Code Complexity Reduction
+
+The caller provides pre-computed context:
+- **Package manager** (`npm`, `yarn`, or `bun`)
+- **Current thresholds** (cognitiveComplexity, maxLinesPerFunction from eslint.thresholds.json)
+- **Proposed thresholds** (each metric decreased toward target minimums)
+- **Metrics being reduced** (which metrics are above target)
+
+## Instructions
+
+1. Read CLAUDE.md and package.json for project conventions
+2. Update eslint.thresholds.json with the proposed new threshold values (do NOT change the maxLines threshold)
+3. Run the project's lint script with the provided package manager (e.g., `npm run lint`, `yarn lint`, or `bun run lint`) to find functions that violate the new stricter thresholds
+4. For cognitive complexity violations: use early returns, extract helper functions, replace conditionals with lookup tables
+5. For max-lines-per-function violations: split large functions, extract helper functions, separate concerns
+6. Re-run the lint script with the provided package manager to verify all violations are resolved
+7. Run the project's test script with the provided package manager (e.g., `npm run test`, `yarn test`, or `bun run test`) to verify no tests are broken by the refactoring
+8. Commit all changes (refactored code + updated eslint.thresholds.json) with conventional commit messages
+9. Create a PR with `gh pr create` with a title like "refactor: reduce code complexity: [metrics being reduced]" summarizing the changes

package/plugins/lisa/skills/plan-improve-tests/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: plan-improve-tests
+description: This skill should be used when improving test quality. It scans the test suite for weak, brittle, or poorly-written tests, generates a brief with improvement opportunities, and creates a plan with tasks to strengthen the tests.
+allowed-tools: ["Read", "Bash", "Glob", "Grep"]
+---
+
+# Improve Test Quality
+
+Target: $ARGUMENTS
+
+If no argument provided, scan the full test suite.
+
+## Step 1: Gather Requirements
+
+1. **Run test suite** to establish baseline:
+   ```bash
+   bun run test 2>&1 | tail -20
+   ```
+2. **Scan test files** for quality issues:
+   - Weak assertions (`toBeTruthy`, `toBeDefined` instead of specific values)
+   - Missing edge cases (no boundary values, no error paths)
+   - Implementation coupling (testing internals rather than behavior)
+   - Missing error path coverage
+   - Duplicated setup that could indicate missing abstractions
+3. **Identify 10-20 test files** with highest improvement potential, noting:
+   - File path
+   - Issues found (weak assertions, missing edge cases, etc.)
+   - Estimated impact of improvement
+
+## Step 2: Compile Brief and Delegate
+
+Compile the gathered information into a structured brief:
+
+```text
+Improve test quality across the test suite.
+
+Test files needing improvement (ordered by impact):
+1. [test file] - [issues found]
+   - Weak assertions: [count]
+   - Missing edge cases: [description]
+   - Implementation coupling: [description]
+2. ...
+
+Verification: `bun run test` -> Expected: All tests pass, improved assertions and coverage
+```
+
+Invoke `/plan-execute` with this brief to create the implementation plan.

package/plugins/lisa/skills/ticket-triage/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: ticket-triage
+description: "Analytical triage gate for JIRA tickets. Detects requirement ambiguities, identifies edge cases from codebase analysis, and plans verification methodology. Posts findings to the ticket and produces a verdict (BLOCKED/PASSED_WITH_FINDINGS/PASSED) that gates whether implementation can proceed."
+allowed-tools: ["Read", "Glob", "Grep", "Bash"]
+---
+
+# Ticket Triage: $ARGUMENTS
+
+Perform analytical triage on the JIRA ticket. The caller has fetched the ticket details (summary, description, acceptance criteria, labels, status, comments) and provided them in context.
+
+Repository name for scoped labels and comment headers: determine via `basename $(git rev-parse --show-toplevel)`.
+
+## Phase 1 -- Relevance Check
+
+Search the local codebase using Glob and Grep for code related to the ticket's subject matter:
+- Keywords from summary and description
+- Component names, API endpoints, database tables
+- Error messages or log strings mentioned in the ticket
+
+If NO relevant code is found in this repo:
+- Output: `## Verdict: NOT_RELEVANT`
+- Instruct caller to add the label `claude-triaged-{repo}` and skip this ticket
+
+If relevant code IS found, proceed to Phase 2.
+
+## Phase 2 -- Cross-Repo Awareness
+
+Parse the ticket's existing comments for triage headers from OTHER repositories. Look for patterns like:
+- `*[some-repo-name] Ambiguity detected*`
+- `*[some-repo-name] Edge cases*`
+- `*[some-repo-name] Verification methodology*`
+
+Note which phases other repos have already covered and what findings they posted. In subsequent phases:
+- Do NOT duplicate findings already posted by another repo
+- DO add supplementary findings specific to THIS repo's codebase
+
+## Phase 3 -- Ambiguity Detection
+
+Examine the ticket summary, description, and acceptance criteria. Look for:
+
+| Signal | Example |
+|--------|---------|
+| Vague language | "should work properly", "handle edge cases", "improve performance" |
+| Untestable criteria | No measurable outcome defined |
+| Undefined terms | Acronyms or domain terms not explained in context |
+| Missing scope boundaries | What's included vs excluded is unclear |
+| Implicit assumptions | Assumptions not stated explicitly |
+
+Skip ambiguities already raised by another repo's triage comments.
+
+For each NEW ambiguity found, produce:
+
+```text
+### Ambiguity: [short title]
+**Description:** [what is ambiguous]
+**Suggested clarification:** [specific question to resolve it]
+```
+
+Be specific -- every ambiguity must have a concrete clarifying question.
+
+## Phase 4 -- Edge Case Analysis
+
+Search the codebase using Glob and Grep for files related to the ticket's subject matter. Check git history for recent changes in those areas:
+
+```bash
+git log --oneline -20 -- <relevant-paths>
+```
+
+Identify:
+- Boundary conditions (empty inputs, max values, concurrent access)
+- Error handling gaps in related code
+- Integration risks with other components
+- Data migration or backward compatibility concerns
+
+Reference only files in THIS repo. Acknowledge edge cases from other repos if relevant, but do not duplicate them.
+
+For each edge case, produce:
+
+```text
+### Edge Case: [title]
+**Description:** [what could go wrong]
+**Code reference:** [file path and relevant lines or patterns]
+```
+
+Every edge case must reference specific code files or patterns found in the codebase. If no relevant code exists, note that this appears to be a new feature with no existing code to analyze.
+
+## Phase 5 -- Verification Methodology
+
+For each acceptance criterion, specify a concrete verification method scoped to what THIS repo can test:
+
+| Verification Type | When to Use | What to Specify |
+|-------------------|-------------|-----------------|
+| UI | Change affects user-visible interface | Playwright test description with specific assertions |
+| API | Change affects HTTP/GraphQL/RPC endpoints | curl command with expected response status and body |
+| Data | Change involves schema, migrations, queries | Database query or service call to verify state |
+| Performance | Change claims performance improvement | Benchmark description with target metrics |
+
+Do not duplicate verification methods already posted by other repos.
+
+Produce a table:
+
+```text
+| Acceptance Criterion | Verification Method | Type |
+|---------------------|--------------------| -----|
+```
+
+Every verification method must be specific enough that an automated agent could execute it.
+
+## Phase 6 -- Verdict
+
+Evaluate the findings and produce exactly one verdict:
+
+- **`NOT_RELEVANT`** -- No relevant code was found in this repository (Phase 1). The caller should add the triage label and skip implementation in this repo.
+- **`BLOCKED`** -- Ambiguities were found in Phase 3. Work MUST NOT proceed until the ambiguities are resolved by a human. The caller should post findings, add the triage label, and STOP.
+- **`PASSED_WITH_FINDINGS`** -- No ambiguities, but edge cases or verification findings were identified. Work can proceed. The caller should post findings and add the triage label.
+- **`PASSED`** -- No ambiguities, edge cases, or verification gaps found. Work can proceed. The caller should add the triage label.
+
+Output format:
+
+```text
+## Verdict: [NOT_RELEVANT | BLOCKED | PASSED_WITH_FINDINGS | PASSED]
+
+**Ambiguities found:** [count]
+**Edge cases identified:** [count]
+**Verification methods defined:** [count]
+```
+
+## Output Structure
+
+Structure all output with clear section headers so the caller can parse and post findings:
+
+```text
+## Triage: [TICKET-KEY] ([repo-name])
+
+### Ambiguities
+[Phase 3 findings, or "None found."]
+
+### Edge Cases
+[Phase 4 findings, or "None found."]
+
+### Verification Methodology
+[Phase 5 table, or "No acceptance criteria to verify."]
+
+## Verdict: [NOT_RELEVANT | BLOCKED | PASSED_WITH_FINDINGS | PASSED]
+```
+
+The caller is responsible for:
+1. Posting the findings as comments on the ticket (using whatever Jira mechanism is available)
+2. Adding the `claude-triaged-{repo}` label to the ticket
+3. If `BLOCKED`: stopping all work and reporting the ambiguities to the human

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "1.68.0",
+  "version": "1.69.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.68.0",
+  "version": "1.69.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.68.0",
+  "version": "1.69.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.68.0",
+  "version": "1.69.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.68.0",
+  "version": "1.69.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -7,6 +7,7 @@ skills:
   - jira-evidence
   - jira-verify
   - jira-add-journey
+  - ticket-triage
 ---
 
 # JIRA Agent
@@ -33,7 +34,24 @@ Use the `jira-verify` skill to check:
 
 If validation fails, update the ticket with what's missing and escalate.
 
-### 3. Determine Intent
+### 3. Analytical Triage Gate
+
+Determine the repo name: `basename $(git rev-parse --show-toplevel)`
+
+Check if the ticket already has the `claude-triaged-{repo}` label. If yes, skip to Step 4.
+
+If not triaged:
+1. Fetch the full ticket details (summary, description, acceptance criteria, comments, labels)
+2. Invoke the `ticket-triage` skill with the ticket details in context
+3. Post the skill's findings (ambiguities, edge cases, verification methodology) as comments on the ticket using Atlassian MCP tools. Prefix all comments with `[{repo}]`.
+4. Add the `claude-triaged-{repo}` label to the ticket
+
+**Gating behavior:**
+- If the verdict is `BLOCKED` (ambiguities found): post the ambiguities, do NOT proceed to implementation. Report to the human: "This ticket has unresolved ambiguities. Triage posted findings as comments. Please resolve the ambiguities and retry."
+- If the verdict is `NOT_RELEVANT`: add the label and report "Ticket is not relevant to this repository."
+- If the verdict is `PASSED` or `PASSED_WITH_FINDINGS`: proceed to Step 4.
+
+### 4. Determine Intent
 
 Map the ticket type to a flow:
 
@@ -47,11 +65,11 @@ Map the ticket type to a flow:
 
 If the ticket type is ambiguous, read the description to classify. A "Task" that describes broken behavior is a Fix, not a Build.
 
-### 4. Delegate to Flow
+### 5. Delegate to Flow
 
 Hand off to the appropriate flow as defined in `.claude/rules/intent-routing.md`. Pass the full ticket context (description, acceptance criteria, credentials, reproduction steps) to the first agent in the flow.
 
-### 5. Sync Progress at Milestones
+### 6. Sync Progress at Milestones
 
 Use the `jira-sync` skill to update the ticket at these milestones:
 - **Plan created** — post plan summary, branch name
@@ -59,14 +77,14 @@ Use the `jira-sync` skill to update the ticket at these milestones:
 - **PR ready** — post PR link, summary of changes
 - **PR merged** — post final summary
 
-### 6. Post Evidence at Completion
+### 7. Post Evidence at Completion
 
 Use the `jira-evidence` skill to:
 - Upload verification evidence to the GitHub PR
 - Post evidence summary as a JIRA comment
 - Transition the ticket to Code Review
 
-### 7. Suggest Status Transition
+### 8. Suggest Status Transition
 
 Based on the milestone, suggest (but don't auto-transition):
 

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

@@ -11,5 +11,6 @@ For specific improvement types, you can also use:
 - `/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/jira/triage.md

@@ -0,0 +1,7 @@
+---
+description: "Analytical triage of a JIRA ticket -- ambiguity detection, edge case analysis, verification methodology"
+allowed-tools: ["Skill"]
+argument-hint: "<TICKET-ID>"
+---
+
+Use the /lisa:ticket-triage skill to run analytical triage on the JIRA ticket. $ARGUMENTS

package/plugins/src/base/commands/plan/improve-tests.md

@@ -0,0 +1,7 @@
+---
+description: "Improve test quality by analyzing and strengthening weak, brittle, or poorly-written tests"
+allowed-tools: ["Skill"]
+argument-hint: "<target-description>"
+---
+
+Use the /lisa:plan-improve-tests skill to improve test quality. $ARGUMENTS

package/plugins/src/base/skills/nightly-add-test-coverage/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: nightly-add-test-coverage
+description: "Nightly direct-execution skill for increasing test coverage. Receives pre-computed threshold data, writes tests targeting coverage gaps, updates thresholds, commits, and creates a PR."
+allowed-tools: ["Edit", "MultiEdit", "Write", "Read", "Glob", "Grep", "Bash"]
+---
+
+# Nightly Test Coverage Improvement
+
+The caller provides pre-computed context:
+- **Package manager** (`npm`, `yarn`, or `bun`)
+- **Thresholds file** path (vitest.thresholds.json or jest.thresholds.json)
+- **Current thresholds** (statements, branches, functions, lines percentages)
+- **Proposed thresholds** (each metric increased by the coverage increment, capped at 90%)
+- **Metrics being bumped** (which metrics are below target)
+
+## Instructions
+
+1. Read CLAUDE.md and package.json for project conventions
+2. Run the project's coverage script with the provided package manager (e.g., `npm run test:cov`, `yarn test:cov`, or `bun run test:cov`) to get the coverage report -- identify gaps BEFORE reading any source files
+3. Parse the coverage output to identify the specific files and lines with the lowest coverage. Prioritize files with the most uncovered lines/branches.
+4. Read only the uncovered sections of source files using the coverage report line numbers -- do not explore the codebase broadly
+5. Write new tests to increase coverage enough to meet the proposed thresholds. Focus on the metrics being bumped -- write tests that cover untested branches, statements, functions, and lines.
+6. Re-run the coverage script with the provided package manager to verify the new thresholds pass
+7. Update the thresholds file with the proposed new threshold values
+8. Re-run the coverage script with the provided package manager to confirm the updated thresholds pass
+9. Commit all changes (new tests + updated thresholds file) with conventional commit messages
+10. Create a PR with `gh pr create` with a title like "test: increase test coverage: [metrics being bumped]" summarizing coverage improvements

package/plugins/src/base/skills/nightly-improve-tests/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: nightly-improve-tests
+description: "Nightly direct-execution skill for improving test quality. In nightly mode, focuses on tests for recently changed files. In general mode, scans all tests for the weakest ones. Commits and creates a PR."
+allowed-tools: ["Edit", "MultiEdit", "Write", "Read", "Glob", "Grep", "Bash"]
+---
+
+# Nightly Test Quality Improvement
+
+The caller provides:
+- **Mode**: "nightly" or "general"
+- **Changed files** (nightly mode only): list of source files changed in the last 24 hours
+
+## Nightly Mode
+
+1. Read CLAUDE.md and package.json for project conventions
+2. For each changed source file, find its corresponding test file(s)
+3. Analyze those test files for: missing edge cases, weak assertions (toBeTruthy instead of specific values), missing error path coverage, tests that test implementation rather than behavior
+4. Improve the test files with the most impactful changes
+5. Run the full test suite to verify all tests pass
+6. Commit changes with conventional commit messages
+7. Create a PR with `gh pr create` summarizing what was improved and why
+
+## General Mode
+
+1. Read CLAUDE.md and package.json for project conventions
+2. Scan the test files to find weak, brittle, or poorly-written tests
+3. Look for: missing edge cases, weak assertions (toBeTruthy instead of specific values), missing error path coverage, tests that test implementation rather than behavior
+4. Improve 3-5 test files with the most impactful changes
+5. Run the full test suite to verify all tests pass
+6. Commit changes with conventional commit messages
+7. Create a PR with `gh pr create` summarizing what was improved and why

package/plugins/src/base/skills/nightly-lower-code-complexity/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: nightly-lower-code-complexity
+description: "Nightly direct-execution skill for reducing code complexity thresholds. Receives pre-computed threshold data, refactors violations, updates thresholds, commits, and creates a PR."
+allowed-tools: ["Edit", "MultiEdit", "Write", "Read", "Glob", "Grep", "Bash"]
+---
+
+# Nightly Code Complexity Reduction
+
+The caller provides pre-computed context:
+- **Package manager** (`npm`, `yarn`, or `bun`)
+- **Current thresholds** (cognitiveComplexity, maxLinesPerFunction from eslint.thresholds.json)
+- **Proposed thresholds** (each metric decreased toward target minimums)
+- **Metrics being reduced** (which metrics are above target)
+
+## Instructions
+
+1. Read CLAUDE.md and package.json for project conventions
+2. Update eslint.thresholds.json with the proposed new threshold values (do NOT change the maxLines threshold)
+3. Run the project's lint script with the provided package manager (e.g., `npm run lint`, `yarn lint`, or `bun run lint`) to find functions that violate the new stricter thresholds
+4. For cognitive complexity violations: use early returns, extract helper functions, replace conditionals with lookup tables
+5. For max-lines-per-function violations: split large functions, extract helper functions, separate concerns
+6. Re-run the lint script with the provided package manager to verify all violations are resolved
+7. Run the project's test script with the provided package manager (e.g., `npm run test`, `yarn test`, or `bun run test`) to verify no tests are broken by the refactoring
+8. Commit all changes (refactored code + updated eslint.thresholds.json) with conventional commit messages
+9. Create a PR with `gh pr create` with a title like "refactor: reduce code complexity: [metrics being reduced]" summarizing the changes

package/plugins/src/base/skills/plan-improve-tests/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: plan-improve-tests
+description: This skill should be used when improving test quality. It scans the test suite for weak, brittle, or poorly-written tests, generates a brief with improvement opportunities, and creates a plan with tasks to strengthen the tests.
+allowed-tools: ["Read", "Bash", "Glob", "Grep"]
+---
+
+# Improve Test Quality
+
+Target: $ARGUMENTS
+
+If no argument provided, scan the full test suite.
+
+## Step 1: Gather Requirements
+
+1. **Run test suite** to establish baseline:
+   ```bash
+   bun run test 2>&1 | tail -20
+   ```
+2. **Scan test files** for quality issues:
+   - Weak assertions (`toBeTruthy`, `toBeDefined` instead of specific values)
+   - Missing edge cases (no boundary values, no error paths)
+   - Implementation coupling (testing internals rather than behavior)
+   - Missing error path coverage
+   - Duplicated setup that could indicate missing abstractions
+3. **Identify 10-20 test files** with highest improvement potential, noting:
+   - File path
+   - Issues found (weak assertions, missing edge cases, etc.)
+   - Estimated impact of improvement
+
+## Step 2: Compile Brief and Delegate
+
+Compile the gathered information into a structured brief:
+
+```text
+Improve test quality across the test suite.
+
+Test files needing improvement (ordered by impact):
+1. [test file] - [issues found]
+   - Weak assertions: [count]
+   - Missing edge cases: [description]
+   - Implementation coupling: [description]
+2. ...
+
+Verification: `bun run test` -> Expected: All tests pass, improved assertions and coverage
+```
+
+Invoke `/plan-execute` with this brief to create the implementation plan.

package/plugins/src/base/skills/ticket-triage/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: ticket-triage
+description: "Analytical triage gate for JIRA tickets. Detects requirement ambiguities, identifies edge cases from codebase analysis, and plans verification methodology. Posts findings to the ticket and produces a verdict (BLOCKED/PASSED_WITH_FINDINGS/PASSED) that gates whether implementation can proceed."
+allowed-tools: ["Read", "Glob", "Grep", "Bash"]
+---
+
+# Ticket Triage: $ARGUMENTS
+
+Perform analytical triage on the JIRA ticket. The caller has fetched the ticket details (summary, description, acceptance criteria, labels, status, comments) and provided them in context.
+
+Repository name for scoped labels and comment headers: determine via `basename $(git rev-parse --show-toplevel)`.
+
+## Phase 1 -- Relevance Check
+
+Search the local codebase using Glob and Grep for code related to the ticket's subject matter:
+- Keywords from summary and description
+- Component names, API endpoints, database tables
+- Error messages or log strings mentioned in the ticket
+
+If NO relevant code is found in this repo:
+- Output: `## Verdict: NOT_RELEVANT`
+- Instruct caller to add the label `claude-triaged-{repo}` and skip this ticket
+
+If relevant code IS found, proceed to Phase 2.
+
+## Phase 2 -- Cross-Repo Awareness
+
+Parse the ticket's existing comments for triage headers from OTHER repositories. Look for patterns like:
+- `*[some-repo-name] Ambiguity detected*`
+- `*[some-repo-name] Edge cases*`
+- `*[some-repo-name] Verification methodology*`
+
+Note which phases other repos have already covered and what findings they posted. In subsequent phases:
+- Do NOT duplicate findings already posted by another repo
+- DO add supplementary findings specific to THIS repo's codebase
+
+## Phase 3 -- Ambiguity Detection
+
+Examine the ticket summary, description, and acceptance criteria. Look for:
+
+| Signal | Example |
+|--------|---------|
+| Vague language | "should work properly", "handle edge cases", "improve performance" |
+| Untestable criteria | No measurable outcome defined |
+| Undefined terms | Acronyms or domain terms not explained in context |
+| Missing scope boundaries | What's included vs excluded is unclear |
+| Implicit assumptions | Assumptions not stated explicitly |
+
+Skip ambiguities already raised by another repo's triage comments.
+
+For each NEW ambiguity found, produce:
+
+```text
+### Ambiguity: [short title]
+**Description:** [what is ambiguous]
+**Suggested clarification:** [specific question to resolve it]
+```
+
+Be specific -- every ambiguity must have a concrete clarifying question.
+
+## Phase 4 -- Edge Case Analysis
+
+Search the codebase using Glob and Grep for files related to the ticket's subject matter. Check git history for recent changes in those areas:
+
+```bash
+git log --oneline -20 -- <relevant-paths>
+```
+
+Identify:
+- Boundary conditions (empty inputs, max values, concurrent access)
+- Error handling gaps in related code
+- Integration risks with other components
+- Data migration or backward compatibility concerns
+
+Reference only files in THIS repo. Acknowledge edge cases from other repos if relevant, but do not duplicate them.
+
+For each edge case, produce:
+
+```text
+### Edge Case: [title]
+**Description:** [what could go wrong]
+**Code reference:** [file path and relevant lines or patterns]
+```
+
+Every edge case must reference specific code files or patterns found in the codebase. If no relevant code exists, note that this appears to be a new feature with no existing code to analyze.
+
+## Phase 5 -- Verification Methodology
+
+For each acceptance criterion, specify a concrete verification method scoped to what THIS repo can test:
+
+| Verification Type | When to Use | What to Specify |
+|-------------------|-------------|-----------------|
+| UI | Change affects user-visible interface | Playwright test description with specific assertions |
+| API | Change affects HTTP/GraphQL/RPC endpoints | curl command with expected response status and body |
+| Data | Change involves schema, migrations, queries | Database query or service call to verify state |
+| Performance | Change claims performance improvement | Benchmark description with target metrics |
+
+Do not duplicate verification methods already posted by other repos.
+
+Produce a table:
+
+```text
+| Acceptance Criterion | Verification Method | Type |
+|---------------------|--------------------| -----|
+```
+
+Every verification method must be specific enough that an automated agent could execute it.
+
+## Phase 6 -- Verdict
+
+Evaluate the findings and produce exactly one verdict:
+
+- **`NOT_RELEVANT`** -- No relevant code was found in this repository (Phase 1). The caller should add the triage label and skip implementation in this repo.
+- **`BLOCKED`** -- Ambiguities were found in Phase 3. Work MUST NOT proceed until the ambiguities are resolved by a human. The caller should post findings, add the triage label, and STOP.
+- **`PASSED_WITH_FINDINGS`** -- No ambiguities, but edge cases or verification findings were identified. Work can proceed. The caller should post findings and add the triage label.
+- **`PASSED`** -- No ambiguities, edge cases, or verification gaps found. Work can proceed. The caller should add the triage label.
+
+Output format:
+
+```text
+## Verdict: [NOT_RELEVANT | BLOCKED | PASSED_WITH_FINDINGS | PASSED]
+
+**Ambiguities found:** [count]
+**Edge cases identified:** [count]
+**Verification methods defined:** [count]
+```
+
+## Output Structure
+
+Structure all output with clear section headers so the caller can parse and post findings:
+
+```text
+## Triage: [TICKET-KEY] ([repo-name])
+
+### Ambiguities
+[Phase 3 findings, or "None found."]
+
+### Edge Cases
+[Phase 4 findings, or "None found."]
+
+### Verification Methodology
+[Phase 5 table, or "No acceptance criteria to verify."]
+
+## Verdict: [NOT_RELEVANT | BLOCKED | PASSED_WITH_FINDINGS | PASSED]
+```
+
+The caller is responsible for:
+1. Posting the findings as comments on the ticket (using whatever Jira mechanism is available)
+2. Adding the `claude-triaged-{repo}` label to the ticket
+3. If `BLOCKED`: stopping all work and reporting the ambiguities to the human