@codyswann/lisa 1.48.0 → 1.50.0

package/plugins/lisa-expo/skills/skill-creator/scripts/quick_validate.py

@@ -0,0 +1,67 @@
+#!/usr/bin/env python3
+# This file is managed by Lisa.
+# Do not edit directly — changes will be overwritten on the next `lisa` run.
+"""
+Quick validation script for skills - minimal version
+"""
+
+import sys
+import os
+import re
+from pathlib import Path
+
+def validate_skill(skill_path):
+    """Basic validation of a skill"""
+    skill_path = Path(skill_path)
+    
+    # Check SKILL.md exists
+    skill_md = skill_path / 'SKILL.md'
+    if not skill_md.exists():
+        return False, "SKILL.md not found"
+    
+    # Read and validate frontmatter
+    content = skill_md.read_text()
+    if not content.startswith('---'):
+        return False, "No YAML frontmatter found"
+    
+    # Extract frontmatter
+    match = re.match(r'^---\n(.*?)\n---', content, re.DOTALL)
+    if not match:
+        return False, "Invalid frontmatter format"
+    
+    frontmatter = match.group(1)
+    
+    # Check required fields
+    if 'name:' not in frontmatter:
+        return False, "Missing 'name' in frontmatter"
+    if 'description:' not in frontmatter:
+        return False, "Missing 'description' in frontmatter"
+    
+    # Extract name for validation
+    name_match = re.search(r'name:\s*(.+)', frontmatter)
+    if name_match:
+        name = name_match.group(1).strip()
+        # Check naming convention (hyphen-case: lowercase with hyphens)
+        if not re.match(r'^[a-z0-9-]+$', name):
+            return False, f"Name '{name}' should be hyphen-case (lowercase letters, digits, and hyphens only)"
+        if name.startswith('-') or name.endswith('-') or '--' in name:
+            return False, f"Name '{name}' cannot start/end with hyphen or contain consecutive hyphens"
+
+    # Extract and validate description
+    desc_match = re.search(r'description:\s*(.+)', frontmatter)
+    if desc_match:
+        description = desc_match.group(1).strip()
+        # Check for angle brackets
+        if '<' in description or '>' in description:
+            return False, "Description cannot contain angle brackets (< or >)"
+
+    return True, "Skill is valid!"
+
+if __name__ == "__main__":
+    if len(sys.argv) != 2:
+        print("Usage: python quick_validate.py <skill_directory>")
+        sys.exit(1)
+    
+    valid, message = validate_skill(sys.argv[1])
+    print(message)
+    sys.exit(0 if valid else 1)

package/plugins/lisa-expo/skills/sonarqube-check/SKILL.md

@@ -0,0 +1,11 @@
+---
+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-expo/skills/sonarqube-fix/SKILL.md

@@ -0,0 +1,8 @@
+---
+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-expo/skills/tasks-load/SKILL.md

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

package/plugins/lisa-expo/skills/tasks-sync/SKILL.md

