@codyswann/lisa 1.56.0 → 1.56.2

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

@@ -1,89 +0,0 @@
----
-name: plan-execute
-description: This skill should be used for any non-trivial request — features, bugs, stories, epics, spikes, or multi-step tasks. It accepts a ticket URL (Jira, Linear, GitHub), a file path containing a spec, or a plain-text prompt. It assembles an agent team, breaks the work into structured tasks, and manages the full lifecycle from research through implementation, code review, deploy, and empirical verification.
----
-
-
-$ARGUMENTS is either a url to a ticket containing the request, a pointer to a file containing the request or the request in text format.
-
-If it's a ticket, use either the Jira CLI (if it's a jira ticket), the Linear CLI (if it's a linear ticket) or the Github CLI (if it's a github ticket) to read and fully understand the request, including any comments or meta data associated with the ticket.
-
-If it's a file, read the entire file without offset or limit to understand the request.
-
-Is this a simple request? Just execute it as usual and ignore the rest...
-
-Otherwise:
-
-
-Review all available agent types listed in the Task tool's `subagent_type` options. This includes built-in agents (like `Explore`, `general-purpose`), custom agents (from `.claude/agents/`), and plugin agents (from `.claude/settings.json` `enabledPlugins`). For each agent, explain in one sentence why it IS or IS NOT relevant to this task. Then select all agents that are relevant. You MUST justify excluding an agent — inclusion is the default.
-
-When deciding the agents to use, consider:
-* Before any task is implemented, the agent team must explore the codebase for relevant research (documentation, code, git history, etc) and update each task's `metadata.relevant_documentation` with the findings.
-* Each task must be reviewed by the team to make sure their verification passes.
-* Each task must have their learnings reviewed by the learner subagent.
-
-NOTE: Every team must include the Explore agent
-
-Create an agent team composed of the selected agents. Spawn every agent with `mode: "plan"` so they must submit their plan for team lead approval before making any file changes.
-
-Use the TeamCreate tool to create the team before doing anything else.
-
-Using the general-purpose agent in Team Lead session, Determine the name of this plan
-
-Using the general-purpose agent in Team Lead session, Determine what branch to use:
-1. Are we already on a feature branch with an open pull request? Use that and set the target branch to the existing target of the pull request
-2. Are we on a feature branch without an open pull request? Use the branch, but ask the human what branch to target for the PR
-3. Are we on an environment branch (dev, staging, main, prod, production)? Check out a feature branch named for this plan and set the target branch of the PR to the environment branch
-
-Using the general-purpose agent in Team Lead session, Determine what type of request this is for:
-1. Informational/Spike
-2. Task
-3. Bug
-4. Feature/Story
-5. Epic
-
-IF it's a bug, Using the general-purpose agent in Team Lead session, determine how you will replicate the bug empirically:
-1. Examples:
-   1. Write a simple API client and call the offending API
-   2. Start the server on localhost and Use the Playwright CLI or Chrome DevTools
-
-Using the general-purpose agent in Team Lead session, determine how you will know that the task is fully complete
-1. Examples
-   1. Direct deploy the changes to dev and then Write a simple API client and call the offending API
-   2. Start the server on localhost and then Use the Playwright CLI or Chrome DevTools
-
-Using the general-purpose agent in Team Lead session, create tasks needed to complete the request.
-
-Every task MUST include this JSON metadata block. Do NOT omit `skills` (use `[]` if none), `learnings` (use `[]` if none) or `verification`.
-
-```json
-{
-  "plan": "<plan-name>",
-  "type": "spike|bug|task|epic|story",
-  "acceptance_criteria": ["..."],
-  "relevant_documentation": "",
-  "testing_requirements": ["..."],
-  "skills": ["..."],
-  "learnings": ["..."],
-  "verification": {
-    "type": "test|ui-recording|test-coverage|api-test|manual-check|documentation",
-    "command": "the proof command",
-    "expected": "what success looks like"
-  }
-}
-```
-
-Before any task is implemented, the agent team must explore the codebase for relevant research (documentation, code, git history, etc) and update each task's `metadata.relevant_documentation` with the findings.
-
-Each task must be reviewed by the team to make sure their verification passes.
-Each task must have their learnings reviewed by the learner subagent.
-
-Before shutting down the team:
-
-1. Commit ALL outstanding changes in logical batches on the branch (minus sensitive data/information) — not just changes made by the agent team. This includes pre-existing uncommitted changes that were on the branch before the plan started. Do NOT filter commits to only "task-related" files. If it shows up in git status, it gets committed (unless it contains secrets).
-2. Push the changes - if any pre-push hook blocks you, create a task for the agent team to fix the error/problem whether it was pre-existing or not
-3. Open a pull request with auto-merge on
-4. Monitor the PR. Create a task for the agent team to resolve any code review comments by either implementing the suggestions or commenting why they should not be implemented and close the comment. Fix any failing checks and repush. Continue all checks pass
-5. Monitor the deploy action that triggers automatically from the successful merge
-6. If it fails, create a task for the agent team to fix the failure, open a new PR and then go back to step 4
-7. Execute empirical verification. If empirical verification succeeds, you're finished, otherwise, create a task for the agent team to find out why it failed, fix it and return to step 1 (repeat this until you get all the way through)

