@codyswann/lisa 1.27.0 → 1.28.0

package/all/copy-overwrite/.claude/skills/plan-add-test-coverage/SKILL.md

@@ -2,7 +2,6 @@
 name: plan-add-test-coverage
 description: This skill should be used when increasing test coverage to a specified threshold percentage. It runs the coverage report, identifies files with the lowest coverage, generates a brief with coverage gaps, and creates a plan with tasks to add the missing tests.
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
-argument-hint: "<threshold-percentage>"
 
 ---
 
@@ -24,31 +23,22 @@ If no argument provided, prompt the user for a target.
    - Current coverage % (lines, branches, functions)
    - Which lines/branches are uncovered
 
-## Step 2: Create Plan
+## Step 2: Compile Brief and Delegate
 
-In plan mode, create a plan that includes the following details:
+Compile the gathered information into a structured brief:
 
-```markdown
+```
 Increase test coverage from [current]% to $ARGUMENTS%.
 
-## Files Needing Coverage (ordered by coverage gap)
-
-1. src/services/user.ts - 23% coverage (target: $ARGUMENTS%)
-   - Uncovered: lines 45-67, 89-102
-   - Missing branch coverage: lines 34, 56
-2. src/utils/helpers.ts - 34% coverage (target: $ARGUMENTS%)
-   - Uncovered: lines 12-45
-...
+Files needing coverage (ordered by coverage gap):
+1. [file] - [current]% coverage (target: $ARGUMENTS%)
+   - Uncovered: [lines]
+   - Missing branch coverage: [lines]
+2. ...
 
-## Configuration
-- Config file: [path to coverage config]
-- Update thresholds to $ARGUMENTS% for: lines, branches, functions, statements
+Configuration: [config file path], update thresholds to $ARGUMENTS%
 
