@codyswann/lisa 1.78.7 → 1.78.9

package/expo/create-only/.github/workflows/ci.yml

@@ -1,12 +1,13 @@
-# This file is managed by Lisa.
-# Do not edit directly — changes will be overwritten on the next `lisa` run.
-
 name: 🔍 CI Quality Checks
 
 on:
   pull_request:
   workflow_dispatch:
 
+concurrency:
+  group: ci-${{ github.event.pull_request.number || github.ref }}
+  cancel-in-progress: true
+
 jobs:
   quality:
     name: 🔍 Quality Checks

package/package.json

@@ -76,7 +76,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "1.78.7",
+  "version": "1.78.9",
   "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.78.7",
+  "version": "1.78.9",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

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

@@ -15,13 +15,26 @@ The caller provides pre-computed context:
 
 ## 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
+### Phase 1: Identify gaps
+
+1. 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
+2. Parse the coverage output to identify the specific files and lines with the lowest coverage. Prioritize files with the most uncovered lines/branches.
+3. Read ONE existing test file to learn the project's testing patterns (mocks, imports, assertions). Do not read more than one.
+
+### Phase 2: Write tests incrementally — one file at a time
+
+For each source file with low coverage (starting with the lowest):
+
+4. Read only the uncovered sections of the source file using the coverage report line numbers -- do not explore the codebase broadly
+5. Write a test file targeting the uncovered branches/lines for that source file
+6. Run the test file in isolation (e.g., `npx vitest run tests/my-new-test.test.ts`) to verify it passes before moving on
+7. If the test fails, fix it immediately. Do not move to the next file until the current test passes.
+8. Repeat steps 4-7 for the next source file. Stop once you estimate the proposed thresholds will be met.
+
+### Phase 3: Verify and ship
+
+9. Run the full coverage script to verify the new thresholds pass
+10. Update the thresholds file with the proposed new threshold values
+11. Re-run the coverage script to confirm the updated thresholds pass
+12. Commit all changes (new tests + updated thresholds file) with conventional commit messages
+13. 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

@@ -12,20 +12,18 @@ The caller provides:
 
 ## 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
+1. For each changed source file, find its corresponding test file(s)
+2. 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
+3. Improve the test files with the most impactful changes
+4. Run the full test suite to verify all tests pass
+5. Commit changes with conventional commit messages
+6. 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
+1. Scan the test files to find weak, brittle, or poorly-written tests
+2. Look for: missing edge cases, weak assertions (toBeTruthy instead of specific values), missing error path coverage, tests that test implementation rather than behavior
+3. Improve 3-5 test files with the most impactful changes
+4. Run the full test suite to verify all tests pass
+5. Commit changes with conventional commit messages
+6. Create a PR with `gh pr create` summarizing what was improved and why

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

@@ -14,16 +14,15 @@ The caller provides pre-computed context:
 
 ## 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. **Before editing**, check each violating file's total line count (`wc -l`). If a file is within 20 lines of its `max-lines` ESLint limit (typically 300), extract helpers into a **separate companion file** (e.g., `fooHelpers.ts`) instead of adding them to the same file. Extracting functions into the same file adds net lines and can create new max-lines violations.
-5. Fix violations one file at a time. Read only the specific function that violates — do not pre-read all files upfront. Fix it, then move to the next.
-6. For cognitive complexity violations: use early returns, extract helper functions, replace conditionals with lookup tables
-7. For max-lines-per-function violations: split large functions, extract helper functions, separate concerns
-8. After each file edit, run the project's formatter (e.g., `bun run format` or `npx prettier --write <file>`) to ensure line counts reflect the final formatted state before moving on
-9. Re-run the lint script with the provided package manager to verify all violations are resolved (both the target metric AND max-lines)
-10. Run the TypeScript compiler to catch type errors early: `npx tsc --noEmit 2>&1 | head -30`. If there are type errors, fix them now — do NOT wait until the commit step. Pre-commit hooks run type checking, and discovering errors at commit time wastes turns.
-11. 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
-12. Commit all changes (refactored code + updated eslint.thresholds.json) with conventional commit messages
-13. Create a PR with `gh pr create` with a title like "refactor: reduce code complexity: [metrics being reduced]" summarizing the changes
+1. Update eslint.thresholds.json with the proposed new threshold values (do NOT change the maxLines threshold)
+2. 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
+3. **Before editing**, check each violating file's total line count (`wc -l`). If a file is within 20 lines of its `max-lines` ESLint limit (typically 300), extract helpers into a **separate companion file** (e.g., `fooHelpers.ts`) instead of adding them to the same file. Extracting functions into the same file adds net lines and can create new max-lines violations.
+4. Fix violations one file at a time. Read only the specific function that violates — do not pre-read all files upfront. Fix it, then move to the next.
+5. For cognitive complexity violations: use early returns, extract helper functions, replace conditionals with lookup tables
+6. For max-lines-per-function violations: split large functions, extract helper functions, separate concerns
+7. After each file edit, run the project's formatter (e.g., `bun run format` or `npx prettier --write <file>`) to ensure line counts reflect the final formatted state before moving on
+8. Re-run the lint script with the provided package manager to verify all violations are resolved (both the target metric AND max-lines)
+9. Run the TypeScript compiler to catch type errors early: `npx tsc --noEmit 2>&1 | head -30`. If there are type errors, fix them now — do NOT wait until the commit step. Pre-commit hooks run type checking, and discovering errors at commit time wastes turns.
+10. 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
+11. Commit all changes (refactored code + updated eslint.thresholds.json) with conventional commit messages
+12. Create a PR with `gh pr create` with a title like "refactor: reduce code complexity: [metrics being reduced]" summarizing the changes

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

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

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