@@ -0,0 +1,108 @@
+---
+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"]
+---
+
+# Sync Tasks to Project
+
+Sync all tasks from the current session to `projects/$ARGUMENTS/tasks/{session-id}/`.
+
+This skill is for manual syncing when work started without setting an active project. Once synced, the automatic hook handles future task updates.
+
+## Process
+
+### Step 1: Validate Project
+
+Check if the project directory exists:
+
+```bash
+ls -d projects/$ARGUMENTS 2>/dev/null
+```
+
+If the project doesn't exist, ask: "Project '$ARGUMENTS' doesn't exist. Create it?"
+
+If yes, create the project structure:
+
+```bash
+mkdir -p projects/$ARGUMENTS/tasks
+```
+
+### Step 2: Determine Session ID
+
+Find the current session by looking for the most recently modified task directory:
+
+```bash
+ls -dt ~/.claude/tasks/*/ 2>/dev/null | head -1 | xargs basename
+```
+
+If no session found, use a timestamp-based identifier:
+
+```bash
+echo "manual-$(date +%Y%m%d-%H%M%S)"
+```
+
+Store the session ID for use in subsequent steps.
+
+### Step 3: Set Active Project
+
+Create/update the active project marker:
+
+```bash
+echo "$ARGUMENTS" > .claude-active-project
+```
+
+### Step 4: Get Current Tasks
+
+Use TaskList to get all tasks in the current session.
+
+### Step 5: Sync Each Task
+
+For each task from TaskList:
+
+1. Use TaskGet to get full task details
+2. Create the session directory:
+
+```bash
+mkdir -p projects/$ARGUMENTS/tasks/{session-id}
+```
+
+3. Create a JSON file with the task data:
+
+```json
+{
+  "id": "<task-id>",
+  "subject": "<subject>",
+  "description": "<description>",
+  "activeForm": "<activeForm>",
+  "status": "<status>",
+  "blocks": [],
+  "blockedBy": []
+}
+```
+
+4. Write to `projects/$ARGUMENTS/tasks/{session-id}/<id>.json`
+
+### Step 6: Stage for Git
+
+```bash
+git add projects/$ARGUMENTS/tasks/{session-id}/*.json
+```
+
+### Step 7: Report
+
+```
+Synced X tasks to projects/$ARGUMENTS/tasks/{session-id}/
+- Pending: Y
+- In Progress: Z
+- Completed: W
+
+Files staged for commit. Run /git-commit when ready.
+```
+
+## Notes
+
+- This skill manually syncs all current tasks to a project
+- Use this when work started without a project context
+- After syncing, the active project is set so future tasks auto-sync via the hook
+- Each sync creates a new session directory to preserve history

package/plugins/lisa-expo/skills/testing-library/SKILL.md