-## Acceptance Criteria
-- All files meet $ARGUMENTS% coverage threshold
-- `bun run test:cov` passes with no threshold violations
-
-## Verification
-Command: `bun run test:cov`
-Expected: All thresholds pass at $ARGUMENTS%
+Verification: `bun run test:cov` → Expected: All thresholds pass at $ARGUMENTS%
 ```
+
+Invoke `/plan-create` with this brief to create the implementation plan.

package/all/copy-overwrite/.claude/skills/plan-create/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: plan-create
+description: "Creates an implementation plan from a ticket URL, file path, or text description. Spawns an Agent Team for parallel research, review, and synthesis. Detects plan type (Bug/Task/Story/Epic) and applies type-specific requirements."
+---
+
+# Create Implementation Plan
+
+Create an implementation plan for: $ARGUMENTS
+
+## Step 1: Parse Input
+
+Determine the input type from `$ARGUMENTS`:
+
+1. **Ticket URL/ID** — For when the argument references a JIRA, Github or Linear issue/ticket number or url
+   - Fetch ticket details with the appropriate CLI or MCP Server
+   - Extract: title, description, acceptance criteria, priority, epic/parent
+   - Note the ticket URL for continuous integration updates
+
+2. **File path** — If the the arguments reference a file:
+   - Read the file contents
+   - Use the file as context for the plan
+
+3. **Free text** — Otherwise, treat the entire argument as a text description of the work
+
+If no argument provided, prompt the user for input.
+
+## Step 2: Detect Plan Type
+
+Analyze the input to determine the plan type:
+
+| Type | Indicators |
+|------|------------|
+| **Bug** | Describes symptoms, errors, incorrect behavior, "broken", "fails", "crash", "regression" |
+| **Story/Feature** | Describes new capability, user-facing change, "add", "implement", "create", "as a user" |
+| **Task** | Describes internal work, refactoring, configuration, maintenance, "update", "migrate", "refactor" |
+| **Epic** | Describes large scope with multiple features/stories, "overhaul", "redesign", multiple distinct deliverables |
+
+If the type is ambiguous, default to **Task**.
+
+## Step 3: Spawn Research Team
+
+Create an Agent Team to research the work in parallel. The team lead operates in **delegate mode** (coordination only, no direct implementation). All teammates are spawned in **plan mode** so the team lead can review their findings before synthesis.
+
+### Phase 1: Research (parallel)
+
+Spawn these three teammates simultaneously:
+
+#### Ticket/Task Researcher
+- **Name**: `researcher`
+- **Agent type**: `general-purpose`
+- **Mode**: `plan`
+- **Prompt**: Research the input (ticket, file, or description). If a ticket URL, fetch full details via JIRA MCP or GitHub CLI. If a bug, attempt to reproduce it empirically (Playwright, browser, direct API call, etc.). Extract requirements, acceptance criteria, and context.
+
+#### Codebase Explorer
+- **Name**: `explorer`
+- **Agent type**: `Explore`
+- **Mode**: `plan`
+- **Prompt**: Explore the codebase for relevant code, existing patterns, and reusable scripts. Read lint and format rules to understand project standards. Identify files that would need modification, existing utilities that can be reused, and architecture constraints. Check for existing scripts in `package.json` that could be used for replication or verification.
+
+#### Devil's Advocate
+- **Name**: `devils-advocate`
+- **Agent type**: `general-purpose`
+- **Mode**: `plan`
+- **Prompt**: Review the input from a critical perspective. Identify anti-patterns, N+1 queries, missing edge cases, security concerns, and performance issues. Do not assume anti-patterns are acceptable just because they exist in the codebase — undocumented anti-patterns should be flagged, not used as reference.
+
+### Phase 2: Review (parallel, after Phase 1 findings are synthesized)
+
+After collecting and synthesizing Phase 1 findings into a draft plan, spawn these two reviewers simultaneously:
+
+#### Tech Reviewer
+- **Name**: `tech-reviewer`
+- **Agent type**: `tech-reviewer`
+- **Mode**: `plan`
+- **Prompt**: Review the draft plan for correctness, security, and coding-philosophy compliance. Validate the proposed approach, identify technical risks, and confirm the implementation strategy is sound. Flag any issues ranked by severity.
+
+#### Product Reviewer
+- **Name**: `product-reviewer`
+- **Agent type**: `product-reviewer`
+- **Mode**: `plan`
+- **Prompt**: Review the draft plan from a non-technical/UX perspective. Does the plan solve the right problem? Will the proposed solution work for end users? Are there user-facing concerns the technical team may have missed?
+
+### Bug-Specific Rules
+
+If the plan type is **Bug**:
+
+- The bug **must** be empirically replicated (Playwright, browser, direct API call, etc.) — not guessed at
+- If the research team cannot reproduce the bug, **STOP**. Update the ticket with findings and what additional information is needed, then end the session
+- Do not attempt to fix a bug you cannot prove exists
+- Never include solutions with obvious anti-patterns (e.g., N+1 queries). If unavoidable due to API limitations, **STOP** and update the ticket with what is needed
+
+## Step 4: Synthesize & Write Plan
+
+After all teammates have reported and the team lead has approved their findings:
+
+1. Synthesize findings into a unified plan and save it
+2. The plan must include, at minimum, the info found in the @.claude/rules/plan.md rule
+
+### Plan Structure
+
+The plan file must include, at minimum:
+
+1. **Title and context** — What is being done and why
+2. **Input source** — Ticket URL, file path, or description
+3. **Plan type** — Bug, Task, Story/Feature, or Epic
+4. **Branch and PR** — Following branch/PR rules from @.claude/rules/plan.md
+5. **Analysis** — Synthesized research findings from all teammates
+6. **Implementation approach** — How the work will be done
+7. **Tasks** — Following the Task Creation Specification from @.claude/rules/plan.md
+8. **Implementation Team** — Instructions to spawn a second Agent Team (see Step 6)
+
+### Type-Specific Requirements
+
+Apply these additional requirements based on the detected type:
+
+#### Bug
+- **Replication step** (mandatory): Include a task to reproduce the bug empirically before any fix
+- **Root cause analysis**: Identify why the bug occurs, not just what triggers it
+- **Regression test**: Write a test that fails without the fix and passes with it
+- **Verification**: Run the replication step again after the fix to confirm resolution
+- **Proof command**: Every fix task must include a proof command and expected output
+
+#### Story/Feature
+- **UX review**: Include a product-reviewer agent task to validate from user perspective
+- **Feature flag consideration**: Note whether this should be behind a feature flag
+- **Documentation**: Include user-facing documentation if applicable
+
+#### Task
+- **Standard implementation** with empirical verification
+
+#### Epic
+- **Decompose into sub-tasks**: Break into Stories, Tasks, and/or Bugs
+- **Each sub-task gets its own type-specific requirements**
+- **Dependency mapping**: Identify which sub-tasks depend on others
+
+## Step 5: Include Required Tasks
+
+Include all required tasks defined in the @.claude/rules/plan.md rule (Required Tasks section), including the archive task which must always be last.
+
+## Step 6: Implementation Team Instructions
+
+The plan must include instructions to spawn a **second Agent Team** for implementation. Recommend these specialized agents:
+
+| Agent | Use For |
+|-------|---------|
+| `implementer` | Code implementation (pre-loaded with project conventions) |
+| `tech-reviewer` | Technical review (correctness, security, performance) |
+| `product-reviewer` | Product/UX review (validates from non-technical perspective) |
+| `learner` | Post-implementation learning (processes learnings into skills/rules) |
+| `test-coverage-agent` | Writing comprehensive tests |
+| `code-simplifier` | Code simplification and refinement |
+| `coderabbit` | Automated AI code review |
+
+The **team lead** handles git operations (commits, pushes, PR management) — teammates focus on their specialized work.
+
+## Step 7: Ticket Integration
+
+If the input was a ticket ID or URL:
+
+1. Include the ticket URL in the plan metadata
+2. Associate the branch and PR with the ticket
+3. Post the approved plan as a comment on the ticket
+4. Use `/jira-sync` at key milestones
+5. If blocked (cannot reproduce, unavoidable anti-pattern, missing information, etc.), update the ticket before stopping
+
+## Step 8: Present to User
+
+Present the synthesized plan to the user for review. The user should be able to:
+
+- Approve the plan as-is
+- Request modifications
+- Reject the plan
+
+All decisions in the plan must include a recommendation. If a decision is left unresolved, use the recommended option.

package/all/copy-overwrite/.claude/skills/plan-fix-linter-error/SKILL.md

@@ -2,7 +2,6 @@
 name: plan-fix-linter-error
 description: This skill should be used when fixing all violations of one or more ESLint rules across the codebase. It runs the linter, groups violations by rule and file, generates a brief with fix strategies, and creates a plan with tasks to implement the fixes.
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
-argument-hint: "<rule-1> [rule-2] [rule-3] ..."
 
 ---
 
@@ -24,40 +23,23 @@ If no arguments provided, prompt the user for at least one lint rule name.
    - Violation count per file
    - Sample error messages
 
-## Step 2: Create Plan
+## Step 2: Compile Brief and Delegate
 
-In plan mode, create a plan that includes the following details:
+Compile the gathered information into a structured brief:
 
-```markdown
+```
 Fix ESLint violations for rules: $ARGUMENTS
 
-## Violations by Rule
-
-### [rule-name-1] (X total violations across Y files)
-
-1. src/services/user.ts (5 violations)
-   - Line 23: [error message]
-   - Line 45: [error message]
-   - Line 67: [error message]
-   ...
-2. src/utils/helpers.ts (3 violations)
-   - Line 12: [error message]
-   ...
+Violations by rule:
+- [rule-name-1]: X total violations across Y files
+  - [file]: N violations (lines: ...)
+  - ...
+- [rule-name-2]: X total violations across Y files
+  - ...
 
-### [rule-name-2] (X total violations across Y files)
-...
+Fix strategies: extract functions, early returns, apply formatting, add types
 
-## Fix Strategies
-- **Complexity rules** (sonarjs/*): Extract functions, early returns, simplify conditions
-- **Style rules** (prettier/*, import/order): Apply formatting fixes
-- **Best practice rules** (react-hooks/*, prefer-const): Refactor to recommended pattern
-- **Type rules** (@typescript-eslint/*): Add proper types, remove `any`
-
-## Acceptance Criteria
-- `bun run lint` passes with zero violations for: $ARGUMENTS
-- Each rule's fixes committed separately: `fix(lint): resolve [rule-name] violations`
-
-## Verification
-Command: `bun run lint 2>&1 | grep -E "($ARGUMENTS)" | wc -l`
-Expected: 0
+Verification: `bun run lint 2>&1 | grep -E "($ARGUMENTS)" | wc -l` → Expected: 0
 ```
