@codyswann/lisa 1.12.9 → 1.14.0

package/all/copy-overwrite/.claude/skills/project-fix-linter-error/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: project-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 bootstraps a project to implement the fixes.
+allowed-tools: ["Read", "Bash", "Glob", "Grep"]
+argument-hint: "<rule-1> [rule-2] [rule-3] ..."
+model: sonnet
+---
+
+# 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: Generate Brief
+
+Compile findings into a detailed brief:
+
+```
+Fix ESLint violations for rules: $ARGUMENTS
+
+## Violations by Rule
+
+### [rule-name-1] (X total violations across Y files)
+
+1. src/services/user.ts (5 violations)
+   - Line 23: [error message]
+   - Line 45: [error message]
+   - Line 67: [error message]
+   ...
+2. src/utils/helpers.ts (3 violations)
+   - Line 12: [error message]
+   ...
+
+### [rule-name-2] (X total violations across Y files)
+...
+
+## Fix Strategies
+- **Complexity rules** (sonarjs/*): Extract functions, early returns, simplify conditions
+- **Style rules** (prettier/*, import/order): Apply formatting fixes
+- **Best practice rules** (react-hooks/*, prefer-const): Refactor to recommended pattern
+- **Type rules** (@typescript-eslint/*): Add proper types, remove `any`
+
+## Acceptance Criteria
+- `bun run lint` passes with zero violations for: $ARGUMENTS
+- Each rule's fixes committed separately: `fix(lint): resolve [rule-name] violations`
+
+## Verification
+Command: `bun run lint 2>&1 | grep -E "($ARGUMENTS)" | wc -l`
+Expected: 0
+```
+
+## Step 3: Bootstrap Project
+
+Run `/project-bootstrap` with the generated brief as a text prompt.

package/all/copy-overwrite/.claude/skills/project-implement/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: project-implement
+description: This skill should be used when systematically implementing all tasks in a specified project. It retrieves planned tasks, executes them via subagents in parallel, runs verification commands, and tracks completion status.
+allowed-tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep", "Task", "TaskCreate", "TaskUpdate", "TaskList", "TaskGet", "Skill"]
+argument-hint: "<project-directory>"
+---
+
+## Setup
+
+1. Set active project marker: `echo "$ARGUMENTS" | sed 's|.*/||' > .claude-active-project`
+2. Extract `<project-name>` from the last segment of `$ARGUMENTS`
+3. Use **TaskList** to verify tasks exist for this project (check metadata.project)
+4. If no tasks found, error: "No tasks found. Run /project-plan first"
+
+## Implementation
+
+Use **TaskList** to get current task status.
+
+**Always execute tasks via subagents** to keep the main context window clean. Launch up to 6 subagents in parallel for unblocked tasks.
+
+For each pending, unblocked task (filter by `metadata.project` = `<project-name>`):
+
+1. Use **TaskUpdate** to mark it `in_progress`
+2. Use **TaskGet** to retrieve full task details
+3. Complete the task following the instructions in its description
+4. Run the verification command and confirm expected output
+5. If verification passes, use **TaskUpdate** to mark it `completed`
+6. If verification fails, keep task `in_progress` and report the failure
+7. Check **TaskList** for newly unblocked tasks
+
+Continue until all tasks are completed.
+
+## Complete
+
+Use **TaskList** to generate a summary showing:
+- Total tasks completed
+- Any tasks that failed or remain in progress
+
+After completing this phase, tell the user: "To continue, run `/project-review $ARGUMENTS`"

package/all/copy-overwrite/.claude/skills/project-local-code-review/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: project-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
+argument-hint: "<project-directory>"
+---
+
+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 $ARGUMENTS/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 $ARGUMENTS/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/all/copy-overwrite/.claude/skills/project-lower-code-complexity/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: project-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 bootstraps a project 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: Generate Brief
+
+Compile findings into a detailed brief:
+
+```
+Reduce cognitive complexity threshold from [current] to [new].
+
+## Functions Exceeding Threshold (ordered by complexity)
+
+1. src/services/user.ts:processUser (complexity: 18, target: [new])
+   - Line 45, function spans lines 45-120
+2. src/utils/helpers.ts:validateInput (complexity: 15, target: [new])
+   - Line 23, function spans lines 23-67
+...
+
+## Configuration Change
+- File: [eslint config path]
+- Change: cognitive-complexity threshold from [current] to [new]
+
+## Refactoring Strategies
+- **Extract functions**: Break complex logic into smaller, named functions
+- **Early returns**: Reduce nesting with guard clauses
+- **Extract conditions**: Move complex boolean logic into named variables
+- **Use lookup tables**: Replace complex switch/if-else chains with object maps
+
+## Acceptance Criteria
+- All functions at or below complexity [new]
+- `bun run lint` passes with no cognitive-complexity violations
+
+## Verification
+Command: `bun run lint 2>&1 | grep "cognitive-complexity" | wc -l`
+Expected: 0
+```
+
+## Step 3: Bootstrap Project
+
+Run `/project-bootstrap` with the generated brief as a text prompt.