package/plugins/lisa-typescript/skills/plan-fix-linter-error/SKILL.md

@@ -1,45 +0,0 @@
----
-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"]
-
----
-
-# Fix Linter Errors
-
-Target rules: $ARGUMENTS
-
-If no arguments provided, prompt the user for at least one lint rule name.
-
-## Step 1: Gather Requirements
-
-1. **Parse rules** from $ARGUMENTS (space-separated)
-2. **Run linter** to collect all violations:
-   ```bash
-   bun run lint 2>&1
-   ```
-3. **Group violations** by rule, then by file, noting:
-   - File path and line numbers
-   - Violation count per file
-   - Sample error messages
-
-## Step 2: Compile Brief and Delegate
-
-Compile the gathered information into a structured brief:
-
-```
-Fix ESLint violations for rules: $ARGUMENTS
-
-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
-  - ...
-
-Fix strategies: extract functions, early returns, apply formatting, add types
-
-Verification: `bun run lint 2>&1 | grep -E "($ARGUMENTS)" | wc -l` → Expected: 0
-```
-
-Invoke `/plan-execute` with this brief to create the implementation plan.

package/plugins/lisa-typescript/skills/plan-local-code-review/SKILL.md

@@ -1,88 +0,0 @@
----
-name: plan-local-code-review
-description: This skill should be used when performing a code review on local changes on the current branch compared to the main branch. It uses multiple parallel agents to check for bugs, CLAUDE.md compliance, git history context, previous PR comments, and code comment adherence, then scores and filters findings by confidence level.
-disable-model-invocation: false
----
-
-Provide a code review for the local changes on the current branch compared to the main branch.
-
-To do this, follow these steps precisely:
-
-1. Use a Haiku agent to check the current git state:
-   - Run `git branch --show-current` to get the current branch name
-   - Run `git log main..HEAD --oneline` to see commits on this branch
-   - Run `git diff main...HEAD --stat` to see changed files
-   - If the current branch IS main, or there are no commits/changes compared to main, do not proceed.
-2. Use another Haiku agent to give you a list of file paths to (but not the contents of) any relevant CLAUDE.md files from the codebase: the root CLAUDE.md file (if one exists), as well as any CLAUDE.md files in the directories whose files were modified on this branch
-3. Use a Haiku agent to analyze the branch changes:
-   - Run `git log main..HEAD --format="%s%n%b"` to get commit messages
-   - Run `git diff main...HEAD` to get the full diff
-   - Return a summary of the changes
-4. Then, launch 5 parallel Sonnet agents to independently code review the change. The agents should do the following, then return a list of issues and the reason each issue was flagged (eg. CLAUDE.md adherence, bug, historical git context, etc.):
-   a. Agent #1: Audit the changes to make sure they comply with the CLAUDE.md. Note that CLAUDE.md is guidance for Claude as it writes code, so not all instructions will be applicable during code review.
-   b. Agent #2: Read the file changes (via `git diff main...HEAD`), then do a shallow scan for obvious bugs. Avoid reading extra context beyond the changes, focusing just on the changes themselves. Focus on large bugs, and avoid small issues and nitpicks. Ignore likely false positives.
-   c. Agent #3: Read the git blame and history of the code modified, to identify any bugs in light of that historical context
-   d. Agent #4: Read previous pull requests that touched these files, and check for any comments on those pull requests that may also apply to the current changes.
-   e. Agent #5: Read code comments in the modified files, and make sure the changes comply with any guidance in the comments.
-5. For each issue found in #4, launch a parallel Haiku agent that takes the diff, issue description, and list of CLAUDE.md files (from step 2), and returns a score to indicate the agent's level of confidence for whether the issue is real or false positive. To do that, the agent should score each issue on a scale from 0-100, indicating its level of confidence. For issues that were flagged due to CLAUDE.md instructions, the agent should double check that the CLAUDE.md actually calls out that issue specifically. The scale is (give this rubric to the agent verbatim):
-   a. 0: Not confident at all. This is a false positive that doesn't stand up to light scrutiny, or is a pre-existing issue.
-   b. 25: Somewhat confident. This might be a real issue, but may also be a false positive. The agent wasn't able to verify that it's a real issue. If the issue is stylistic, it is one that was not explicitly called out in the relevant CLAUDE.md.
-   c. 50: Moderately confident. The agent was able to verify this is a real issue, but it might be a nitpick or not happen very often in practice. Relative to the rest of the changes, it's not very important.
-   d. 75: Highly confident. The agent double checked the issue, and verified that it is very likely it is a real issue that will be hit in practice. The existing approach is insufficient. The issue is very important and will directly impact the code's functionality, or it is an issue that is directly mentioned in the relevant CLAUDE.md.
-   e. 100: Absolutely certain. The agent double checked the issue, and confirmed that it is definitely a real issue, that will happen frequently in practice. The evidence directly confirms this.
-6. Filter out any issues with a score less than 80.
-7. Write the review to claude-review.md. When writing your review, keep in mind to:
-   a. Keep your output brief
-   b. Avoid emojis
-   c. Reference relevant files and line numbers
-8. Briefly summarize claude-review.md as direct output to the user
-
-Examples of false positives, for steps 4 and 5:
-
-- Pre-existing issues
-- Something that looks like a bug but is not actually a bug
-- Pedantic nitpicks that a senior engineer wouldn't call out
-- Issues that a linter, typechecker, or compiler would catch (eg. missing or incorrect imports, type errors, broken tests, formatting issues, pedantic style issues like newlines). No need to run these build steps yourself -- it is safe to assume that they will be run separately as part of CI.
-- General code quality issues (eg. lack of test coverage, general security issues, poor documentation), unless explicitly required in CLAUDE.md
-- Issues that are called out in CLAUDE.md, but explicitly silenced in the code (eg. due to a lint ignore comment)
-- Changes in functionality that are likely intentional or are directly related to the broader change
-- Real issues, but on lines that were not modified in the current branch
-
-Notes:
-
-- Do not check build signal or attempt to build or typecheck the app. These will run separately, and are not relevant to your code review.
-- Use git commands to analyze local changes (not `gh` commands for remote PRs)
-- Make a todo list first
-- You must cite each bug with file path and line number (eg. if referring to a CLAUDE.md, you must reference it)
-- For your final output, follow the following format precisely (assuming for this example that you found 3 issues):
-
----
-
-### Code review for branch `<branch-name>`
-
-Reviewed X commits with changes to Y files.
-
-Found 3 issues:
-
-1. **<brief description of bug>** (CLAUDE.md says "<...>")
-   - File: `path/to/file.ts:L10-L15`
-
-2. **<brief description of bug>** (some/other/CLAUDE.md says "<...>")
-   - File: `path/to/other-file.ts:L25-L30`
-
-3. **<brief description of bug>** (bug due to <reasoning>)
-   - File: `path/to/another-file.ts:L5-L8`
-
----
-
-- Or, if you found no issues:
-
----
-
-### Code review for branch `<branch-name>`
-
-Reviewed X commits with changes to Y files.
-
-No issues found. Checked for bugs and CLAUDE.md compliance.
-
----

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