+
+Invoke `/plan-create` with this brief to create the implementation plan.

package/all/copy-overwrite/.claude/skills/plan-implement/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: plan-implement
+description: "Implements an existing plan file by reading its tasks and executing them. Spawns an Agent Team with specialized agents for parallel implementation."
+---
+
+# Implement Plan
+
+Implement the requirements in $ARGUMENTS.
+
+If no argument provided, search for plan files in the `plans/` directory and present them to the user for selection.
+
+## Workflow
+
+1. **Read the plan file** specified in `$ARGUMENTS`
+2. **Parse all tasks** from the plan, including their dependencies, descriptions, and verification requirements
+3. **Create tasks** using TaskCreate for each task in the plan
+4. **Set up dependencies** between tasks using TaskUpdate (addBlockedBy/addBlocks)
+5. **Spawn an Agent Team** with specialized agents to execute tasks in parallel where dependencies allow
+6. **Execute tasks** following the plan's specified order and dependency graph
+7. **Verify each task** using its verification metadata before marking complete
+8. **Commit changes** after implementation using conventional commit format
+
+## Agent Team Composition
+
+Use the specialized agents listed in the `plan.md` rule (Implementation Team Guidance section). The **team lead** handles git operations (commits, pushes, PR management) -- teammates focus on their specialized work.
+
+## Execution
+
+Read the plan and begin implementation now.

