home / skills / codyswanngt / lisa / lisa-integration-test

lisa-integration-test skill

/.claude/skills/lisa-integration-test

This skill applies Lisa templates to a downstream project, validates build and tests, and retries with upstream fixes until all checks pass.

npx playbooks add skill codyswanngt/lisa --skill lisa-integration-test

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.6 KB
---
name: lisa-integration-test
description: This skill should be used when integration testing Lisa against a downstream project. It applies Lisa templates, verifies the project still builds, and if anything breaks, fixes the templates upstream in Lisa and retries until the project passes all checks.
---

# Lisa Integration Test

Apply Lisa templates to a downstream project and verify it works end-to-end. If anything breaks, fix the upstream templates in Lisa and retry until the project passes all checks.

This must be run FROM the Lisa repository directory.

## Prerequisites

- Running from the Lisa repo (has `src/core/lisa.ts`)
- The target project has Lisa applied (has `.lisa-manifest`)
- The target project's working directory is clean (no uncommitted changes)

## Instructions

### Step 1: Validate Environment

1. Confirm running from Lisa by checking for `src/core/lisa.ts`
2. Extract project path from `$ARGUMENTS`. If not provided, ask the user.
3. Validate the project path exists and has `.lisa-manifest`
4. Check the project's working directory is clean: `git -C <project-path> status --porcelain`
   - If dirty, tell the user and stop: "The project has uncommitted changes. Please commit or stash them first."

### Step 2: Record Baseline

Before applying Lisa, record the project's current state:

1. Read `<project-path>/.lisa-manifest` to note the current Lisa version
2. Run `git -C <project-path> log --oneline -1` to note the current HEAD
3. Note the project's branch and whether there's an open PR: `git -C <project-path> branch --show-current`

### Step 3: Apply Lisa

Run from the Lisa directory:

```bash
bun run dev <project-path>
```

If Lisa fails, report the error and stop.

### Step 4: Check What Changed

Run `git -C <project-path> status --short` to see what Lisa modified.

If nothing changed, report "Lisa applied cleanly with no changes" and stop.

### Step 5: Verify the Project

Run the project's verification commands in order. Stop at the first failure:

1. **Typecheck**: `cd <project-path> && bun run typecheck` (or `npm run typecheck` based on package manager)
2. **Lint**: `cd <project-path> && bun run lint` (or equivalent)
3. **Test**: `cd <project-path> && bun run test` (or equivalent)

Determine the package manager by checking which lockfile exists:
- `bun.lockb` → bun
- `pnpm-lock.yaml` → pnpm
- `yarn.lock` → yarn
- `package-lock.json` → npm

### Step 6: Handle Failures

If any verification step fails:

1. **Diagnose**: Analyze the error output to determine root cause
2. **Determine fix location**:
   - If the fix belongs in Lisa templates (the upstream change broke something), fix it in Lisa and go to Step 6a
   - If the fix belongs in the project's `*.local.*` files (project-specific override needed), fix it in the project and go to Step 6b
3. **Report** what failed and what you're fixing

#### Step 6a: Fix Upstream in Lisa

1. Make the fix in the Lisa template files
2. Run Lisa's own checks: `bun run typecheck && bun run lint && bun run test`
3. If Lisa's checks pass, go back to **Step 3** (re-apply Lisa to the project)
4. If Lisa's checks fail, fix those too, then retry

#### Step 6b: Fix in Project Local Files

1. Make the fix in the project's local override files (e.g., `tsconfig.local.json`, `eslint.config.local.ts`, `jest.config.local.ts`)
2. Go to **Step 5** (re-verify the project)

### Step 7: Commit and Push

Once all verification passes:

1. Stage all changes in the project: `git -C <project-path> add <changed-files>`
2. Commit with message: `chore: apply Lisa <version> templates`
3. Push to the project's remote
4. If upstream Lisa changes were made, commit and push those too

### Step 8: Report Results

Output a summary:

```
## Lisa Integration Test: PASSED

**Project:** <project-path>
**Lisa version:** <version>
**Branch:** <branch>

### Changes Applied
- <list of changed files>

### Verification
- Typecheck: PASSED
- Lint: PASSED
- Tests: PASSED

### Upstream Fixes (if any)
- <list of Lisa template fixes made>

### Commits
- <project-commit-hash> chore: apply Lisa <version> templates
- <lisa-commit-hash> fix: <description> (if upstream fixes were needed)
```

## Important Notes

- **Never skip verification** — the whole point is proving it works empirically
- **Fix upstream when possible** — if Lisa broke something, fix the template, not the project
- **Use local overrides for project-specific needs** — `tsconfig.local.json`, `eslint.config.local.ts`, etc.
- **Retry loop is bounded** — if you've tried 3 fix-and-retry cycles without success, stop and report the situation to the user
- **Preserve project conventions** — check the project's commit message style before committing

Overview

This skill runs an end-to-end integration test that applies Lisa templates to a downstream project and verifies the project still builds. It automatically detects failures, guides whether to fix templates upstream in Lisa or apply project-local overrides, and retries until checks pass or a retry limit is reached. Use it from within the Lisa repository directory.

How this skill works

The skill validates that it is running from the Lisa repo and that the target project is clean and already has a .lisa-manifest. It applies Lisa to the target project, inspects git to see what changed, then runs the project's typecheck, lint, and test commands using the appropriate package manager. On failure it diagnoses whether to fix Lisa templates upstream or to add project-local overrides, applies fixes, reruns checks, and repeats up to a bounded retry limit.

When to use it

  • When validating that Lisa template changes do not break a downstream repository.
  • Before releasing a new Lisa template version or merging template changes.
  • When onboarding a project to Lisa to ensure templates integrate cleanly.
  • When debugging a downstream build or lint regression after template updates.

Best practices

  • Run this from the Lisa repo root (verify src/core/lisa.ts exists).
  • Ensure the target project has a clean working tree and contains .lisa-manifest.
  • Determine package manager by lockfile to run the correct verification commands.
  • Prefer fixing Lisa templates upstream when the change is generic; use local overrides only for project-specific needs.
  • Limit automated fix-and-retry cycles (stop after three attempts) and report unresolved issues.

Example use cases

  • Apply a new Lisa template change and confirm downstream typechecking, linting, and tests still pass.
  • Detect and fix a template regression introduced by a refactor in Lisa, then reapply to the project.
  • Validate that adding a new lint rule in Lisa does not break a downstream repo, or provide a local override when necessary.
  • Automate the pre-merge verification step to prevent template changes from landing that break consumers.

FAQ

Where must I run this skill from?

Run it from the Lisa repository root so the tool can locate src/core/lisa.ts and run bun run dev against the target project.

What happens if the project has uncommitted changes?

The process stops and instructs you to commit or stash changes. The target project must have a clean working directory before applying templates.