@codyswann/lisa 1.67.2 → 1.68.0

package/plugins/lisa/skills/security-review/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: security-review
+description: "Security review methodology. STRIDE threat modeling, OWASP Top 10 vulnerability checks, auth/validation/secrets handling review, and mitigation recommendations."
+---
+
+# Security Review
+
+Identify vulnerabilities, evaluate threats, and recommend mitigations for code changes.
+
+## Analysis Process
+
+1. **Read affected files** -- understand current security posture of the code being changed
+2. **STRIDE analysis** -- evaluate Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege risks
+3. **Check input validation** -- are user inputs sanitized at system boundaries?
+4. **Check secrets handling** -- are credentials, tokens, or API keys exposed in code, logs, or error messages?
+5. **Check auth/authz** -- are access controls properly enforced for new endpoints or features?
+6. **Review dependencies** -- do new dependencies introduce known vulnerabilities?
+
+## Output Format
+
+Structure findings as:
+
+```
+## Security Analysis
+
+### Threat Model (STRIDE)
+| Threat | Applies? | Description | Mitigation |
+|--------|----------|-------------|------------|
+| Spoofing | Yes/No | ... | ... |
+| Tampering | Yes/No | ... | ... |
+| Repudiation | Yes/No | ... | ... |
+| Info Disclosure | Yes/No | ... | ... |
+| Denial of Service | Yes/No | ... | ... |
+| Elevation of Privilege | Yes/No | ... | ... |
+
+### Security Checklist
+- [ ] Input validation at system boundaries
+- [ ] No secrets in code or logs
+- [ ] Auth/authz enforced on new endpoints
+- [ ] No SQL/NoSQL injection vectors
+- [ ] No XSS vectors in user-facing output
+- [ ] Dependencies free of known CVEs
+
+### Vulnerabilities Found
+- [vulnerability] -- where in the code, how to prevent
+
+### Recommendations
+- [recommendation] -- priority (critical/warning/suggestion)
+```
+
+## Rules
+
+- Focus on the specific changes proposed, not a full security audit of the entire codebase
+- Flag only real risks -- do not invent hypothetical threats for internal tooling with no user input
+- Prioritize OWASP Top 10 vulnerabilities
+- If the changes are purely internal (config, refactoring, docs), report "No security concerns" and explain why
+- Always check `.gitleaksignore` patterns to understand what secrets scanning is already in place