package/all/copy-overwrite/.claude/skills/plan-lower-code-complexity/SKILL.md

@@ -23,36 +23,22 @@ Reduces the cognitive complexity threshold by 2 and fixes all violations.
 
 If no violations at new threshold, report success and exit.
 
-## Step 2: Create Plan
+## Step 2: Compile Brief and Delegate
 
-In plan mode, create a plan that includes the following details:
+Compile the gathered information into a structured brief:
 
-```markdown
+```
 Reduce cognitive complexity threshold from [current] to [new].
 
-## Functions Exceeding Threshold (ordered by complexity)
+Functions exceeding threshold (ordered by complexity):
+1. [file:function] (complexity: X, target: [new]) - Line Y
+2. ...
 
-1. src/services/user.ts:processUser (complexity: 18, target: [new])
-   - Line 45, function spans lines 45-120
-2. src/utils/helpers.ts:validateInput (complexity: 15, target: [new])
-   - Line 23, function spans lines 23-67
-...
+Configuration change: [eslint config path], cognitive-complexity from [current] to [new]
 
-## Configuration Change
-- File: [eslint config path]
-- Change: cognitive-complexity threshold from [current] to [new]
+Refactoring strategies: extract functions, early returns, extract conditions, use lookup tables
 
-## Refactoring Strategies
-- **Extract functions**: Break complex logic into smaller, named functions
-- **Early returns**: Reduce nesting with guard clauses
-- **Extract conditions**: Move complex boolean logic into named variables
-- **Use lookup tables**: Replace complex switch/if-else chains with object maps
+Verification: `bun run lint 2>&1 | grep "cognitive-complexity" | wc -l` → Expected: 0
+```
 
-## Acceptance Criteria
-- All functions at or below complexity [new]
-- `bun run lint` passes with no cognitive-complexity violations
-
-## Verification
-Command: `bun run lint 2>&1 | grep "cognitive-complexity" | wc -l`
-Expected: 0
-```
+Invoke `/plan-create` with this brief to create the implementation plan.

package/all/copy-overwrite/.claude/skills/plan-reduce-max-lines/SKILL.md