@@ -15,13 +15,26 @@ The caller provides pre-computed context:
 
 ## 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
+### Phase 1: Identify gaps
+
+1. 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
+2. Parse the coverage output to identify the specific files and lines with the lowest coverage. Prioritize files with the most uncovered lines/branches.
+3. Read ONE existing test file to learn the project's testing patterns (mocks, imports, assertions). Do not read more than one.
+
+### Phase 2: Write tests incrementally — one file at a time
+
+For each source file with low coverage (starting with the lowest):
+
+4. Read only the uncovered sections of the source file using the coverage report line numbers -- do not explore the codebase broadly
+5. Write a test file targeting the uncovered branches/lines for that source file
+6. Run the test file in isolation (e.g., `npx vitest run tests/my-new-test.test.ts`) to verify it passes before moving on
+7. If the test fails, fix it immediately. Do not move to the next file until the current test passes.
+8. Repeat steps 4-7 for the next source file. Stop once you estimate the proposed thresholds will be met.
+
+### Phase 3: Verify and ship
+
+9. Run the full coverage script to verify the new thresholds pass
+10. Update the thresholds file with the proposed new threshold values
+11. Re-run the coverage script to confirm the updated thresholds pass
+12. Commit all changes (new tests + updated thresholds file) with conventional commit messages
+13. 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

@@ -12,20 +12,18 @@ The caller provides:
 
 ## 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
+1. For each changed source file, find its corresponding test file(s)
+2. 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
+3. Improve the test files with the most impactful changes
+4. Run the full test suite to verify all tests pass
+5. Commit changes with conventional commit messages
+6. 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
+1. Scan the test files to find weak, brittle, or poorly-written tests
+2. Look for: missing edge cases, weak assertions (toBeTruthy instead of specific values), missing error path coverage, tests that test implementation rather than behavior
+3. Improve 3-5 test files with the most impactful changes
+4. Run the full test suite to verify all tests pass
+5. Commit changes with conventional commit messages
+6. Create a PR with `gh pr create` summarizing what was improved and why

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

@@ -14,16 +14,15 @@ The caller provides pre-computed context:
 
 ## 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. **Before editing**, check each violating file's total line count (`wc -l`). If a file is within 20 lines of its `max-lines` ESLint limit (typically 300), extract helpers into a **separate companion file** (e.g., `fooHelpers.ts`) instead of adding them to the same file. Extracting functions into the same file adds net lines and can create new max-lines violations.
-5. Fix violations one file at a time. Read only the specific function that violates — do not pre-read all files upfront. Fix it, then move to the next.
-6. For cognitive complexity violations: use early returns, extract helper functions, replace conditionals with lookup tables
-7. For max-lines-per-function violations: split large functions, extract helper functions, separate concerns
-8. After each file edit, run the project's formatter (e.g., `bun run format` or `npx prettier --write <file>`) to ensure line counts reflect the final formatted state before moving on
-9. Re-run the lint script with the provided package manager to verify all violations are resolved (both the target metric AND max-lines)
-10. Run the TypeScript compiler to catch type errors early: `npx tsc --noEmit 2>&1 | head -30`. If there are type errors, fix them now — do NOT wait until the commit step. Pre-commit hooks run type checking, and discovering errors at commit time wastes turns.
-11. 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
-12. Commit all changes (refactored code + updated eslint.thresholds.json) with conventional commit messages
-13. Create a PR with `gh pr create` with a title like "refactor: reduce code complexity: [metrics being reduced]" summarizing the changes
+1. Update eslint.thresholds.json with the proposed new threshold values (do NOT change the maxLines threshold)
+2. 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
+3. **Before editing**, check each violating file's total line count (`wc -l`). If a file is within 20 lines of its `max-lines` ESLint limit (typically 300), extract helpers into a **separate companion file** (e.g., `fooHelpers.ts`) instead of adding them to the same file. Extracting functions into the same file adds net lines and can create new max-lines violations.
+4. Fix violations one file at a time. Read only the specific function that violates — do not pre-read all files upfront. Fix it, then move to the next.
+5. For cognitive complexity violations: use early returns, extract helper functions, replace conditionals with lookup tables
+6. For max-lines-per-function violations: split large functions, extract helper functions, separate concerns
+7. After each file edit, run the project's formatter (e.g., `bun run format` or `npx prettier --write <file>`) to ensure line counts reflect the final formatted state before moving on
+8. Re-run the lint script with the provided package manager to verify all violations are resolved (both the target metric AND max-lines)
+9. Run the TypeScript compiler to catch type errors early: `npx tsc --noEmit 2>&1 | head -30`. If there are type errors, fix them now — do NOT wait until the commit step. Pre-commit hooks run type checking, and discovering errors at commit time wastes turns.
+10. 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
+11. Commit all changes (refactored code + updated eslint.thresholds.json) with conventional commit messages
+12. Create a PR with `gh pr create` with a title like "refactor: reduce code complexity: [metrics being reduced]" summarizing the changes