package/plugins/lisa/skills/task-decomposition/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: task-decomposition
+description: "Methodology for breaking work into ordered tasks. Each task gets acceptance criteria, verification type, dependencies, and skills required."
+---
+
+# Task Decomposition
+
+Break work into ordered, well-scoped tasks that can be independently implemented and verified.
+
+## Decomposition Process
+
+### 1. Identify Units of Work
+
+- Break the work into the smallest units that are independently valuable
+- Each unit should produce a verifiable outcome (a passing test, a working endpoint, observable behavior)
+- Avoid tasks that are too large to complete in a single session
+- Avoid tasks that are too small to be meaningful (e.g., "add an import statement")
+
+### 2. Define Acceptance Criteria
+
+For each task, define what "done" looks like:
+
+- Be specific and measurable -- avoid vague criteria like "works correctly"
+- Include both positive cases (what should work) and negative cases (what should be rejected)
+- Reference exact behavior: error messages, status codes, output format, performance thresholds
+- If a task modifies existing behavior, state both the before and after
+
+### 3. Assign Verification Type
+
+Each task must have a verification method. Choose the most appropriate:
+
+| Verification Type | When to Use |
+|-------------------|-------------|
+| **Unit test** | Pure logic, data transformations, utility functions |
+| **Integration test** | Cross-module interactions, database operations, API contracts |
+| **E2E test** | User-facing workflows, multi-service interactions |
+| **Manual verification** | UI/UX behavior, visual correctness, one-time infrastructure changes |
+| **Build verification** | Compilation, type checking, linting, bundle size |
+| **Deploy verification** | Service health checks, smoke tests, monitoring dashboards |
+
+### 4. Map Dependencies
+
+- Identify which tasks must complete before others can start
+- Order tasks so that each builds on a stable foundation
+- Prefer independent tasks that can run in parallel where possible
+- Flag external dependencies (other teams, services, permissions, data) that may block progress
+
+### 5. Determine Execution Order
+
+- Place foundational tasks first (types, schemas, interfaces, shared utilities)
+- Follow with implementation tasks (business logic, handlers, services)
+- Then integration tasks (wiring, configuration, API routes)
+- Finish with verification tasks (test suites, documentation, cleanup)
+
+### 6. Assign Required Skills
+
+Map each task to the skills needed to complete it. This enables delegation to specialized agents or helps identify what expertise is required.
+
+## Output Format
+
+```
+## Task Breakdown
+
+### Task 1: [imperative description]
+- **Acceptance criteria:**
+  - [specific, measurable criterion]
+  - [specific, measurable criterion]
+- **Verification:** [type] -- [how to verify]
+- **Dependencies:** [none | task IDs that must complete first]
+- **Skills:** [list of skills needed]
+
+### Task 2: [imperative description]
+- **Acceptance criteria:**
+  - [specific, measurable criterion]
+- **Verification:** [type] -- [how to verify]
+- **Dependencies:** [Task 1]
+- **Skills:** [list of skills needed]
+
+### Execution Order
+1. [Task 1, Task 3] (parallel -- no dependencies)
+2. [Task 2] (depends on Task 1)
+3. [Task 4] (depends on Task 2, Task 3)
+
+### External Dependencies
+- [dependency] -- [who owns it] -- [current status]
+```
+
+## Rules
+
+- Every task must have at least one acceptance criterion that can be empirically verified
+- Do not create tasks that cannot be verified -- if you cannot define how to prove it is done, the task is not well-scoped
+- Keep tasks ordered so that no task references work that has not been completed by a prior task
+- Flag any task that requires access, permissions, or external input not yet available
+- Prefer more small tasks over fewer large tasks -- smaller tasks are easier to verify and less risky to fail
+- Do not create placeholder or "TODO" tasks -- every task should describe concrete work

package/plugins/lisa/skills/task-triage/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: task-triage
+description: "8-step task triage and implementation workflow. Ensures tasks have clear requirements, dependencies, and verification plans before implementation begins."
+---
+
+# Task Triage
+
+Follow this 8-step triage process before implementing any task. Do not skip triage.
+
+## Triage Steps
+
+1. Verify you have all information needed to implement this task (acceptance criteria, design specs, environment information, dependencies, etc.). Do not make assumptions. If anything is missing, stop and ask before proceeding.
+2. Verify you have a clear understanding of the expected behavior or outcome when the task is complete. If not, stop and clarify before starting.
+3. Identify all dependencies (other tasks, services, APIs, data) that must be in place before you can complete this task. If any are unresolved, stop and raise them before starting implementation.
+4. Verify you have access to the tools, environments, and permissions needed to deploy and verify this task (e.g. CI/CD pipelines, deployment targets, logging/monitoring systems, API access, database access). If any are missing or inaccessible, stop and raise them before starting implementation.
+5. Define the tests you will write to confirm the task is implemented correctly and prevent regressions.
+6. Define the documentation you will create or update to explain the "how" and "what" behind this task so another developer understands it.
+7. If you can verify your implementation before deploying to the target environment (e.g. start the app, invoke the API, open a browser, run the process, check logs), do so before deploying.
+8. Define how you will verify the task is complete beyond a shadow of a doubt (e.g. deploy to the target environment, invoke the API, open a browser, run the process, check logs).
+
+## Implementation
+
+Use the output of the triage steps above as your guide. Do not skip triage.