@@ -2,7 +2,6 @@
 name: plan-reduce-max-lines
 description: This skill should be used when reducing the maximum file lines threshold and fixing all violations. It updates the eslint threshold configuration, identifies files exceeding the new limit, generates a brief with refactoring strategies, and creates a plan with tasks to split oversized files.
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
-argument-hint: "<max-lines-value>"
 
 ---
 
@@ -25,35 +24,22 @@ If no argument provided, prompt the user for a target.
 
 If no violations at $ARGUMENTS, report success and exit.
 
-## Step 2: Create Plan
+## Step 2: Compile Brief and Delegate
 
-In plan mode, create a plan that includes the following details:
+Compile the gathered information into a structured brief:
 
-```markdown
+```
 Reduce max file lines threshold to $ARGUMENTS.
 
-## Files Exceeding Threshold (ordered by line count)
-
-1. src/services/user.ts (450 lines, target: $ARGUMENTS)
-2. src/utils/helpers.ts (380 lines, target: $ARGUMENTS)
-3. src/components/Dashboard.tsx (320 lines, target: $ARGUMENTS)
-...
+Files exceeding threshold (ordered by line count):
+1. [file] - [current] lines (target: $ARGUMENTS)
+2. ...
 
-## Configuration Change
-- File: eslint.thresholds.json
-- Change: maxLines to $ARGUMENTS
+Configuration change: eslint.thresholds.json, maxLines to $ARGUMENTS
 
-## Refactoring Strategies
-- **Extract modules**: Break file into smaller focused modules
-- **Remove duplication**: Consolidate repeated logic
-- **Delete dead code**: Remove unused functions/code paths
-- **Simplify logic**: Use early returns, reduce nesting
+Refactoring strategies: extract modules, remove duplication, delete dead code, simplify logic
 
-## Acceptance Criteria
-- All files at or below $ARGUMENTS lines
-- `bun run lint` passes with no max-lines violations
-
-## Verification
-Command: `bun run lint 2>&1 | grep "max-lines" | wc -l`
-Expected: 0
+Verification: `bun run lint 2>&1 | grep "max-lines" | wc -l` → Expected: 0
 ```
+
+Invoke `/plan-create` with this brief to create the implementation plan.

package/all/copy-overwrite/.claude/skills/plan-reduce-max-lines-per-function/SKILL.md

@@ -2,7 +2,6 @@
 name: plan-reduce-max-lines-per-function
 description: This skill should be used when reducing the maximum lines per function threshold and fixing all violations. It updates the eslint threshold configuration, identifies functions exceeding the new limit, generates a brief with refactoring strategies, and creates a plan with tasks to split oversized functions.
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
-argument-hint: "<max-lines-per-function-value>"
 
 ---
 
@@ -26,37 +25,22 @@ If no argument provided, prompt the user for a target.
 
 If no violations at $ARGUMENTS, report success and exit.
 
-## Step 2: Create Plan
+## Step 2: Compile Brief and Delegate
 
-In plan mode, create a plan that includes the following details:
+Compile the gathered information into a structured brief:
 
-```markdown
+```
 Reduce max lines per function threshold to $ARGUMENTS.
 
-## Functions Exceeding Threshold (ordered by line count)
-
-1. src/services/user.ts:processUser (95 lines, target: $ARGUMENTS)
-   - Line 45, function spans lines 45-140
-2. src/utils/helpers.ts:validateInput (82 lines, target: $ARGUMENTS)
-   - Line 23, function spans lines 23-105
-...
+Functions exceeding threshold (ordered by line count):
+1. [file:function] (lines: X, target: $ARGUMENTS) - Line Y
+2. ...
 
-## Configuration Change
-- File: eslint.thresholds.json
-- Change: maxLinesPerFunction to $ARGUMENTS
+Configuration change: eslint.thresholds.json, maxLinesPerFunction to $ARGUMENTS
 
-## Refactoring Strategies
-- **Extract functions**: Break function into smaller named functions
-- **Early returns**: Reduce nesting with guard clauses
-- **Extract conditions**: Move complex boolean logic into named variables
-- **Use lookup tables**: Replace complex switch/if-else chains with object maps
-- **Consolidate logic**: Merge similar code paths
+Refactoring strategies: extract functions, early returns, extract conditions, use lookup tables, consolidate logic
 
-## Acceptance Criteria
-- All functions at or below $ARGUMENTS lines
-- `bun run lint` passes with no max-lines-per-function violations
-
-## Verification
-Command: `bun run lint 2>&1 | grep "max-lines-per-function" | wc -l`
-Expected: 0
+Verification: `bun run lint 2>&1 | grep "max-lines-per-function" | wc -l` → Expected: 0
 ```