@@ -1,44 +0,0 @@
----
-name: plan-lower-code-complexity
-description: This skill should be used when reducing the cognitive complexity threshold of the codebase. It lowers the threshold by 2, identifies functions that exceed the new limit, generates a brief with refactoring strategies, and creates a plan with tasks to fix all violations.
-allowed-tools: ["Read", "Bash", "Glob", "Grep"]
----
-
-# Lower Code Complexity
-
-Reduces the cognitive complexity threshold by 2 and fixes all violations.
-
-## Step 1: Gather Requirements
-
-1. **Read current threshold** from eslint config (cognitive-complexity rule)
-2. **Calculate new threshold**: current - 2 (e.g., 15 -> 13)
-3. **Run lint** with the new threshold to find violations:
-   ```bash
-   bun run lint 2>&1 | grep "cognitive-complexity"
-   ```
-4. **Note for each violation**:
-   - File path and line number
-   - Function name
-   - Current complexity score
-
-If no violations at new threshold, report success and exit.
-
-## Step 2: Compile Brief and Delegate
-
-Compile the gathered information into a structured brief:
-
-```
-Reduce cognitive complexity threshold from [current] to [new].
-
-Functions exceeding threshold (ordered by complexity):
-1. [file:function] (complexity: X, target: [new]) - Line Y
-2. ...
-
-Configuration change: [eslint config path], cognitive-complexity from [current] to [new]
-
-Refactoring strategies: extract functions, early returns, extract conditions, use lookup tables
-
-Verification: `bun run lint 2>&1 | grep "cognitive-complexity" | wc -l` → Expected: 0
-```
-
-Invoke `/plan-execute` with this brief to create the implementation plan.

