@codyswann/lisa 1.19.0 → 1.19.1

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

@@ -1,92 +0,0 @@
----
-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>"
----
-
-> **DEPRECATED**: This skill is deprecated. Use `/plan-local-code-review` instead, which integrates with Claude's native plan mode.
-> This skill will be removed in a future release.
-
-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

@@ -1,65 +0,0 @@
----
-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"]
----
-
-> **DEPRECATED**: This skill is deprecated. Use `/plan-lower-code-complexity` instead, which integrates with Claude's native plan mode.
-> This skill will be removed in a future release.
-
-# 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

@@ -1,183 +0,0 @@
----
-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>"
----
-
-> **DEPRECATED**: This skill is deprecated. Use Claude's native plan mode instead.
-> Enter plan mode with `/plan`, describe your requirements, and Claude will create a plan with tasks automatically.
-> This skill will be removed in a future release.
-
-## 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

@@ -1,66 +0,0 @@
----
-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>"
-
----
-
-> **DEPRECATED**: This skill is deprecated. Use `/plan-reduce-max-lines` instead, which integrates with Claude's native plan mode.
-> This skill will be removed in a future release.
-
-# 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

@@ -1,69 +0,0 @@
----
-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>"
-
----
-
-> **DEPRECATED**: This skill is deprecated. Use `/plan-reduce-max-lines-per-function` instead, which integrates with Claude's native plan mode.
-> This skill will be removed in a future release.
-
-# 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.

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

@@ -1,170 +0,0 @@
----
-name: project-research
-description: This skill should be used when conducting comprehensive research across the codebase and web relevant to a project. It spawns parallel research agents, documents existing code patterns, testing patterns, and architecture, and compiles findings into a research.md file for the planning phase.
-allowed-tools: ["Read", "Write", "Bash", "Glob", "Grep", "Task", "TaskCreate", "TaskUpdate", "TaskList", "WebSearch", "WebFetch"]
-argument-hint: "<project-directory>"
----
-
-> **DEPRECATED**: This skill is deprecated. Use Claude's native plan mode instead.
-> Enter plan mode with `/plan`, describe your requirements, and Claude will create a plan with tasks automatically.
-> This skill will be removed in a future release.
-
-# Research Codebase
-
-Conduct comprehensive research across the codebase and web to help create an implementation plan for the brief in $ARGUMENTS.
-
-## Goals
-
-1. Determine what existing documentation in the codebase will be needed
-2. Determine any gaps in the spec that would prevent fulfilling acceptance criteria
-3. Determine potential pitfalls (performance, security concerns)
-4. Determine reusable code, functions, and modules in the codebase
-5. Determine testing patterns and locations (frameworks, conventions, examples)
-6. Determine documentation patterns (JSDoc, DB comments, GraphQL descriptions)
-
-## Critical Rule
-
-**THE ONLY JOB IS TO DOCUMENT AND EXPLAIN THE CODEBASE AS IT EXISTS TODAY**
-
-- DO NOT suggest improvements or changes
-- DO NOT perform root cause analysis
-- DO NOT propose future enhancements
-- DO NOT critique or identify problems
-- ONLY describe what exists, where it exists, how it works, and how components interact
-
-## Workflow Tasks
-
-Create workflow tracking tasks with `metadata: { "project": "<project-name>", "phase": "research" }`:
-
-1. Read mentioned files
-2. Analyze and decompose
-3. Spawn research agents
-4. Wait and synthesize
-5. Generate document
-6. Commit
-
-## Step 1: Read Mentioned Files
-
-Read any directly mentioned files FULLY first (no limit/offset). This ensures full context before spawning sub-tasks.
-
-## Step 2: Analyze and Decompose
-
-- Break down the brief into composable research areas
-- Identify specific components, patterns, or concepts to investigate
-- Consider which directories, files, or architectural patterns are relevant
-
-## Step 3: Spawn Research Agents
-
-Spawn parallel sub-agent tasks for comprehensive research:
-
-**For codebase research:**
-- **codebase-locator**: Find WHERE files and components live
-- **codebase-analyzer**: Understand HOW specific code works
-- **codebase-pattern-finder**: Find examples of existing patterns
-- **git-history-analyzer**: Understand file change history
-
-**For e2e test research:**
-- Find existing e2e tests in `e2e/` or `tests/` directories
-- Document what scenarios each test covers
-- Identify tests needing modification or gaps for new functionality
-
-**For web research:**
-- **web-search-researcher**: External documentation and resources
-- Include LINKS with findings in the final report
-
-Run multiple agents in parallel when searching for different things.
-
-## Step 4: Wait and Synthesize
-
-**CRITICAL**: Wait for ALL sub-agent tasks to complete before proceeding.
-
-- Compile all sub-agent results
-- Prioritize live codebase findings as primary source of truth
-- Connect findings across different components
-- Include specific file paths and line numbers
-- Note any frameworks used (Rails, NestJS, Expo, React, etc.)
-
-## Step 5: Generate Document
-
-Create `$ARGUMENTS/research.md` with this structure:
-
-```markdown
----
-date: [ISO format with timezone]
-status: complete
-last_updated: [YYYY-MM-DD]
----
-
-# Research
-
-## Summary
-[High-level documentation of findings]
-
-## Detailed Findings
-### [Component/Area]
-- Description of what exists ([file.ext:line](link))
-- How it connects to other components
-
-## Code References
-- `path/to/file.py:123` - Description
-
-## Reusable Code
-### Existing Functions/Modules
-- `path/to/utils.ts:45` - `functionName()` - description of what it does and how it can be reused
-- `path/to/service.ts:120` - `ClassName` - description of reusable functionality
-
-### Existing Patterns to Follow
-- Similar feature implemented in `path/to/feature/` - follow same structure
-- Existing implementation of X in `path/to/file.ts` - can be extended/adapted
-
-## Architecture Documentation
-[Patterns, conventions, design implementations]
-
-## Testing Patterns
-### Unit Test Patterns
-- **Location**: pattern found
-- **Framework**: Jest/Vitest/etc.
-- **Example to follow**: path:line-range
-- **Conventions**: naming, structure, mocks
-
-### Integration Test Patterns
-[Similar structure]
-
-### E2E Test Patterns
-[Similar structure]
-
-## Impacted Tests
-### Tests Requiring Modification
-- `tests/example.spec.ts` - tests X functionality, will need updates for Y
-- `e2e/feature.spec.ts` - may need new assertions for Z
-
-### Test Gaps
-- No existing tests for X functionality - will need new test file
-- Missing edge case coverage for Y scenario
-
-## Documentation Patterns
-### JSDoc Conventions
-### Database Comments (Backend)
-### GraphQL Descriptions (Backend)
-
-## Open Questions
-
-### Q1: [Short Title]
-**Question**: [Full question]
-**Context**: [Why this arose]
-**Impact**: [What it affects]
-**Recommendation**: [Researcher's best recommendation based on findings]
-**Answer**: _[Human fills before /project-plan]_
-```
-
-## Step 6: Commit
-
-Run `/git-commit`
-
-## Important Notes
-
-- Always use parallel Task agents to maximize efficiency
-- Always run fresh codebase research - never rely solely on existing documents
-- Focus on finding concrete file paths and line numbers
-- Each sub-agent prompt should be specific and focused on read-only documentation
-- **REMEMBER**: Document what IS, not what SHOULD BE