+
+Invoke `/plan-create` with this brief to create the implementation plan.

package/all/copy-overwrite/.claude/skills/pull-request-review/SKILL.md

@@ -2,7 +2,6 @@
 name: pull-request-review
 description: This skill should be used when checking for code review comments on a pull request and implementing them if required. It fetches PR metadata and comments, generates a brief from unresolved feedback, and bootstraps a project to address the review comments.
 allowed-tools: ["Read", "Bash", "Glob", "Grep"]
-argument-hint: "<github-pr-link>"
 ---
 
 # Review PR Comments

package/all/copy-overwrite/.claude/skills/security-zap-scan/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: security-zap-scan
+description: "Run an OWASP ZAP baseline security scan locally using Docker. Checks for the ZAP baseline script, executes the scan, and summarizes findings by risk level with remediation recommendations."
+allowed-tools: ["Bash", "Read"]
+---
+
+# OWASP ZAP Baseline Security Scan
+
+Run a ZAP baseline security scan against the local application.
+
+## Workflow
+
+1. **Check prerequisites**:
+   - Verify Docker is installed and running: `docker info`
+   - Check if `scripts/zap-baseline.sh` exists in the project
+
+2. **Execute scan**:
+   - If the script exists, run: `bash scripts/zap-baseline.sh`
+   - If the script does not exist, inform the user that this project does not have a ZAP baseline scan configured
+
+3. **Analyze results**:
+   - After the scan completes, read `zap-report.html` (or `zap-report.md` for text)
+   - Summarize findings:
+     - Total number of alerts by risk level (High, Medium, Low, Informational)
+     - List each Medium+ finding with its rule ID, name, and recommended fix
+     - Categorize findings as "infrastructure-level" (fix at CDN/proxy) vs "application-level" (fix in code)
+
+4. **Handle failures**:
+   - If the scan failed, explain what failed and suggest concrete remediation steps
+
+## Execution
+
+Run the scan now.

package/all/copy-overwrite/.claude/skills/sonarqube-fix/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sonarqube-fix
-description: This skill should be used when fixing SonarQube quality gate failures. It runs the sonarqube-check skill to identify failures, fixes the identified issues, and then commits the changes using the git-commit skill.
+description: This skill should be used when fixing SonarQube quality gate failures. It runs the sonarqube:check skill to identify failures, fixes the identified issues, and then commits the changes using the git:commit skill.
 ---
 
 1. Run /sonarqube-check

package/all/copy-overwrite/.claude/skills/tasks-load/SKILL.md

@@ -2,7 +2,6 @@
 name: tasks-load
 description: This skill should be used when loading tasks from a project directory into the current Claude Code session. It reads task JSON files from session subdirectories, recreates them in the current session, and sets the active project marker.
 allowed-tools: ["Read", "Bash", "TaskCreate", "TaskUpdate", "TaskList"]
-argument-hint: "<project-name>"
 ---
 
 # Load Project Tasks

package/all/copy-overwrite/.claude/skills/tasks-sync/SKILL.md

@@ -2,7 +2,6 @@
 name: tasks-sync
 description: This skill should be used when syncing current session tasks to a project directory. It exports all tasks from the current Claude Code session to JSON files in the project's tasks directory, enabling persistence across sessions.
 allowed-tools: ["Read", "Write", "Bash", "TaskList", "TaskGet"]
-argument-hint: "<project-name>"
 ---
 
 # Sync Tasks to Project