package/plugins/lisa/skills/tdd-implementation/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: tdd-implementation
+description: "Test-Driven Development implementation workflow. RED: write failing test, GREEN: minimum code to pass, REFACTOR: clean up. Includes task metadata requirements, verification, and atomic commit practices."
+---
+
+# TDD Implementation
+
+Implement code changes using the Test-Driven Development (RED/GREEN/REFACTOR) cycle. This skill defines the complete workflow from task metadata validation through atomic commit.
+
+## Task Metadata
+
+Each task you work on must have the following in its metadata:
+
+```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"
+  }
+}
+```
+
+All fields are mandatory — empty arrays are ok. If any are missing, ask the agent team to fill them in and wait to get a response.
+
+## Workflow
+
+1. **Verify task metadata** — All fields are mandatory. If any are missing, ask the agent team to fill them in and wait to get a response.
+2. **Load skills** — Load the skills in the `skills` property of the task metadata.
+3. **Read before writing** — Read existing code before modifying it. Understand acceptance criteria, verification, and relevant research.
+4. **Follow existing patterns** — Match the style, naming, and structure of surrounding code.
+5. **One task at a time** — Complete the current task before moving on.
+6. **RED** — Write a failing test that captures the expected behavior from the task description. Focus on testing behavior, not implementation details.
+7. **GREEN** — Write the minimum production code to make the test pass.
+8. **REFACTOR** — Clean up while keeping tests green.
+9. **Verify empirically** — Run the task's proof command and confirm expected output.
+10. **Update documentation** — Add/Remove/Modify all relevant JSDoc preambles, explaining "why", not "what".
+11. **Update the learnings** — Add what you learned during implementation to the `learnings` array in the task's `metadata.learnings`. These should be things that are relevant for other implementers to know.
+12. **Commit atomically** — Once verified, run the `/git-commit` skill.
+
+## TDD Cycle
+
+**Always write failing tests before implementation code.** This is mandatory, not optional.
+
+```text
+TDD Cycle:
+1. RED: Write a failing test that defines expected behavior
+2. GREEN: Write the minimum code to make the test pass
+3. REFACTOR: Clean up while keeping tests green
+```
+
+### RED Phase
+
+- Write a test that captures the expected behavior from the task description
+- Focus on testing behavior, not implementation details
+- The test must fail before you write any production code
+- If the imported module doesn't exist, Jest reports 0 tests found (not N failed) — this is expected RED behavior
+
+### GREEN Phase
+
+- Write the minimum production code to make the test pass
+- Do not optimize, do not add features beyond what the test requires
+- The goal is the simplest code that makes the test green
+
+### REFACTOR Phase
+
+- Clean up code while keeping all tests green
+- Remove duplication, improve naming, simplify structure
+- Run tests after every refactor step to confirm nothing breaks
+
+## When Stuck
+
+- Re-read the task description and acceptance criteria
+- Check relevant research for reusable code references
+- Search the codebase for similar implementations
+- Ask the team lead if the task is ambiguous — do not guess

package/plugins/lisa/skills/test-strategy/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: test-strategy
+description: "Test strategy design. Coverage matrix, edge cases, TDD sequence planning, test quality review. Behavior-focused testing over implementation details."
+---
+
+# Test Strategy
+
+Design test strategies, write tests, and review test quality.
+
+## Analysis Process
+
+1. **Read existing tests** -- understand the project's test conventions (describe/it structure, naming, helpers)
+2. **Identify test types needed** -- unit, integration, E2E based on the scope of changes
+3. **Map edge cases** -- boundary values, empty inputs, error states, concurrency scenarios
+4. **Check coverage gaps** -- run existing tests to understand current coverage of affected files
+5. **Design verification commands** -- proof commands that empirically demonstrate the code works
+
+## Test Writing Process
+
+1. **Analyze the source file** to understand its functionality
+2. **Identify untested code paths**, edge cases, and error conditions
+3. **Write comprehensive, meaningful tests** (not just coverage padding)
+4. **Follow the project's existing test patterns** and conventions
+5. **Ensure tests are readable and maintainable**
+
+## Output Format
+
+Structure findings as:
+
+```text
+## Test Analysis
+
+### Test Matrix
+| Component | Test Type | What to Test | Priority |
+|-----------|-----------|-------------|----------|
+
+### Edge Cases
+- [edge case] -- why it matters
+
+### Coverage Targets
+- `path/to/file.ts` -- current: X%, target: Y%
+
+### Test Patterns (from codebase)
+- Pattern: [description] -- found in `path/to/test.spec.ts`
+
+### Verification Commands
+| Task | Proof Command | Expected Output |
+|------|--------------|-----------------|
+
+### TDD Sequence
+1. [first test to write] -- covers [behavior]
+2. [second test] -- covers [behavior]
+```
+
+## Rules
+
+- Always run `bun run test` to understand current test state before recommending or writing new tests
+- Match existing test conventions -- do not introduce new test patterns
+- Every test must have a clear "why" -- no tests for testing's sake
+- Focus on testing behavior, not implementation details
+- Verification commands must be runnable locally (no CI/CD dependencies)
+- Prioritize tests that catch regressions over tests that verify happy paths
+- Write comprehensive tests, not just coverage padding