package/all/copy-overwrite/.claude/skills/project-plan/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: project-plan
+description: This skill should be used when creating a detailed list of implementation tasks from research.md and brief.md files. It validates research completeness, discovers available skills, creates granular tasks with verification commands, and establishes task dependencies.
+allowed-tools: ["Read", "Bash", "Glob", "Grep", "TaskCreate", "TaskUpdate", "TaskList", "Skill"]
+argument-hint: "<project-directory>"
+---
+
+## Setup
+
+Set active project marker: `echo "$ARGUMENTS" | sed 's|.*/||' > .claude-active-project`
+
+Extract `<project-name>` from the last segment of `$ARGUMENTS`.
+
+## Step 1: Read Project Files
+
+Read `$ARGUMENTS/brief.md` and `$ARGUMENTS/research.md` FULLY (no limit/offset).
+
+## Step 2: Validate Research
+
+Locate "## Open Questions" in research.md.
+
+**Valid states** (proceed):
+- Section contains "None", "[None identified]", "N/A", or is empty
+- Section doesn't exist
+- All `**Answer**:` fields are filled
+
+**Invalid state** (stop immediately):
+- Questions with unfilled `**Answer**:` fields
+
+If invalid, report:
+```
+CANNOT PROCEED WITH PLANNING
+
+The research.md file has unanswered open questions.
+
+Unanswered Questions Found:
+[List each question]
+
+Action Required:
+1. Review $ARGUMENTS/research.md "## Open Questions"
+2. Fill in the **Answer**: field for each question
+3. Re-run /project-plan
+```
+
+**IMPORTANT**: NEVER modify research.md during validation.
+
+## Step 3: Discover Skills
+
+Read `.claude/skills/*/SKILL.md` files (first 10 lines each) to map skills to applicable tasks.
+
+## Step 4: Create Tasks
+
+### Determine Task List
+
+Each task must be small enough to have a **single, specific verification**.
+- Ask: "Can I prove this task is done with ONE command or check?"
+- Exception: `ui-recording` tasks may verify per-platform (web/iOS/Android)
+
+**Properly-sized tasks:**
+- "Add logout button to header" → single Playwright test
+- "Add unit tests for UserService" → single coverage command
+- "Create API endpoint for user profile" → single curl command
+
+**Too large (split these):**
+- "Build authentication system" → split into login, logout, session, etc.
+- "Add user management feature" → split into list, create, edit, etc.
+
+### Create Tasks with TaskCreate
+
+For each task, use **TaskCreate** with:
+
+**subject**: Task name in imperative form (e.g., "Add logout button to header")
+
+**activeForm**: Present continuous form (e.g., "Adding logout button to header")
+
+**description**: Full task specification in markdown:
+
+```markdown
+**Type:** Bug | Task | Epic | Story
+
+## Description
+[Clear description based on type:
+- Bug: Symptoms, root cause approach
+- Story: Gherkin BDD format (Given/When/Then)
+- Task: Straightforward with clear goal
+- Epic: Goal overview with sub-tasks]
+
+## Acceptance Criteria
+- [ ] Criterion 1
+- [ ] Criterion 2
+
+## Relevant Research
+[Extract from research.md: code references, patterns, architecture constraints]
+
+## Skills to Invoke
+- `/coding-philosophy` - Always required
+- [Other applicable skills from Step 3]
+
+## Implementation Details
+[Files to modify, functions to implement, edge cases]
+
+## Testing Requirements
+### Unit Tests
+- [ ] `describe('X')/it('should Y')`: Description
+
+### Integration Tests
+[Or "N/A - no integration points"]
+
+### E2E Tests
+[Or "N/A - no user-facing changes"]
+
+## Verification
+
+Every task MUST have empirical verification - a command that proves the work is done.
+
+**Why?** Code that "looks correct" often isn't. The only way to know something works is to run it and observe the result. Verification isn't "I wrote the code" - it's running a command and seeing expected output.
+
+**Type:** `test` | `ui-recording` | `test-coverage` | `api-test` | `manual-check` | `documentation`
+
+| Type | When to Use | Example |
+|------|-------------|---------|
+| `test` | Run specific tests | `npm test -- src/services/user.spec.ts` |
+| `ui-recording` | UI/UX changes | `npm run playwright:test ...` |
+| `test-coverage` | Coverage threshold | `npm run test:cov -- --collectCoverageFrom='...'` |
+| `api-test` | API endpoints | `curl -s http://localhost:3000/api/endpoint` |
+| `documentation` | Docs, README | `cat path/to/doc.md \| grep "expected content"` |
+| `manual-check` | Config, setup | `cat config.json \| jq '.setting'` |
+
+**Proof Command:**
+```bash
+[Single command that outputs observable proof of completion]
+```
+
+**Expected Output:**
+[Exact or pattern-matched output that proves success]
+
+## Learnings
+During implementation, collect any discoveries valuable for future developers:
+- Gotchas or unexpected behavior encountered
+- Edge cases that weren't obvious from requirements
+- Better approaches discovered during implementation
+- Patterns that should be reused or avoided
+- Documentation gaps or misleading information found
+
+**On task completion**, use `TaskUpdate` to save learnings:
+```
+TaskUpdate:
+  taskId: "<this-task-id>"
+  metadata: { learnings: ["Learning 1", "Learning 2", ...] }
+```
+```
+
+**metadata**:
+```json
+{
+  "project": "<project-name>",
+  "type": "bug|task|epic|story",
+  "skills": ["/coding-philosophy", ...],
+  "verification": {
+    "type": "test|ui-recording|test-coverage|api-test|manual-check|documentation",
+    "command": "the proof command",
+    "expected": "what success looks like"
+  }
+}
+```
+
+### Set Up Dependencies
+
+After creating all tasks, use **TaskUpdate** with `addBlockedBy` to establish task order where needed.
+
+## Step 5: Report
+
+Report: "Planning complete - X tasks created for project <project-name>"
+
+Use **TaskList** to show the created tasks.
+
+---
+
+**IMPORTANT**: Each task description should contain all necessary information from `brief.md` and `research.md` to complete in isolation. Tasks should be independent and as small in scope as possible.

package/all/copy-overwrite/.claude/skills/project-reduce-max-lines/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: project-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 bootstraps a project to split oversized files.
+allowed-tools: ["Read", "Bash", "Glob", "Grep"]
+argument-hint: "<max-lines-value>"
+model: sonnet
+---
+
+# 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: Generate Brief
+
+Compile findings into a detailed brief:
+
+```
+Reduce max file lines threshold to $ARGUMENTS.
+
+## Files Exceeding Threshold (ordered by line count)
+
+1. src/services/user.ts (450 lines, target: $ARGUMENTS)
+2. src/utils/helpers.ts (380 lines, target: $ARGUMENTS)
+3. src/components/Dashboard.tsx (320 lines, target: $ARGUMENTS)
+...
+
+## Configuration Change
+- File: eslint.thresholds.json
+- Change: maxLines to $ARGUMENTS
+
+## Refactoring Strategies
+- **Extract modules**: Break file into smaller focused modules
+- **Remove duplication**: Consolidate repeated logic
+- **Delete dead code**: Remove unused functions/code paths
+- **Simplify logic**: Use early returns, reduce nesting
+
+## Acceptance Criteria
+- All files at or below $ARGUMENTS lines
+- `bun run lint` passes with no max-lines violations
+
+## Verification
+Command: `bun run lint 2>&1 | grep "max-lines" | wc -l`
+Expected: 0
+```
+
+## Step 3: Bootstrap Project
+
+Run `/project-bootstrap` with the generated brief as a text prompt.

package/all/copy-overwrite/.claude/skills/project-reduce-max-lines-per-function/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: project-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 bootstraps a project to split oversized functions.
+allowed-tools: ["Read", "Bash", "Glob", "Grep"]
+argument-hint: "<max-lines-per-function-value>"
+model: sonnet
+---
+
+# 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: Generate Brief
+
+Compile findings into a detailed brief:
+
+```
+Reduce max lines per function threshold to $ARGUMENTS.
+
+## Functions Exceeding Threshold (ordered by line count)
+
+1. src/services/user.ts:processUser (95 lines, target: $ARGUMENTS)
+   - Line 45, function spans lines 45-140
+2. src/utils/helpers.ts:validateInput (82 lines, target: $ARGUMENTS)
+   - Line 23, function spans lines 23-105
+...
+
+## Configuration Change
+- File: eslint.thresholds.json
+- Change: maxLinesPerFunction to $ARGUMENTS
+
+## Refactoring Strategies
+- **Extract functions**: Break function into smaller named functions
+- **Early returns**: Reduce nesting with guard clauses
+- **Extract conditions**: Move complex boolean logic into named variables
+- **Use lookup tables**: Replace complex switch/if-else chains with object maps
+- **Consolidate logic**: Merge similar code paths
+
+## Acceptance Criteria
+- All functions at or below $ARGUMENTS lines
+- `bun run lint` passes with no max-lines-per-function violations
+
+## Verification
+Command: `bun run lint 2>&1 | grep "max-lines-per-function" | wc -l`
+Expected: 0
+```
+
+## Step 3: Bootstrap Project
+
+Run `/project-bootstrap` with the generated brief as a text prompt.