package/all/copy-overwrite/CLAUDE.md

@@ -18,7 +18,6 @@ Always ignore build folders (dist, build, etc) unless specified otherwise
 Always delete and remove old code completely - no deprecation needed
 Always add `GIT_SSH_COMMAND="ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=5" ` when running `git push`
 Always ignore knip configuration hints (warnings) — only fix actual unused exports/dependencies reported as errors
-Always err on the side of creating a plan before directly executing a coding task
 
 Never modify this file (CLAUDE.md) directly. To add a memory or learning, add it to .claude/rules/PROJECT_RULES.md or create a skill with /skill-creator.
 Never commit changes to an environment branch (dev, staging, main) directly. This is enforced by the pre-commit hook.

package/all/deletions.json

@@ -19,6 +19,28 @@
     ".claude/skills/project-review",
     ".claude/skills/project-setup",
     ".claude/skills/project-verify",
-    ".claude/skills/prompt-complexity-scorer"
+    ".claude/skills/prompt-complexity-scorer",
+    ".claude/skills/git:commit",
+    ".claude/skills/git:commit-and-submit-pr",
+    ".claude/skills/git:prune",
+    ".claude/skills/git:submit-pr",
+    ".claude/skills/jira:create",
+    ".claude/skills/jira:sync",
+    ".claude/skills/jira:verify",
+    ".claude/skills/lisa:review-implementation",
+    ".claude/skills/plan:add-test-coverage",
+    ".claude/skills/plan:create",
+    ".claude/skills/plan:fix-linter-error",
+    ".claude/skills/plan:implement",
+    ".claude/skills/plan:local-code-review",
+    ".claude/skills/plan:lower-code-complexity",
+    ".claude/skills/plan:reduce-max-lines",
+    ".claude/skills/plan:reduce-max-lines-per-function",
+    ".claude/skills/pull-request:review",
+    ".claude/skills/security:zap-scan",
+    ".claude/skills/sonarqube:check",
+    ".claude/skills/sonarqube:fix",
+    ".claude/skills/tasks:load",
+    ".claude/skills/tasks:sync"
   ]
 }

package/nestjs/copy-overwrite/.claude/commands/security/zap-scan.md

@@ -0,0 +1,6 @@
+---
+description: "Run an OWASP ZAP baseline security scan locally using Docker"
+allowed-tools: ["Skill"]
+---
+
+Use the /security-zap-scan skill to run an OWASP ZAP baseline security scan.

package/nestjs/copy-overwrite/.claude/skills/security-zap-scan/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: security-zap-scan
+description: "Run an OWASP ZAP baseline security scan locally using Docker. Checks for the ZAP baseline script, executes the scan, and summarizes findings by risk level with remediation recommendations."
+allowed-tools: ["Bash", "Read"]
+---
+
+# OWASP ZAP Baseline Security Scan
+
+Run a ZAP baseline security scan against the local application.
+
+## Workflow
+
+1. **Check prerequisites**:
+   - Verify Docker is installed and running: `docker info`
+   - Check if `scripts/zap-baseline.sh` exists in the project
+
+2. **Execute scan**:
+   - If the script exists, run: `bash scripts/zap-baseline.sh`
+   - If the script does not exist, inform the user that this project does not have a ZAP baseline scan configured
+
+3. **Analyze results**:
+   - After the scan completes, read `zap-report.html` (or `zap-report.md` for text)
+   - Summarize findings:
+     - Total number of alerts by risk level (High, Medium, Low, Informational)
+     - List each Medium+ finding with its rule ID, name, and recommended fix
+     - Categorize findings as "infrastructure-level" (fix at CDN/proxy) vs "application-level" (fix in code)
+
+4. **Handle failures**:
+   - If the scan failed, explain what failed and suggest concrete remediation steps
+
+## Execution
+
+Run the scan now.

package/package.json

@@ -88,7 +88,7 @@
     "@isaacs/brace-expansion": "^5.0.1"
   },
   "name": "@codyswann/lisa",
-  "version": "1.27.0",
+  "version": "1.28.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "bin": {