package/plugins/lisa-typescript/skills/plan-reduce-max-lines/SKILL.md

@@ -1,45 +0,0 @@
----
-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"]
-
----
-
-# Reduce Max Lines
-
-Target threshold: $ARGUMENTS lines per file
-
-If no argument provided, prompt the user for a target.
-
-## Step 1: Gather Requirements
-
-1. **Read current config** from eslint thresholds (eslint.thresholds.json or similar)
-2. **Run lint** with the new threshold to find violations:
-   ```bash
-   bun run lint 2>&1 | grep "max-lines"
-   ```
-3. **Note for each violation**:
-   - File path
-   - Current line count
-
-If no violations at $ARGUMENTS, report success and exit.
-
-## Step 2: Compile Brief and Delegate
-
-Compile the gathered information into a structured brief:
-
-```
-Reduce max file lines threshold to $ARGUMENTS.
-
-Files exceeding threshold (ordered by line count):
-1. [file] - [current] lines (target: $ARGUMENTS)
-2. ...
-
-Configuration change: eslint.thresholds.json, maxLines to $ARGUMENTS
-
-Refactoring strategies: extract modules, remove duplication, delete dead code, simplify logic
-
-Verification: `bun run lint 2>&1 | grep "max-lines" | wc -l` → Expected: 0
-```
-
-Invoke `/plan-execute` with this brief to create the implementation plan.

package/plugins/lisa-typescript/skills/plan-reduce-max-lines-per-function/SKILL.md

@@ -1,46 +0,0 @@
----
-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"]
-
----
-
-# Reduce Max Lines Per Function
-
-Target threshold: $ARGUMENTS lines per function
-
-If no argument provided, prompt the user for a target.
-
-## Step 1: Gather Requirements
-
-1. **Read current config** from eslint thresholds (eslint.thresholds.json or similar)
-2. **Run lint** with the new threshold to find violations:
-   ```bash
-   bun run lint 2>&1 | grep "max-lines-per-function"
-   ```
-3. **Note for each violation**:
-   - File path and line number
-   - Function name
-   - Current line count
-
-If no violations at $ARGUMENTS, report success and exit.
-
-## Step 2: Compile Brief and Delegate
-
-Compile the gathered information into a structured brief:
-
-```
-Reduce max lines per function threshold to $ARGUMENTS.
-
-Functions exceeding threshold (ordered by line count):
-1. [file:function] (lines: X, target: $ARGUMENTS) - Line Y
-2. ...
-
-Configuration change: eslint.thresholds.json, maxLinesPerFunction to $ARGUMENTS
-
-Refactoring strategies: extract functions, early returns, extract conditions, use lookup tables, consolidate logic
-
-Verification: `bun run lint 2>&1 | grep "max-lines-per-function" | wc -l` → Expected: 0
-```
-
-Invoke `/plan-execute` with this brief to create the implementation plan.

package/plugins/lisa-typescript/skills/pull-request-review/SKILL.md

