@codyswann/lisa 1.38.0 → 1.39.0

package/all/copy-overwrite/.claude/rules/plan.md

@@ -1,79 +0,0 @@
-# Plan Document Format
-
-For governance rules (required tasks, branch/PR rules, git workflow), see `plan-governance.md`.
-
-## Task Creation Specification
-
-### Parameters
-
-- **subject**: Imperative form (e.g., "Add logout button to header")
-- **activeForm**: Present continuous form (e.g., "Adding logout button to header")
-
-### Description Template
-
-Every task description must be a markdown document with these sections:
-
-**Type:** Bug | Task | Epic | Story
-
-**Description:** Clear description based on type:
-- Bug: symptoms and root cause
-- Story: Gherkin Given/When/Then
-- Task: clear goal
-- Epic: goal with sub-tasks
-
-### Type-Specific Requirements
-
-#### Bug
-- **Replication step** (mandatory): Reproduce the bug empirically before any fix
-- **Root cause analysis**: Identify why the bug occurs
-- **Regression test**: Write a test that fails without the fix and passes with it
-- **Verification**: Run the replication step again to confirm the fix
-
-#### Story/Feature
-- **UX review**: Product-reviewer agent validates from user perspective
-- **Feature flag consideration**: Should this be behind a flag?
-- **Documentation**: User-facing docs if applicable
-
-#### Task
-- **Standard implementation** with empirical verification
-
-#### Epic
-- **Decompose into sub-tasks** (Stories/Tasks/Bugs)
-- **Each sub-task gets its own type-specific requirements**
-
-### Additional Description Sections
-
-**Acceptance Criteria:** Checkbox list of completion criteria
-
-**Relevant Research:** Code references, patterns, architecture constraints
-
-**Skills to Invoke:** List applicable skills (coding-philosophy is auto-loaded as a rule)
-
-**Implementation Details:** Files to modify, functions to implement, edge cases
-
-**Testing Requirements:** Unit tests (with `describe/it` structure), integration tests, E2E tests (or "N/A")
-
-**Verification:** Every task MUST have empirical verification (see `verfication.md` for types). Include: verification type, proof command, and expected output.
-
-**Learnings:** On completion, use `TaskUpdate` to save discoveries: `metadata: { learnings: ["Learning 1", ...] }`
-
-### Metadata
-
-Every task MUST include this JSON metadata block. Do NOT omit `skills` (use `[]` if none) or `verification`.
-
-```json
-{
-  "plan": "<plan-name>",
-  "type": "bug|task|epic|story",
-  "skills": ["..."],
-  "verification": {
-    "type": "test|ui-recording|test-coverage|api-test|manual-check|documentation",
-    "command": "the proof command",
-    "expected": "what success looks like"
-  }
-}
-```
-
-### Task Sizing
-
-Each task must be small enough to have a **single, specific verification**. Ask: "Can I prove this is done with ONE command?" Split tasks that require multiple verifications.

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