package/plugins/lisa/skills/verification-lifecycle/SKILL.md

@@ -0,0 +1,292 @@
+---
+name: verification-lifecycle
+description: "Verification lifecycle: classify types, discover tools, fail fast, plan, execute, loop. Includes verification surfaces, proof artifacts, self-correction loop, escalation protocol, and definition of done."
+---
+
+# Verification Lifecycle
+
+This skill defines the complete verification lifecycle that agents must follow for every change: classify, check tooling, fail fast, plan, execute, and loop.
+
+## Verification Lifecycle
+
+Agents must follow this mandatory sequence for every change:
+
+### 1. Classify
+
+Determine which verification types apply based on the change. Start with the three always-required types (Test, Type Safety, Lint/Format), then check each conditional type against the change scope.
+
+### 2. Check Tooling
+
+For each required verification type, discover what tools are available in the project. Use the Tool Discovery Process below.
+
+Report what is available for each required type. If a required type has no available tool, proceed to step 3.
+
+### 3. Fail Fast
+
+If a required verification type has no available tool and no reasonable alternative, escalate immediately using the Escalation Protocol. Do not begin implementation without a verification plan for every required type.
+
+### 4. Plan
+
+For each verification type, state:
+- The specific tool or command that will be used
+- The expected outcome that constitutes a pass
+- Any prerequisites (running server, seeded database, auth token)
+
+### 5. Execute
+
+After implementation, run the verification plan. Execute each verification type in order.
+
+### 6. Loop
+
+If any verification fails, fix the issue and re-verify. Do not declare done until all required types pass. If a verification is stuck after 3 attempts, escalate.
+
+---
+
+## Tool Discovery Process
+
+Agents must discover available tools at runtime rather than assuming what exists. Check these locations in order:
+
+1. **Project manifest** — Read the project manifest file for available scripts (build, test, lint, deploy, start, etc.) and their variants
+2. **Script directories** — Search for shell scripts, automation files, and task runners in common locations (`scripts/`, `bin/`, project root)
+3. **Configuration files** — Look for test framework configs, linter configs, formatter configs, deployment configs, and infrastructure-as-code definitions
+4. **MCP tools** — Check available MCP server tools for browser automation, observability, issue tracking, and other capabilities
+5. **CLI tools** — Check for available command-line tools relevant to the verification type (database clients, HTTP clients, cloud CLIs, container runtimes)
+6. **Environment files** — Read environment configuration for service URLs, connection strings, and feature flags that indicate available services
+7. **Documentation** — Check project README, CLAUDE.md, and rules files for documented verification procedures
+
+If a tool is expected but not found, report the gap rather than assuming it doesn't exist — it may need to be installed or configured.
+
+---
+
+## Verification Surfaces
+
+Agents may only self-verify when the required verification surfaces are available.
+
+Verification surfaces include:
+
+### Action Surfaces
+
+- Build and test execution
+- Deployment and rollback
+- Infrastructure apply and drift detection
+- Feature flag toggling
+- Data seeding and state reset
+- Load generation and fault injection
+
+### Observation Surfaces
+
+- Application logs (local and remote)
+- Metrics (latency, errors, saturation, scaling)
+- Traces and correlation IDs
+- Database queries and schema inspection
+- Browser and device automation
+- Queue depth and consumer execution visibility
+- CDN headers and edge behavior
+- Artifact capture (video, screenshots, traces, diffs)
+
+If a required surface is unavailable, agents must follow the Escalation Protocol.
+
+---
+
+## Tooling Surfaces
+
+Many verification steps require tools that may not be available by default.
+
+Tooling surfaces include:
+
+- Required CLIs (cloud, DB, deployment, observability)
+- Required MCP servers and their capabilities
+- Required internal APIs (feature flags, auth, metrics, logs, CI)
+- Required credentials and scopes for those tools
+
+If required tooling is missing, misconfigured, blocked, undocumented, or inaccessible, agents must treat this as a verification blocker and escalate before proceeding.
+
+---
+
+## Proof Artifacts Requirements
+
+Every completed task must include proof artifacts stored in the PR description or linked output location.
+
+Proof artifacts must be specific and re-checkable. A proof artifact should contain enough detail that another agent or human can reproduce the verification independently.
+
+Acceptable proof includes:
+- Automated session recordings and screenshots for UI work
+- Request/response captures for API work
+- Before/after query outputs for data work
+- Metrics snapshots for performance and scaling work
+- Log excerpts with correlation IDs for behavior validation
+- Benchmark results with methodology for performance work
+
+Statements like "works" or "should work" are not acceptable.
+
+---
+
+## Self-Correction Loop
+
+Verification is not a one-shot activity. Agents operate within a three-layer self-correction architecture that catches errors at increasing scope. Each layer is enforced automatically — agents do not need to invoke them manually.
+
+### Layer 1 — Inline Correction
+
+**Trigger:** Every file write or edit.
+
+Hooks run formatting, structural analysis, and linting on the single file just written. Errors are reported immediately so the agent can fix them before writing more files. This prevents error accumulation across multiple files.
+
+**Agent responsibility:** When a hook blocks, fix the reported errors in the same file before proceeding to other files. Do not accumulate errors.
+
+### Layer 2 — Commit-Time Enforcement
+
+**Trigger:** Every commit.
+
+Checks run on staged files: linting, formatting, secret detection, commit message validation, and branch protection. This layer catches errors that span multiple files or involve staged-but-not-yet-checked changes.
+
+Commit-time checks cannot be bypassed. Agents must discover what specific checks are enforced by reading the project's hook configuration.
+
+### Layer 3 — Push-Time Enforcement
+
+**Trigger:** Every push.
+
+The full project quality gate runs: test suites with coverage thresholds, type checking, security audits, unused export detection, and integration tests. This is the last automated checkpoint before code reaches the remote.
+
+**Handling failures:** When a push fails, read the error output to determine which check failed. Fix the root cause rather than working around it. Agents must discover what specific checks are enforced by reading the project's hook configuration.
+
+### Regeneration Over Patching
+
+When the root cause of errors is architectural (wrong abstraction, incorrect data flow, fundamentally broken approach), delete and regenerate rather than incrementally patching. Incremental patches on a broken foundation accumulate tech debt faster than the self-correction loop can catch it.
+
+Signs that regeneration is needed:
+- The same file has been edited 3+ times in the same loop without converging
+- Fixing one error introduces another in the same file
+- The fix requires disabling a lint rule or adding a type assertion
+
+---
+
+## Standard Workflow
+
+Agents must follow this sequence unless explicitly instructed otherwise:
+
+1. Restate goal in one sentence.
+2. Identify the end user of the change.
+3. Classify verification types that apply to the change.
+4. Discover available tools for each verification type.
+5. Confirm required surfaces are available, escalate if not.
+6. Plan verification: state tool, command, and expected outcome for each type.
+7. Implement the change.
+8. Execute verification plan.
+9. Collect proof artifacts.
+10. Summarize what changed, what was verified, and remaining risk.
+11. Label the result with a verification level.
+
+---
+
+## Task Completion Rules
+
+1. **Run the proof command** before marking any task complete
+2. **Compare output** to expected result
+3. **If verification fails**: Fix and re-run, don't mark complete
+4. **If verification blocked** (missing tools, services, etc.): Mark as blocked, not complete
+5. **Must not be dependent on CI/CD** if necessary, you may use local deploy methods found in the project manifest, but the verification methods must be listed in the pull request and therefore cannot be dependent on CI/CD completing
+
+---
+
+## Escalation Protocol
+
+Agents must escalate when verification is blocked, ambiguous, or requires tools that are missing or inaccessible.
+
+Common blockers:
+
+- VPN required
+- MFA, OTP, SMS codes
+- Hardware token requirement
+- Missing CLI, MCP server, or internal API required for verification
+- Missing documentation on how to access required tooling
+- Production-only access gates
+- Compliance restrictions
+
+When blocked, agents must do the following:
+
+1. Identify the exact boundary preventing verification.
+2. Identify which verification surfaces and tooling surfaces are missing.
+3. Attempt safe fallback verification (local, staging, mocks) and label it clearly.
+4. Declare verification level as PARTIALLY VERIFIED or UNVERIFIED.
+5. Produce a Human Action Packet.
+6. Pause until explicit human confirmation or tooling is provided.
+
+Agents must never proceed past an unverified boundary without surfacing it to the human overseer.
+
+### Human Action Packet Format
+
+Agents must provide:
+
+- What is blocked and why
+- What tool or access is missing
+- Exactly what the human must do
+- How to confirm completion
+- What the agent will do immediately after
+- What artifacts the agent will produce after access is restored
+
+Example:
+
+- Blocked: Cannot reach DB, VPN required.
+- Missing: Database client access to `db.host` and internal logs viewer.
+- Human steps: Connect VPN "CorpVPN", confirm access by running connectivity check to `db.host`, provide credentials or endpoint.
+- Confirmation: Reply "VPN ACTIVE" and "ACCESS READY".
+- Next: Agent runs migration verification script and captures schema diff and query outputs.
+
+Agents must pause until explicit human confirmation.
+
+Agents must never bypass security controls to proceed.
+
+---
+
+## Environments and Safety Rules
+
+### Allowed Environments
+
+- Local development
+- Preview environments
+- Staging
+- Production read-only, only if explicitly approved and configured for safe access
+
+### Prohibited Actions Without Human Approval
+
+- Writing to production data stores
+- Disabling MFA or security policies
+- Modifying IAM roles or firewall rules beyond scoped change requests
+- Running destructive migrations
+- Triggering external billing or payment flows
+
+If an operation is irreversible or risky, escalate first.
+
+---
+
+## Artifact Storage and PR Requirements
+
+Every PR must include:
+
+- Goal summary
+- Verification level
+- Proof artifacts links or embedded outputs
+- How to reproduce verification locally
+- Known limitations and follow-up items
+
+Preferred artifact locations:
+
+- PR description
+- Repo-local scripts under `scripts/verification/`
+- CI artifacts linked from the build
+
+---
+
+## Definition of Done
+
+A task is done only when:
+
+- End user is identified
+- All applicable verification types are classified and executed
+- Verification lifecycle is completed (classify, check tooling, plan, execute, loop)
+- Required verification surfaces and tooling surfaces are used or explicitly unavailable
+- Proof artifacts are captured
+- Verification level is declared
+- Risks and gaps are documented
+
+If any of these are missing, the work is not complete.

package/plugins/lisa-cdk/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "1.67.2",
+  "version": "1.68.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "1.67.2",
+  "version": "1.68.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "1.67.2",
+  "version": "1.68.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "1.67.2",
+  "version": "1.68.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "1.67.2",
+  "version": "1.68.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"