@codyswann/lisa 1.67.3 → 1.69.0

package/plugins/src/base/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/src/base/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/src/base/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/src/base/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/src/base/skills/ticket-triage/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: ticket-triage
+description: "Analytical triage gate for JIRA tickets. Detects requirement ambiguities, identifies edge cases from codebase analysis, and plans verification methodology. Posts findings to the ticket and produces a verdict (BLOCKED/PASSED_WITH_FINDINGS/PASSED) that gates whether implementation can proceed."
+allowed-tools: ["Read", "Glob", "Grep", "Bash"]
+---
+
+# Ticket Triage: $ARGUMENTS
+
+Perform analytical triage on the JIRA ticket. The caller has fetched the ticket details (summary, description, acceptance criteria, labels, status, comments) and provided them in context.
+
+Repository name for scoped labels and comment headers: determine via `basename $(git rev-parse --show-toplevel)`.
+
+## Phase 1 -- Relevance Check
+
+Search the local codebase using Glob and Grep for code related to the ticket's subject matter:
+- Keywords from summary and description
+- Component names, API endpoints, database tables
+- Error messages or log strings mentioned in the ticket
+
+If NO relevant code is found in this repo:
+- Output: `## Verdict: NOT_RELEVANT`
+- Instruct caller to add the label `claude-triaged-{repo}` and skip this ticket
+
+If relevant code IS found, proceed to Phase 2.
+
+## Phase 2 -- Cross-Repo Awareness
+
+Parse the ticket's existing comments for triage headers from OTHER repositories. Look for patterns like:
+- `*[some-repo-name] Ambiguity detected*`
+- `*[some-repo-name] Edge cases*`
+- `*[some-repo-name] Verification methodology*`
+
+Note which phases other repos have already covered and what findings they posted. In subsequent phases:
+- Do NOT duplicate findings already posted by another repo
+- DO add supplementary findings specific to THIS repo's codebase
+
+## Phase 3 -- Ambiguity Detection
+
+Examine the ticket summary, description, and acceptance criteria. Look for:
+
+| Signal | Example |
+|--------|---------|
+| Vague language | "should work properly", "handle edge cases", "improve performance" |
+| Untestable criteria | No measurable outcome defined |
+| Undefined terms | Acronyms or domain terms not explained in context |
+| Missing scope boundaries | What's included vs excluded is unclear |
+| Implicit assumptions | Assumptions not stated explicitly |
+
+Skip ambiguities already raised by another repo's triage comments.
+
+For each NEW ambiguity found, produce:
+
+```text
+### Ambiguity: [short title]
+**Description:** [what is ambiguous]
+**Suggested clarification:** [specific question to resolve it]
+```
+
+Be specific -- every ambiguity must have a concrete clarifying question.
+
+## Phase 4 -- Edge Case Analysis
+
+Search the codebase using Glob and Grep for files related to the ticket's subject matter. Check git history for recent changes in those areas:
+
+```bash
+git log --oneline -20 -- <relevant-paths>
+```
+
+Identify:
+- Boundary conditions (empty inputs, max values, concurrent access)
+- Error handling gaps in related code
+- Integration risks with other components
+- Data migration or backward compatibility concerns
+
+Reference only files in THIS repo. Acknowledge edge cases from other repos if relevant, but do not duplicate them.
+
+For each edge case, produce:
+
+```text
+### Edge Case: [title]
+**Description:** [what could go wrong]
+**Code reference:** [file path and relevant lines or patterns]
+```
+
+Every edge case must reference specific code files or patterns found in the codebase. If no relevant code exists, note that this appears to be a new feature with no existing code to analyze.
+
+## Phase 5 -- Verification Methodology
+
+For each acceptance criterion, specify a concrete verification method scoped to what THIS repo can test:
+
+| Verification Type | When to Use | What to Specify |
+|-------------------|-------------|-----------------|
+| UI | Change affects user-visible interface | Playwright test description with specific assertions |
+| API | Change affects HTTP/GraphQL/RPC endpoints | curl command with expected response status and body |
+| Data | Change involves schema, migrations, queries | Database query or service call to verify state |
+| Performance | Change claims performance improvement | Benchmark description with target metrics |
+
+Do not duplicate verification methods already posted by other repos.
+
+Produce a table:
+
+```text
+| Acceptance Criterion | Verification Method | Type |
+|---------------------|--------------------| -----|
+```
+
+Every verification method must be specific enough that an automated agent could execute it.
+
+## Phase 6 -- Verdict
+
+Evaluate the findings and produce exactly one verdict:
+
+- **`NOT_RELEVANT`** -- No relevant code was found in this repository (Phase 1). The caller should add the triage label and skip implementation in this repo.
+- **`BLOCKED`** -- Ambiguities were found in Phase 3. Work MUST NOT proceed until the ambiguities are resolved by a human. The caller should post findings, add the triage label, and STOP.
+- **`PASSED_WITH_FINDINGS`** -- No ambiguities, but edge cases or verification findings were identified. Work can proceed. The caller should post findings and add the triage label.
+- **`PASSED`** -- No ambiguities, edge cases, or verification gaps found. Work can proceed. The caller should add the triage label.
+
+Output format:
+
+```text
+## Verdict: [NOT_RELEVANT | BLOCKED | PASSED_WITH_FINDINGS | PASSED]
+
+**Ambiguities found:** [count]
+**Edge cases identified:** [count]
+**Verification methods defined:** [count]
+```
+
+## Output Structure
+
+Structure all output with clear section headers so the caller can parse and post findings:
+
+```text
+## Triage: [TICKET-KEY] ([repo-name])
+
+### Ambiguities
+[Phase 3 findings, or "None found."]
+
+### Edge Cases
+[Phase 4 findings, or "None found."]
+
+### Verification Methodology
+[Phase 5 table, or "No acceptance criteria to verify."]
+
+## Verdict: [NOT_RELEVANT | BLOCKED | PASSED_WITH_FINDINGS | PASSED]
+```
+
+The caller is responsible for:
+1. Posting the findings as comments on the ticket (using whatever Jira mechanism is available)
+2. Adding the `claude-triaged-{repo}` label to the ticket
+3. If `BLOCKED`: stopping all work and reporting the ambiguities to the human