@codyswann/lisa 1.47.1 → 1.49.0

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

@@ -0,0 +1,89 @@
+---
+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

@@ -0,0 +1,45 @@
+---
+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

@@ -0,0 +1,88 @@
+---
+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

@@ -0,0 +1,44 @@
+---
+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

@@ -0,0 +1,45 @@
+---
+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

@@ -0,0 +1,46 @@
+---
+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

@@ -0,0 +1,68 @@
+---
+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

@@ -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/plugins/lisa-typescript/skills/skill-creator/LICENSE.txt

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.