@@ -1,68 +0,0 @@
----
-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"]
----
-
-# Review PR Comments
-
-Target PR: $ARGUMENTS
-
-If no argument provided, prompt the user for a PR link or number.
-
-## Step 1: Gather Requirements
-
-1. **Fetch PR metadata and comments** using the GitHub CLI:
-   ```bash
-   gh pr view $ARGUMENTS --json number,title,body,reviews,comments
-   gh api repos/{owner}/{repo}/pulls/{pr_number}/comments
-   ```
-2. **Extract each unresolved review comment**:
-   - Comment ID
-   - File path
-   - Line number
-   - Comment body
-   - Author
-
-If no unresolved comments exist, report success and exit.
-
-## Step 2: Create Plan
-
-In plan mode, create a plan that includes the following details:
-
-```markdown
-Implement PR review feedback for $ARGUMENTS.
-
-## PR Overview
-- Title: [PR title]
-- Description: [PR description summary]
-
-## Review Comments to Address (ordered by file)
-
-### 1. [file_path]:[line_number] (Comment ID: [id])
-**Reviewer**: [author]
-**Comment**: [full comment body]
-**Action Required**: [brief description of what needs to change]
-
-### 2. [file_path]:[line_number] (Comment ID: [id])
-**Reviewer**: [author]
-**Comment**: [full comment body]
-**Action Required**: [brief description of what needs to change]
-
-...
-
-## Implementation Guidelines
-- Evaluate each comment for validity before implementing
-- If a comment is not valid, document the reasoning
-- Ensure changes follow project coding standards
-- Run relevant tests to verify changes work
-
-## Acceptance Criteria
-- All valid review comments addressed
-- Tests pass after changes
-- `bun run lint` passes
-
-## Verification
-Command: `bun run lint && bun run test`
-Expected: All checks pass
-```

package/plugins/lisa-typescript/skills/security-zap-scan/SKILL.md

@@ -1,33 +0,0 @@
----
-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/plugins/lisa-typescript/skills/sonarqube-check/SKILL.md

@@ -1,11 +0,0 @@
----
-name: sonarqube-check
-description: This skill should be used when checking why the last pull request failed SonarQube/SonarCloud quality gates. It uses the SonarQube MCP server to retrieve failure details and report the reasons.
-allowed-tools: ["mcp__sonarqube__*"]
----
-
-# SonarQube Check
-
-Use the SonarQube MCP server to get the reason the last PR failed checks.
-
-Retrieve the quality gate status and report all failures with their details.

package/plugins/lisa-typescript/skills/sonarqube-fix/SKILL.md

@@ -1,8 +0,0 @@
----
-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.
----
-
-1. Run /sonarqube-check
-2. Fix the SonarQube quality gate failures identified in step 1
-3. Run /git-commit

package/plugins/lisa-typescript/skills/tasks-load/SKILL.md

@@ -1,88 +0,0 @@
----
-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"]
----
-
-# Load Project Tasks
-
-Load tasks from `projects/$ARGUMENTS/tasks/` into the current Claude Code session.
-
-Tasks are stored in session subdirectories to preserve history across `/clear` commands:
-```
-projects/$ARGUMENTS/tasks/
-├── {session-1-uuid}/
-│   ├── 1.json
-│   └── 2.json
-└── {session-2-uuid}/
-    ├── 1.json
-    └── 2.json
-```
-
-## Process
-
-### Step 1: Validate Project
-
-Check if the project exists and has task files:
-
-```bash
-find projects/$ARGUMENTS/tasks -name "*.json" 2>/dev/null | head -5
-```
-
-If no task files exist, report: "No tasks found in projects/$ARGUMENTS/tasks/"
-
-List available sessions:
-
-```bash
-ls -dt projects/$ARGUMENTS/tasks/*/ 2>/dev/null | head -10
-```
-
-### Step 2: Set Active Project
-
-Create the active project marker:
-
-```bash
-echo "$ARGUMENTS" > .claude-active-project
-```
-
-This ensures any new tasks created will sync back to this project.
-
-### Step 3: Load Tasks
-
-Find and load all task JSON files from ALL session directories:
-
-```bash
-find projects/$ARGUMENTS/tasks -name "*.json" -type f
-```
-
-For each JSON file found:
-
-1. Read the task JSON file
-2. Use TaskCreate to recreate the task with:
-   - subject from JSON
-   - description from JSON
-   - activeForm from JSON
-   - metadata: `{ "project": "$ARGUMENTS" }`
-3. If the task was already completed (status: "completed"), use TaskUpdate to mark it completed
-
-### Step 4: Report
-
-After loading all tasks, report:
-
-```
-Loaded X tasks from projects/$ARGUMENTS/tasks/
-- Sessions found: N
-- Pending: Y
-- Completed: Z
-
-Active project set to: $ARGUMENTS
-New tasks will automatically sync to this project.
-```
-
-## Notes
-
-- Tasks are recreated with new IDs in the current session
-- The original task IDs from the project are not preserved
-- Tasks from ALL sessions are loaded (full history)
-- Task dependencies (blocks/blockedBy) are NOT currently preserved across load/sync cycles
-- Use TaskList to see the loaded tasks