@@ -0,0 +1,314 @@
+---
+name: testing-library
+description: Enforces best practices for unit testing with Jest, @testing-library/react-native, and jest-expo in Expo projects. This skill should be used when writing, reviewing, or debugging unit tests to ensure tests are accessible, maintainable, and follow Testing Library guiding principles. Use this skill for test file creation, query selection, async handling, mocking patterns, and Expo Router testing.
+---
+
+# Testing Library Best Practices
+
+## Overview
+
+This skill enforces best practices for unit testing in Expo applications using Jest, `@testing-library/react-native`, and `jest-expo`. Tests should be **user-centric**, **accessible**, and **behavior-focused** rather than implementation-focused.
+
+## Core Principles
+
+### 1. Test User Behavior, Not Implementation
+
+Focus on what the component does from a user's perspective, not how it achieves it internally.
+
+```typescript
+// Correct - tests visible behavior
+expect(screen.getByRole("button", { name: "Submit" })).toBeEnabled();
+
+// Incorrect - tests implementation details
+expect(component.state.isSubmitting).toBe(false);
+```
+
+### 2. Use Accessible Queries
+
+Queries should reflect how users and assistive technologies interact with the UI.
+
+```typescript
+// Correct - uses accessible role and name
+screen.getByRole("button", { name: /save changes/i });
+
+// Incorrect - relies on implementation detail
+screen.getByTestId("save-btn");
+```
+
+### 3. One Assertion Per Behavior
+
+Each test should verify one behavior. Multiple assertions are acceptable when verifying different aspects of the same behavior.
+
+```typescript
+// Correct - focused test
+test("displays error message when submission fails", async () => {
+  render(<Form />);
+  await userEvent.press(screen.getByRole("button", { name: "Submit" }));
+  expect(await screen.findByRole("alert")).toHaveTextContent("Failed");
+});
+
+// Incorrect - testing multiple behaviors
+test("form works correctly", async () => {
+  // Tests validation, submission, success, and error handling...
+});
+```
+
+### 4. Prefer userEvent Over fireEvent
+
+`userEvent` simulates realistic user interactions including the full event sequence.
+
+```typescript
+// Correct - realistic interaction
+const user = userEvent.setup();
+await user.press(screen.getByRole("button", { name: "Submit" }));
+
+// Less ideal - simplified event
+fireEvent.press(screen.getByRole("button", { name: "Submit" }));
+```
+
+## Query Priority
+
+Choose queries based on accessibility, following this priority order:
+
+| Priority | Query            | When to Use                             |
+| -------- | ---------------- | --------------------------------------- |
+| 1        | `getByRole`      | Interactive elements, headings, buttons |
+| 2        | `getByLabelText` | Form fields with labels                 |
+| 3        | `getByText`      | Non-interactive content, static text    |
+| 4        | `getByTestId`    | Last resort when semantic queries fail  |
+
+For detailed query patterns, see [references/query-priority.md](references/query-priority.md).
+
+## Async Testing Patterns
+
+### Use findBy for Async Assertions
+
+```typescript
+// Correct - waits for element to appear
+expect(await screen.findByRole("alert")).toBeOnTheScreen();
+
+// Incorrect - may fail if element appears async
+expect(screen.getByRole("alert")).toBeOnTheScreen();
+```
+
+### Use waitFor for Side Effects
+
+```typescript
+// Correct - assertion inside waitFor
+await waitFor(() => {
+  expect(mockCallback).toHaveBeenCalledWith("success");
+});
+
+// Incorrect - side effect inside waitFor
+await waitFor(() => {
+  fireEvent.press(button); // Never do this
+});
+```
+
+For comprehensive async patterns, see [references/async-patterns.md](references/async-patterns.md).
+
+## Mocking Patterns
+
+### Required Global Mocks
+
+These must be configured in `jest/setup-jest.ts`:
+
+```typescript
+// AsyncStorage
+jest.mock("@react-native-async-storage/async-storage", () =>
+  require("@react-native-async-storage/async-storage/jest/async-storage-mock")
+);
+
+// Expo Fonts (to avoid async icon assertions)
+jest.mock("expo-font", () => ({
+  ...jest.requireActual("expo-font"),
+  isLoaded: jest.fn(() => true),
+}));
+```
+
+For complete mocking patterns, see [references/mocking-patterns.md](references/mocking-patterns.md).
+
+## Expo Router Testing
+
+Use `renderRouter` from `expo-router/testing-library` instead of `render` when testing components that use Expo Router.
+
+```typescript
+import { renderRouter, screen } from "expo-router/testing-library";
+
+test("navigates to player detail", async () => {
+  renderRouter({
+    index: () => <PlayerList />,
+    "players/[id]": () => <PlayerDetail />,
+  });
+
+  await userEvent.press(screen.getByRole("button", { name: "View Player" }));
+  expect(screen).toHavePathname("/players/123");
+});
+```
+
+For Expo Router testing details, see [references/expo-router-testing.md](references/expo-router-testing.md).
+
+## Test Structure
+
+### File Organization
+
+- Place test files in `__tests__/` directories, not alongside source files
+- Never place tests inside the `app/` directory (Expo Router constraint)
+- Use `.test.ts` or `.test.tsx` extensions
+
+### AAA Pattern
+
+Structure every test with Arrange-Act-Assert:
+
+```typescript
+test("increments counter when button pressed", async () => {
+  // Arrange
+  const user = userEvent.setup();
+  render(<Counter initialCount={0} />);
+
+  // Act
+  await user.press(screen.getByRole("button", { name: "Increment" }));
+
+  // Assert
+  expect(screen.getByRole("text", { name: "Count: 1" })).toBeOnTheScreen();
+});
+```
+
+### Descriptive Test Names
+
+Use descriptive names that explain the expected behavior:
+
+```typescript
+// Correct - describes behavior
+test("displays validation error when email format is invalid", () => {});
+test("disables submit button while form is submitting", () => {});
+
+// Incorrect - vague or implementation-focused
+test("email validation works", () => {});
+test("sets isSubmitting to true", () => {});
+```
+
+## Jest Configuration
+
+### Manual React Native Resolution (No Preset)
+
+Lisa configures Jest manually instead of using the `jest-expo` preset to avoid
+jsdom incompatibility with `react-native/jest/setup.js`. The configuration in
+`jest.expo.ts` provides haste, resolver, transform, and setupFiles that match
+the preset's behavior without redefining `window`.
+
+### Use Fake Timers with userEvent
+
+```typescript
+jest.useFakeTimers();
+
+test("handles debounced input", async () => {
+  const user = userEvent.setup();
+  render(<SearchInput />);
+
+  await user.type(screen.getByRole("textbox"), "query");
+  jest.runAllTimers();
+
+  expect(await screen.findByText("Results")).toBeOnTheScreen();
+});
+```
+
+## Anti-Patterns
+
+### Never Test Implementation Details
+
+```typescript
+// Wrong - testing internal state
+expect(wrapper.state().isLoading).toBe(true);
+
+// Wrong - testing component methods
+expect(wrapper.instance().handleSubmit).toHaveBeenCalled();
+
+// Correct - testing visible behavior
+expect(screen.getByRole("progressbar")).toBeOnTheScreen();
+```
+
+### Never Use getByTestId as Default
+
+```typescript
+// Wrong - using testID when semantic query exists
+screen.getByTestId("submit-button");
+
+// Correct - using accessible query
+screen.getByRole("button", { name: "Submit" });
+```
+
+### Never Wrap render or fireEvent in act()
+
+```typescript
+// Wrong - unnecessary act wrapper
+await act(async () => {
+  render(<Component />);
+});
+
+// Correct - render already wraps in act
+render(<Component />);
+```
+
+### Never Put Side Effects in waitFor
+
+```typescript
+// Wrong - side effect in waitFor
+await waitFor(() => {
+  fireEvent.press(button);
+  expect(result).toBeOnTheScreen();
+});
+
+// Correct - side effect before waitFor
+fireEvent.press(button);
+await waitFor(() => {
+  expect(result).toBeOnTheScreen();
+});
+```
+
+### Never Use Multiple Assertions in waitFor
+
+```typescript
+// Wrong - multiple assertions
+await waitFor(() => {
+  expect(title).toBeOnTheScreen();
+  expect(subtitle).toBeOnTheScreen();
+  expect(button).toBeEnabled();
+});
+
+// Correct - single assertion, chain with findBy
+expect(await screen.findByRole("heading")).toBeOnTheScreen();
+expect(screen.getByText("Subtitle")).toBeOnTheScreen();
+expect(screen.getByRole("button")).toBeEnabled();
+```
+
+## Quick Reference
+
+### Common Matchers
+
+| Matcher               | Purpose                         |
+| --------------------- | ------------------------------- |
+| `toBeOnTheScreen()`   | Element is currently rendered   |
+| `toBeEnabled()`       | Interactive element is enabled  |
+| `toBeDisabled()`      | Interactive element is disabled |
+| `toHaveTextContent()` | Element contains text           |
+| `toBeVisible()`       | Element is visible to user      |
+| `toBeChecked()`       | Checkbox/radio is checked       |
+
+### Query Variants
+
+| Prefix     | Returns              | Throws on 0 | Throws on >1 | Async |
+| ---------- | -------------------- | ----------- | ------------ | ----- |
+| getBy      | Element              | Yes         | Yes          | No    |
+| queryBy    | Element \| null      | No          | Yes          | No    |
+| findBy     | Promise\<Element\>   | Yes         | Yes          | Yes   |
+| getAllBy   | Element[]            | Yes         | No           | No    |
+| queryAllBy | Element[]            | No          | No           | No    |
+| findAllBy  | Promise\<Element[]\> | Yes         | No           | Yes   |
+
+## References
+
+- [Query Priority](references/query-priority.md) - Detailed query selection guidance
+- [Async Patterns](references/async-patterns.md) - Comprehensive async testing patterns
+- [Mocking Patterns](references/mocking-patterns.md) - Common mocking configurations
+- [Expo Router Testing](references/expo-router-testing.md) - Testing with Expo Router