@codyswann/lisa 1.11.11 → 1.12.1

package/README.md

@@ -86,26 +86,21 @@ Lisa is designed for a **two-tier organizational model** that separates AI exper
 
 ### How Implementation Teams Work
 
-Once Lisa is applied to a project, developers have two paths:
+Once Lisa is applied to a project, developers use a simple workflow:
 
-**Path 1: Just Type a Prompt**
+**Simple Requests**
 
-Even if a developer just types a vague request, Lisa's built-in `prompt-complexity-scorer` skill automatically evaluates it:
+For straightforward tasks, just describe what you need:
 
 ```
-Developer: "Make the app faster"
+Developer: "Fix the typo in the login error message"
 
-Claude: This request scores 8/10 on complexity. I suggest writing it
-        as a spec to plan it out properly.
-
-        Would you like me to create `specs/performance-optimization.md`?
+Claude: [Immediately fixes the typo with proper verification]
 ```
 
-Complex or vague prompts (score 5+) are automatically routed to the spec workflow. Simple, well-defined requests (score 1-4) proceed immediately. Developers don't need to know which path to take—Lisa routes them automatically.
-
-**Path 2: The Full Workflow**
+**Complex Work: The Full Workflow**
 
-For planned work, the workflow is two commands:
+For larger features or complex changes, use the spec-driven workflow:
 
 ```bash
 # 1. Create a spec file describing what you want
@@ -1198,8 +1193,6 @@ Publish Claude Code skills, commands, and agents as installable plugins via the
 - Community registry: [claude-plugins.dev](https://claude-plugins.dev/)
 
 **Lisa Components That Could Become Plugins:**
-- `coding-philosophy` skill - Teachable immutability and function structure patterns
-- `prompt-complexity-scorer` skill - Request complexity evaluation
 - `jsdoc-best-practices` skill - Documentation standards
 - `project:*` commands - Implementation workflows
 - Custom agents (skill-evaluator, codebase-analyzer)

package/all/copy-overwrite/.claude/README.md

@@ -126,8 +126,7 @@ Skills in `skills/` provide domain-specific knowledge:
 
 | Skill | Purpose |
 |-------|---------|
-| `coding-philosophy/` | Core coding principles |
-| `prompt-complexity-scorer/` | Task complexity evaluation |
+| `jsdoc-best-practices/` | JSDoc documentation standards |
 | `skill-creator/` | Creating new skills |
 
 See each skill's `SKILL.md` for detailed documentation.

package/all/copy-overwrite/CLAUDE.md

@@ -4,7 +4,6 @@ CRITICAL RULES:
 
 Always output "I'm tired boss" before starting any task, request or anything else.
 Always figure out the Package manager the project uses: !`ls package-lock.json yarn.lock pnpm-lock.yaml bun.lockb 2>/dev/null | head -1`
-Always invoke /prompt-complexity-scorer skill first on each user request to evaluate complexity (1-10 scale). For scores 5+, suggest writing to specs/<spec-name>.md before proceeding.
 Always invoke /jsdoc-best-practices skill when writing or reviewing JSDoc documentation to ensure "why" over "what" and proper tag usage
 Always read @package.json without limit or offset to understand what scripts and third party packages are used
 Always read @eslint.config.ts without limit or offset to understand this project's linting standards

package/all/deletions.json

@@ -1,5 +1,6 @@
 {
   "paths": [
-    ".claude/skills/coding-philosophy"
+    ".claude/skills/coding-philosophy",
+    ".claude/skills/prompt-complexity-scorer"
   ]
 }

package/cdk/package-lisa/package.lisa.json

@@ -2,18 +2,18 @@
   "force": {
     "scripts": {
       "watch": "tsc -w",
-      "cdk": "cdk"
+      "cdk": "cdk",
+      "build": "tsc --noEmit"
     },
     "dependencies": {
       "@aws-cdk/aws-amplify-alpha": "^2.235.0-alpha.0",
       "aws-cdk-github-oidc": "^2.4.1",
       "aws-cdk-lib": "2.235.0",
       "constructs": "^10.4.5",
-      "lodash": "^4.17.21",
       "source-map-support": "^0.5.21"
     },
     "devDependencies": {
-      "aws-cdk": "2.235.0"
+      "aws-cdk": "^2.1104.0"
     },
     "bin": {
       "infrastructure": "bin/infrastructure.js"

package/package.json

@@ -18,7 +18,7 @@
     "knip:fix": "knip --fix",
     "sg:scan": "ast-grep scan",
     "build": "tsc",
-    "prepare": "tsc || husky install || true",
+    "prepare": "$npm_execpath run build || husky install || true",
     "lisa:update": "npx @codyswann/lisa@latest .",
     "start": "node dist/index.js",
     "dev": "tsx src/index.ts",
@@ -74,7 +74,7 @@
   },
   "resolutions": {},
   "name": "@codyswann/lisa",
-  "version": "1.11.11",
+  "version": "1.12.1",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "bin": {

package/typescript/package-lisa/package.lisa.json

@@ -15,7 +15,7 @@
       "knip:fix": "knip --fix",
       "sg:scan": "ast-grep scan",
       "build": "tsc",
-      "prepare": "tsc || husky install || true",
+      "prepare": "$npm_execpath run build || husky install || true",
       "lisa:update": "npx @codyswann/lisa@latest ."
     },
     "devDependencies": {
@@ -50,6 +50,7 @@
       "knip": "^5.0.0",
       "@ast-grep/cli": "^0.40.4",
       "@jest/test-sequencer": "^30.2.0",
+      "@jest/globals": "^30.0.0",
       "@types/jest": "^30.0.0",
       "jest": "^30.0.0",
       "ts-jest": "^29.4.6"

package/all/copy-overwrite/.claude/skills/prompt-complexity-scorer/SKILL.md

@@ -1,164 +0,0 @@
----
-name: prompt-complexity-scorer
-description: Evaluates user prompts for effort and complexity on a 1-10 scale. This skill should be invoked on every user request to determine if the request warrants planning via a project. For scores 5-10, the agent suggests creating a project at projects/<date>-<project-name>/ to enable task tracking and team collaboration.
-model: haiku
----
-
-# Prompt Complexity Scorer
-
-This skill evaluates user prompts to determine if they require planning before implementation.
-
-## Skip Evaluation
-
-**Do not evaluate** prompts that are explicit slash command invocations. If the user's prompt starts with `/`, they are already invoking a workflow and no complexity scoring is needed.
-
-Examples of prompts to **skip** (just execute the command):
-- `/project:bootstrap @specs/add-auth.md`
-- `/git:commit`
-- `/project:implement @projects/2026-01-26-feature`
-
-Examples of prompts to **evaluate**:
-- "Add WebSocket support to this project"
-- "Make the app faster"
-- "Refactor the authentication system"
-
-## Scoring Criteria
-
-Score each prompt on a 1-10 scale based on these factors:
-
-| Factor | Low (1-3) | Medium (4-6) | High (7-10) |
-|--------|-----------|--------------|-------------|
-| **Scope** | Single file/function | Multiple files/module | Multiple systems/services |
-| **Clarity** | Specific, well-defined | Some ambiguity | Vague, open-ended |
-| **Dependencies** | None or obvious | Some coordination | Multiple unknown deps |
-| **Unknowns** | None | Some research needed | Significant discovery |
-| **Risk** | Low/reversible | Moderate | High/architectural |
-
-### Score Calculation
-
-1. Evaluate each factor independently
-2. Average the factor scores
-3. Round to nearest integer
-
-## Behavior by Score
-
-### Score 1-4: Continue Normally
-
-Do not mention the scoring. Proceed with the request immediately.
-
-### Score 5-10: Suggest Project
-
-Pause and ask the user:
-
-```text
-This request scores [X]/10 on complexity. I suggest creating a project to track this work properly.
-
-Would you like me to create `projects/<date>-<suggested-name>/` with a brief.md?
-```
-
-Where `<date>` is today's date in YYYY-MM-DD format and `<suggested-name>` is a kebab-case name derived from the request (e.g., "2026-01-24-add-websockets", "2026-01-24-refactor-auth-system").
-
-## Project Setup
-
-When creating a project, create the directory structure and brief.md:
-
-```bash
-# Get today's date
-DATE=$(date +%Y-%m-%d)
-mkdir -p projects/${DATE}-<suggested-name>/tasks
-```
-
-```markdown
-# <Title derived from prompt>
-
-## Original Request
-
-<User's exact prompt/request>
-
-## Goals
-
-<Bullet points summarizing what needs to be accomplished>
-
-## Notes
-
-<Any additional context or constraints mentioned>
-```
-
-After creating the project, inform the user:
-
-```text
-Project created at `projects/<date>-<suggested-name>/`.
-
-You can now:
-- Run `/project:bootstrap @projects/<date>-<suggested-name>` for full research and planning
-- Or continue with the request and tasks will be tracked in this project
-```
-
-**IMPORTANT**: After creating the project, set the active project context by creating a marker file:
-
-```bash
-echo "${DATE}-<suggested-name>" > .claude-active-project
-```
-
-This enables automatic task syncing to the project directory.
-
-## Examples
-
-### Example 1: Simple Request (Score 1)
-
-**Prompt**: "Fix the typo in the error message on line 45 of user.service.ts"
-
-**Factors**:
-- Scope: 1 (single line)
-- Clarity: 1 (exact location specified)
-- Dependencies: 1 (none)
-- Unknowns: 1 (none)
-- Risk: 1 (trivial change)
-
-**Score**: 1 → Continue normally
-
-### Example 2: Complex Request (Score 7)
-
-**Prompt**: "Add WebSocket support to this project"
-
-**Factors**:
-- Scope: 8 (new system, multiple files)
-- Clarity: 6 (what kind of WebSocket? real-time features?)
-- Dependencies: 7 (infrastructure, client changes)
-- Unknowns: 7 (architecture decisions needed)
-- Risk: 7 (architectural change)
-
-**Score**: 7 → Suggest creating `projects/YYYY-MM-DD-add-websockets/`
-
-### Example 3: Medium Request (Score 3)
-
-**Prompt**: "Add a new field 'nickname' to the User entity"
-
-**Factors**:
-- Scope: 4 (entity, migration, possibly resolvers)
-- Clarity: 2 (clear requirement)
-- Dependencies: 3 (migration, schema)
-- Unknowns: 2 (standard pattern)
-- Risk: 3 (database change but reversible)
-
-**Score**: 3 → Continue normally
-
-### Example 4: Nebulous Request (Score 8)
-
-**Prompt**: "Make the app faster"
-
-**Factors**:
-- Scope: 9 (entire application)
-- Clarity: 9 (completely vague)
-- Dependencies: 8 (unknown until investigated)
-- Unknowns: 9 (what's slow? why?)
-- Risk: 6 (depends on changes)
-
-**Score**: 8 → Suggest creating `projects/YYYY-MM-DD-performance-optimization/`
-
-## Important Notes
-
-- This evaluation should be quick and silent for low-complexity requests
-- Never mention the scoring system for scores 1-4
-- For borderline cases (score 4-5), lean toward continuing normally
-- The goal is to catch truly complex/nebulous requests that benefit from planning

package/nestjs/copy-overwrite/.github/workflows/k6-load-test-README.md

@@ -1,230 +0,0 @@
-# K6 Load Testing Workflow
-
-## Overview
-
-The `k6-load-test.yml` is a reusable GitHub Actions workflow designed to run k6 performance tests as part of your CI/CD pipeline. It supports multiple test scenarios, flexible configuration, and both local and cloud execution.
-
-## Quick Start
-
-```yaml
-name: Deploy and Test
-on:
-  push:
-    branches: [main]
-
-jobs:
-  deploy:
-    # Your deployment steps
-    
-  performance-test:
-    needs: deploy
-    uses: ./.github/workflows/k6-load-test.yml
-    with:
-      environment: production
-      test_scenario: smoke
-      base_url: https://api.example.com
-    secrets: inherit
-```
-
-## Workflow Inputs
-
-| Input | Type | Required | Default | Description |
-|-------|------|----------|---------|-------------|
-| `environment` | string | Yes | - | Target environment (staging, production) |
-| `test_scenario` | string | No | smoke | Test type: smoke, load, stress, spike, soak |
-| `base_url` | string | Yes | - | Base URL of application to test |
-| `k6_version` | string | No | latest | k6 version to use |
-| `test_duration` | string | No | - | Override test duration (e.g., 5m, 1h) |
-| `virtual_users` | number | No | - | Override number of virtual users |
-| `thresholds_config` | string | No | - | Path to custom thresholds JSON |
-| `test_script` | string | No | .github/k6/scripts/default-test.js | Path to k6 test script |
-| `fail_on_threshold` | boolean | No | true | Fail workflow if thresholds not met |
-| `upload_results` | boolean | No | true | Upload test results as artifacts |
-| `cloud_run` | boolean | No | false | Run tests on k6 Cloud |
-
-## Workflow Outputs
-
-| Output | Description |
-|--------|-------------|
-| `test_passed` | Whether the test passed all thresholds (true/false) |
-| `results_url` | URL to test results artifact |
-| `summary` | Test execution summary |
-
-## Workflow Secrets
-
-| Secret | Required | Description |
-|--------|----------|-------------|
-| `K6_CLOUD_TOKEN` | No | k6 Cloud API token for cloud runs |
-| `CUSTOM_HEADERS` | No | Custom headers for authenticated endpoints (JSON) |
-
-## Test Scenarios
-
-### Available Scenarios
-
-- **smoke**: Quick validation (1 min, 1 VU)
-- **load**: Normal traffic (9 min, 10 VUs)
-- **stress**: Find breaking points (33 min, up to 200 VUs)
-- **spike**: Sudden traffic changes (8 min, 5→100→5 VUs)
-- **soak**: Extended duration (30+ min, 10 VUs)
-
-### Selecting a Scenario
-
-See the [Scenario Selection Guide](../k6/SCENARIO_SELECTION_GUIDE.md) for detailed guidance.
-
-## Authentication
-
-For testing protected endpoints:
-
-```yaml
-uses: ./.github/workflows/k6-load-test.yml
-with:
-  base_url: https://api.example.com
-secrets:
-  CUSTOM_HEADERS: |
-    {
-      "Authorization": "Bearer ${{ secrets.API_TOKEN }}",
-      "X-API-Key": "${{ secrets.API_KEY }}"
-    }
-```
-
-## Custom Test Scripts
-
-Use your own test script:
-
-```yaml
-with:
-  test_script: .github/k6/scripts/my-custom-test.js
-```
-
-## Custom Thresholds
-
-Use environment-specific thresholds:
-
-```yaml
-with:
-  thresholds_config: .github/k6/thresholds/production.json
-```
-
-## k6 Cloud Integration
-
-For high-concurrency tests:
-
-```yaml
-uses: ./.github/workflows/k6-load-test.yml
-with:
-  cloud_run: true
-secrets:
-  K6_CLOUD_TOKEN: ${{ secrets.K6_CLOUD_TOKEN }}
-```
-
-## Artifacts
-
-Test results are automatically uploaded as artifacts including:
-- JSON results (`results.json`)
-- CSV results (`results.csv`)
-- HTML report (`report.html`)
-- Scenario-specific summaries
-
-Artifacts are retained for 30 days.
-
-## Error Handling
-
-The workflow handles various error scenarios:
-- Base URL not accessible
-- Test script not found
-- Threshold failures
-- k6 installation issues
-
-See the [Troubleshooting Guide](../k6/INTEGRATION_GUIDE.md#troubleshooting) for solutions.
-
-## Integration Patterns
-
-For comprehensive integration examples, see the [Integration Guide](../k6/INTEGRATION_GUIDE.md).
-
-### Integration with Release and Deployment Workflows
-
-The k6 load testing workflow is designed to integrate seamlessly with your release and deployment processes. Here's the recommended pattern:
-
-```yaml
-# deploy.yml.example - Complete release and deployment with load testing
-name: 🚀 Release and Deploy
-
-on:
-  push:
-    branches: [main, staging, dev]
-
-jobs:
-  # Step 1: Create a release
-  release:
-    uses: ./.github/workflows/release.yml
-    with:
-      environment: ${{ github.ref_name }}
-      # ... other inputs
-    
-  # Step 2: Deploy to your infrastructure
-  deploy:
-    needs: release
-    runs-on: ubuntu-latest
-    outputs:
-      environment_url: ${{ steps.deploy.outputs.environment_url }}
-    steps:
-      # Your deployment logic here
-      
-  # Step 3: Run load tests (staging only)
-  load_testing:
-    needs: [release, deploy]
-    if: |
-      needs.deploy.result == 'success' && 
-      github.ref_name == 'staging'
-    uses: ./.github/workflows/load-test.yml
-    with:
-      environment: staging
-      test_scenario: smoke
-      base_url: ${{ needs.deploy.outputs.environment_url }}
-      fail_on_threshold: false  # Don't fail the deployment
-    secrets: inherit
-```
-
-This pattern ensures:
-- Releases are created first with proper versioning
-- Deployments happen after successful releases
-- Load tests run automatically for staging deployments
-- Production deployments skip load testing (run manually if needed)
-
-## File Structure
-
-```
-.github/
-├── workflows/
-│   └── k6-load-test.yml      # This workflow
-└── k6/
-    ├── scripts/              # Test scripts
-    ├── scenarios/            # Scenario configs
-    ├── thresholds/           # Threshold configs
-    └── examples/             # Usage examples
-```
-
-## Workflow Steps
-
-1. **Checkout**: Get repository code
-2. **Setup k6**: Install specified k6 version
-3. **Prepare Environment**: Set up test variables
-4. **Run Test**: Execute k6 with parameters
-5. **Generate Summary**: Create test report
-6. **Upload Results**: Store artifacts
-7. **Comment on PR**: Add results to PR (if applicable)
-
-## Best Practices
-
-1. Start with smoke tests
-2. Use appropriate scenarios per environment
-3. Set realistic thresholds
-4. Monitor resource usage during tests
-5. Review results regularly
-6. Update tests as application evolves
-
-## Support
-
-- [k6 Documentation](https://k6.io/docs/)
-- [GitHub Actions Documentation](https://docs.github.com/en/actions)
-- Project-specific guides in `.github/k6/`