@@ -1,238 +0,0 @@
----
-name: plan-create
-description: "Creates an implementation plan from a ticket URL, file path, or text description. Spawns an Agent Team for parallel research, review, and synthesis. Detects plan type (Bug/Task/Story/Epic) and applies type-specific requirements."
----
-
-# Create Implementation Plan
-
-Create an implementation plan for: $ARGUMENTS
-
-All plans must follow the rules in @.claude/rules/plan-governance.md (required tasks, branch/PR rules, git workflow) and @.claude/rules/plan.md (task creation specification, metadata schema).
-
-## Step 1: Parse Input
-
-Determine the input type from `$ARGUMENTS`:
-
-1. **Ticket URL/ID** -- Fetch ticket details with the appropriate CLI or MCP Server. Extract: title, description, acceptance criteria, priority, epic/parent. Note the ticket URL for later integration updates.
-2. **File path** -- Read the file contents and use as context for the plan.
-3. **Free text** -- Treat the entire argument as a text description of the work.
-
-If no argument provided, prompt the user for input.
-
-## Step 2: Detect Plan Type
-
-| Type | Indicators |
-|------|------------|
-| **Bug** | Symptoms, errors, incorrect behavior, "broken", "fails", "crash", "regression" |
-| **Story/Feature** | New capability, user-facing change, "add", "implement", "create", "as a user" |
-| **Task** | Internal work, refactoring, configuration, maintenance, "update", "migrate", "refactor" |
-| **Epic** | Large scope with multiple features/stories, "overhaul", "redesign", multiple deliverables |
-
-If ambiguous, default to **Task**.
-
-## Step 3: Assess Complexity
-
-Evaluate the scope of work:
-
-- **Trivial** (single file, config change, documentation update) → Skip to Step 8 (direct synthesis). No agent team needed.
-- **Standard** (2-10 files, single feature or fix) → Proceed through all phases.
-- **Epic** (10+ files, multiple features, cross-cutting changes) → Proceed through all phases with extra attention to dependency mapping.
-
-## Step 4: Phase 1 - Research (parallel)
-
-Create an Agent Team and spawn three research teammates simultaneously. **All agents spawned in Steps 4–7 must include the `team_name` parameter from the TeamCreate call.**
-
-#### Researcher
-- **Name**: `researcher`
-- **Agent type**: `general-purpose`
-- **Mode**: `bypassPermissions`
-- **Team**: use the `team_name` from TeamCreate
-- **Prompt**: Research the input (ticket, file, or description). If a ticket URL, fetch full details via JIRA MCP or GitHub CLI. If a bug, attempt to reproduce it empirically (Playwright, browser, direct API call, etc.). Extract requirements, acceptance criteria, and context.
-
-#### Codebase Explorer
-- **Name**: `explorer`
-- **Agent type**: `Explore`
-- **Team**: use the `team_name` from TeamCreate
-- **Prompt**: Explore the codebase for relevant code, existing patterns, and reusable scripts. Read lint and format rules to understand project standards. Identify files that would need modification, existing utilities that can be reused, and architecture constraints. Check for existing scripts in `package.json` that could be used for replication or verification.
-
-#### Spec Gap Analyst
-- **Name**: `spec-analyst`
-- **Agent type**: `spec-analyst`
-- **Mode**: `bypassPermissions`
-- **Team**: use the `team_name` from TeamCreate
-- **Prompt**: Analyze the input for specification gaps. Read `package.json` and existing code for project context. Identify every ambiguity or unstated assumption that could lead to wrong architectural decisions. Report as a numbered list of clarifying questions, sorted by impact.
-
-Wait for all three to report back via SendMessage.
-
-## Step 5: Phase 1.5 - Research Brief & Gap Resolution (team lead)
-
-Synthesize Phase 1 findings into a structured **Research Brief**:
-
-- **Ticket/spec details**: requirements, acceptance criteria, constraints
-- **Reproduction results**: (for bugs) steps attempted, outcome observed
-- **Relevant files**: paths, line ranges, what they do
-- **Existing patterns**: conventions found in the codebase
-- **Architecture constraints**: dependencies, limitations, integration points
-- **Reusable utilities**: existing code that applies to this work
-
-### Gap Resolution
-
-After synthesizing the Research Brief:
-
-1. Collect gaps from the spec-analyst's findings
-2. Present gaps to the user via AskUserQuestion -- group related questions and include why each matters
-3. If no gaps identified, state "No specification gaps identified" and proceed to Phase 2
-4. Incorporate answers into the Research Brief before Phase 2
-
-## Step 6: Phase 2 - Domain Sub-Plans (parallel)
-
-Spawn four domain planners simultaneously, passing each the Research Brief:
-
-#### Architecture Planner
-- **Name**: `arch-planner`
-- **Agent type**: `architecture-planner`
-- **Mode**: `bypassPermissions`
-- **Team**: use the `team_name` from TeamCreate
-- **Prompt**: [Research Brief] + Design the technical implementation approach. Identify files to create/modify, map dependencies, recommend patterns, flag risks.
-
-#### Test Strategist
-- **Name**: `test-strategist`
-- **Agent type**: `test-strategist`
-- **Mode**: `bypassPermissions`
-- **Team**: use the `team_name` from TeamCreate
-- **Prompt**: [Research Brief] + Design the test matrix. Identify edge cases, set coverage targets, define verification commands, plan TDD sequence.
-
-#### Security Planner
-- **Name**: `security-planner`
-- **Agent type**: `security-planner`
-- **Mode**: `bypassPermissions`
-- **Team**: use the `team_name` from TeamCreate
-- **Prompt**: [Research Brief] + Perform lightweight threat modeling (STRIDE). Identify auth/validation gaps, secrets exposure risks, and security measures needed.
-
-#### Product Planner
-- **Name**: `product-planner`
-- **Agent type**: `product-planner`
-- **Mode**: `bypassPermissions`
-- **Team**: use the `team_name` from TeamCreate
-- **Prompt**: [Research Brief] + Define user flows in Gherkin. Write acceptance criteria from user perspective. Identify UX concerns and error states.
-
-Wait for all four to report back via SendMessage.
-
-## Step 7: Phase 3 - Review (parallel)
-
-Spawn two reviewers simultaneously, passing them all sub-plans:
-
-#### Devil's Advocate
-- **Name**: `devils-advocate`
-- **Agent type**: `general-purpose`
-- **Mode**: `bypassPermissions`
-- **Team**: use the `team_name` from TeamCreate
-- **Prompt**: [All sub-plans] + Review critically. Identify anti-patterns, N+1 queries, missing edge cases, security concerns, and performance issues. Do not assume anti-patterns are acceptable just because they exist in the codebase — undocumented anti-patterns should be flagged, not used as reference. Challenge assumptions and propose alternatives for weak points.
-
-#### Consistency Checker
-- **Name**: `consistency-checker`
-- **Agent type**: `consistency-checker`
-- **Mode**: `bypassPermissions`
-- **Team**: use the `team_name` from TeamCreate
-- **Prompt**: [All sub-plans] + Verify cross-plan consistency. Check that file lists align, test strategy covers architecture changes, security measures are reflected in acceptance criteria, and no sub-plans contradict each other.
-
-Wait for both to report back via SendMessage.
-
-## Step 8: Phase 4 - Synthesis (team lead)
-
-Read governance and format rules, then merge everything into a unified plan:
-
-1. Read `@.claude/rules/plan-governance.md` for governance rules
-2. Read `@.claude/rules/plan.md` for task document format
-3. Merge sub-plans + review feedback into a unified plan
-4. Apply governance: Required Tasks, Branch/PR rules, Git Workflow
-5. Create TaskCreate specs per plan.md format
-6. Write plan to `plans/<name>.md`
-7. Create branch, open draft PR
-8. Update ticket if applicable
-
-Apply the Type-Specific Requirements from @.claude/rules/plan.md based on the detected plan type. For Bugs, also include a replication task before any fix and a proof command for every fix task. For Epics, include dependency mapping between sub-tasks.
-
-The plan file must include:
-
-1. **Title and context** — What is being done and why
-2. **Input source** — Ticket URL, file path, or description
-3. **Plan type** — Bug, Task, Story/Feature, or Epic
-4. **Branch and PR** — Following branch/PR rules from plan-governance.md
-5. **Analysis** — Synthesized research findings from all teammates
-6. **Implementation approach** — How the work will be done
-7. **Tasks** — Following the Task Creation Specification from plan.md
-8. **Implementation Team** — Instructions to spawn an Agent Team (see Step 10)
-
-### Type-Specific Requirements
-
-Apply these additional requirements based on the detected type:
-
-#### Bug
-- **Replication step** (mandatory): Include a task to reproduce the bug empirically before any fix
-- **Root cause analysis**: Identify why the bug occurs, not just what triggers it
-- **Regression test**: Write a test that fails without the fix and passes with it
-- **Verification**: Run the replication step again after the fix to confirm resolution
-- **Proof command**: Every fix task must include a proof command and expected output
-
-#### Story/Feature
-- **UX review**: Include a product-reviewer agent task to validate from user perspective
-- **Feature flag consideration**: Note whether this should be behind a feature flag
-- **Documentation**: Include user-facing documentation if applicable
-
-#### Task
-- **Standard implementation** with empirical verification
-
-#### Epic
-- **Decompose into sub-tasks**: Break into Stories, Tasks, and/or Bugs
-- **Each sub-task gets its own type-specific requirements**
-- **Dependency mapping**: Identify which sub-tasks depend on others
-
-## Step 9: Include Required Tasks
-
-Include all required tasks defined in `@.claude/rules/plan-governance.md` (Required Tasks section), including the archive task which must always be last.
-
-## Step 10: Implementation Team Instructions
-
-The plan must include explict instructions to "Create an agent team" for implementation and run the /plan-implement skill. Recommend these specialized agents:
-
-| Agent | Use For |
-|-------|---------|
-| `implementer` | Code implementation (pre-loaded with project conventions, TDD enforcement) |
-| `tech-reviewer` | Technical review (correctness, security, performance) |
-| `product-reviewer` | Product/UX review (validates from non-technical perspective) |
-| `learner` | Post-implementation learning (processes learnings into skills/rules) |
-| `test-coverage-agent` | Writing comprehensive tests |
-| `code-simplifier` | Code simplification and refinement |
-| `coderabbit` | Automated AI code review |
-
-The **team lead** handles git operations (commits, pushes, PR management) — teammates focus on their specialized work.
-
-## Step 11: Ticket Integration
-
-If the input was a ticket ID or URL:
-
-1. Include the ticket URL in the plan metadata
-2. Associate the branch and PR with the ticket
-3. Post the approved plan as a comment on the ticket
-4. Use `/jira-sync` at key milestones
-5. If blocked, update the ticket before stopping
-
-## Step 12: Present to User
-
-Present the synthesized plan to the user for review. The user may approve, request modifications, or reject.
-
-All decisions in the plan must include a recommendation. If a decision is left unresolved, use the recommended option.
-
-## Step 13: Shutdown Team
-
-Send `shutdown_request` to all teammates and clean up the team.
-
-### Bug-Specific Rules
-
-If the plan type is **Bug**:
-
-- The bug **must** be empirically replicated (Playwright, browser, direct API call, etc.) — not guessed at
-- If the research team cannot reproduce the bug, **STOP**. Update the ticket with findings and what additional information is needed, then end the session
-- Do not attempt to fix a bug you cannot prove exists
-- Never include solutions with obvious anti-patterns (e.g., N+1 queries). If unavoidable due to API limitations, **STOP** and update the ticket with what is needed

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

@@ -1,114 +0,0 @@
----
-name: plan-implement
-description: "Implements an existing plan file by reading its tasks and executing them. Spawns an Agent Team with specialized agents for parallel implementation."
----
-
-# Implement Plan
-
-Implement the requirements in $ARGUMENTS.
-
-If no argument provided, search for plan files in the `plans/` directory and present them to the user for selection.
-
-Critical: you must create an agent team to implement the plan. Do not try to skip this!
-
-## Step 1: Parse Plan
-
-1. **Read the plan file** specified in `$ARGUMENTS`
-2. **Extract all tasks** with their dependencies, descriptions, verification requirements, and metadata
-3. **Parse task metadata** -- extract the JSON metadata code fence from each task (see @.claude/rules/plan.md Metadata section for the required schema)
-4. **Build a dependency graph** to determine which tasks can run in parallel
-
-## Task Metadata Rules
-
-Each task in the plan file contains a JSON metadata code fence (schema defined in @.claude/rules/plan.md Metadata section).
-
-- Every TaskCreate call MUST include the full `metadata` object from the plan's JSON code fence
-- If a task is missing `skills` or `verification`, flag it as an error and ask the user before proceeding
-- Run `verification.command` before marking any task complete
-
-## Step 2: Setup
-
-1. Read `@.claude/rules/plan-governance.md` for governance rules (branch/PR, git workflow, required tasks)
-2. Read `@.claude/rules/plan.md` for task document format
-3. **Verify branch exists** -- create if needed following branch/PR rules from plan-governance.md
-4. **Verify draft PR exists** -- create with `gh pr create --draft` if needed. No implementation before the draft PR exists
-5. **Determine implementer count** based on the task dependency graph:
-   - 1-2 independent tasks → 1 implementer
-   - 3-5 independent tasks → 2 implementers
-   - 6+ independent tasks → 3 implementers (cap)
-
-## Step 3: Create Agent Team
-
-Spawn an Agent Team with:
-
-- **Implementers** (named `implementer-1`, `implementer-2`, etc.) -- agent type: `implementer`, mode: `bypassPermissions`
-- Create all tasks via TaskCreate with proper `blockedBy` relationships matching the plan's dependency graph
-- Assign the first batch of independent tasks to implementers
-
-Use the specialized agents per `@.claude/rules/plan-governance.md` (Implementation Team Guidance):
-
-| Agent | Use For | Phase |
-|-------|---------|-------|
-| `implementer` | Code implementation with TDD (red-green-refactor) | Phase 2 |
-| `tech-reviewer` | Technical review (correctness, security, performance) | Phase 3 |
-| `product-reviewer` | Product/UX review (validates from non-technical perspective) | Phase 3 |
-| `test-coverage-agent` | Writing comprehensive tests | Phase 4 |
-| `code-simplifier` | Code simplification and refinement | Phase 4 |
-| `coderabbit` | Automated AI code review | Phase 3 |
-| `learner` | Post-implementation learning | Phase 5 |
-
-The **team lead** handles git operations (commits, pushes, PR management) -- teammates focus on their specialized work.
-
-## Compaction Resilience
-
-Context compaction can cause the team lead to lose in-memory state (task assignments, owner fields). Follow these rules:
-
-1. **Dual owner storage** -- on every TaskUpdate that sets `owner`, also store it in `metadata.owner`:
-   ```
-   TaskUpdate({ taskId: "1", owner: "implementer-1", metadata: { owner: "implementer-1" } })
-   ```
-2. **Re-read after compaction** -- immediately call TaskList to reload all task state
-3. **Restore missing owners** -- if any task has `metadata.owner` but no `owner` field, restore it via TaskUpdate
-4. **Never rely on memory** -- always call TaskList before assigning new work
-
-## Step 4: Phase 2 - Implementation
-
-1. Implementers work on assigned tasks following TDD (red-green-refactor cycle)
-2. Team lead monitors completion via messages from implementers
-3. After each task completes: team lead runs `git add <specific files>` + `git commit` with conventional commit message
-4. Team lead assigns next tasks as dependencies resolve
-5. Continue until all implementation tasks are complete
-
-## Step 5: Phase 3 - Reviews (parallel)
-
-Spawn review agents simultaneously:
-
-- **tech-reviewer** -- agent type: `tech-reviewer`, mode: `bypassPermissions`
-- **product-reviewer** -- agent type: `product-reviewer`, mode: `bypassPermissions`
-- Invoke `/plan-local-code-review` skill (team lead runs directly)
-- **coderabbit** -- agent type: `coderabbit:code-reviewer`, mode: `bypassPermissions`
-
-Wait for all reviews to complete.
-
-## Step 6: Phase 4 - Post-Review (sequential)
-
-1. **Fix review findings** -- re-spawn an implementer to address valid review suggestions
-2. **Simplify code** -- spawn `code-simplifier` agent (agent type: `code-simplifier:code-simplifier`, mode: `bypassPermissions`)
-3. **Update tests** -- spawn `test-coverage-agent` to update tests for post-review changes
-4. **Verify all tasks** -- team lead runs ALL proof commands from all tasks to confirm everything still works
-
-## Step 7: Phase 5 - Learning & Archive
-
-1. **Collect learnings** -- spawn `learner` agent (agent type: `learner`, mode: `bypassPermissions`) to process task learnings
-2. **Archive the plan** -- follow the Archive Procedure in @.claude/rules/plan-governance.md
-3. **Finalize PR**:
-   ```bash
-   git add . && git commit -m "chore: archive <plan-name> plan"
-   GIT_SSH_COMMAND="ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=5" git push
-   gh pr ready
-   gh pr merge --auto --merge
-   ```
-
-## Step 8: Shutdown Team
-
-Send `shutdown_request` to all teammates and clean up the team.