@codyswann/lisa 4.74.9 → 4.75.0

package/plugins/lisa-devin/skills/lisa-task-decomposition/SKILL.md

@@ -0,0 +1,195 @@
+---
+name: lisa-task-decomposition
+description: "Methodology for breaking work into ordered tasks. Cross-repo source PRDs and coordination containers stay cross-repo; each buildable leaf task gets a single-repo scope, 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")
+
+### 1.5. Preserve Cross-Repo Containers, Split Leaf Work by Repository
+
+Start from the right shape:
+
+- A source PRD may span multiple repositories.
+- Coordination containers may also span multiple repositories.
+- Buildable leaf work units must be implementable inside exactly one repository.
+
+That last point is a hard invariant — downstream validators (`jira-validate-ticket`, `github-validate-issue`, `linear-validate-issue`) gate writes on it, so a cross-repo leaf will fail to be created.
+
+Apply this rule by layer:
+
+| Layer | Repo scope |
+|-------|------------|
+| **PRD / source initiative** | MAY span repos — it describes the full initiative |
+| **Epic, Story, Spike** | MAY span repos — these are coordination containers |
+| **Task, Bug, Sub-task, Improvement** | MUST name exactly one repo — these are buildable leaf work units |
+
+If a candidate work unit naturally touches multiple repos (e.g., "add field to backend API and consume it in mobile app"), do not write it as one ticket. Instead:
+
+1. Split it into one work unit per repo (e.g., `[backend-api] Add field to /users endpoint`, `[mobile-app] Display new field on profile screen`).
+2. Group the per-repo units under a single parent Story (or Epic, if the parent Story already exists). The parent stays cross-repo; the children do not.
+3. Encode the order via `Dependencies` in step 4 — typically the producing repo (backend) blocks the consuming repo (frontend/mobile).
+4. Tag each work unit with `[repo-name]` as a summary prefix so the repo is visible in tracker lists at a glance.
+
+Reject any work unit whose acceptance criteria reference behavior in a different repo from the one it's scoped to. If you find yourself writing "and the frontend should also...", that's a signal to split.
+
+This is the **decomposition-time** strategy (greenfield — you are creating the tickets now, so a cross-repo PRD can stay whole, its Epic/Story/Spike containers can stay cross-repo, and a parent Story + per-repo children is the natural shape). It is distinct from the **work-time** strategy in the `repo-scope-split` rule, which applies when an agent picks up an *already-existing leaf ticket* to implement and discovers it spans repos: there it narrows the original in place and spins off sibling work units rather than introducing a new parent. Use the phase-appropriate one; do not mix them.
+
+### 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
+
+For a **frontend task** -- one that adds or changes a user-observable surface -- the `bdd-e2e-coverage` rule makes two further criteria mandatory on the item itself, never left implied: (a) the Gherkin scenarios it adds or changes in the project's behavior contract, with their stable IDs and required platforms, and (b) aligned e2e automation in the project's configured runner for each of those platforms, with the coverage gate passing and the matrix and burndown regenerated. Carry both into the item's Validation Journey. A project with no behavior contract yet does not get an exemption -- the first such task carries the bootstrap scaffolding as a deliverable, scoped to its own behavior (cite the rule; do not restate its bootstrap steps).
+
+For a task that adds or changes **persistent state** -- anything the system writes that outlives the process that wrote it, including identity-provider objects, object storage, search indexes, queues, caches and derived views, not only rows -- the `reset-seed-coverage` rule makes two further criteria mandatory on the item itself, never left implied: (a) every entity it introduces or changes is classified in the project's state contract with a reason and an owner, and (b) anything classified `fixture-owned` has a declared ownership predicate and an actual sweep, with the state-classification check passing. Carry both into the item's Validation Journey. A project with no state contract yet does not get an exemption -- the first such task carries the bootstrap scaffolding as a deliverable, scoped to its own state (cite the rule; do not restate its bootstrap steps).
+
+### 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
+
+### 4.5. Classify Any New Material Dependency
+
+Step 4 maps dependencies *between tasks*. This step covers third-party
+dependencies a task proposes to **add**.
+
+A dependency is **material** if its failure, disappearance, or bad update would
+break something a user can see, or would cost real time to replace. If a work
+unit proposes adding one, the work unit must, before it is buildable:
+
+1. **Name its trust class** — exactly one of: mature ecosystem primitive,
+   fast-moving standard implementation, build/development tool, runtime-critical
+   service client, thin wrapper suitable for in-house ownership, or
+   temporary/experimental dependency. See the `dependency-trust-classes` rule
+   for what each class means and why it is trusted.
+2. **State the class's required evidence** — the detection evidence that class
+   demands, and whether product/human ratification is required before the work
+   starts. Runtime-critical service clients and expiry extensions on temporary
+   dependencies always require ratification; a work unit that needs it and does
+   not say so is not ready.
+3. **Include updating `.lisa/DEPENDENCY_DECISIONS.md`** in its acceptance
+   criteria, so the record entry lands in the same change as the dependency.
+
+If nobody can pick a class, that is the finding — resolve it before accepting
+the work unit, not after the package is installed.
+
+### 4.6. Inherit the Confidence-Rebuild Kit When Ownership Moves In-House
+
+Step 4.5 covers dependencies a task proposes to **add**. This step covers
+dependencies a task proposes to **remove, replace, or internalize** — vendor,
+fork-and-maintain, or reimplement ourselves.
+
+When ownership moves in-house, the risk stops being "do we trust upstream" and
+becomes "did we prove we rebuilt the capability." A work unit that moves a
+material dependency in-house **inherits all seven acceptance criteria** of the
+`dependency-internalization-kit` rule, each written as an acceptance criterion
+of the work unit:
+
+1. **Real corpus** — did we test it on real inputs, not toy examples?
+2. **Conformance fixtures** — does the new code do what the dependency did?
+3. **Negative fixtures** — does it still reject what it should reject?
+4. **Coverage as a gap detector** — what behavior is still untested?
+5. **Provenance and license review** — where did this code come from, and are we
+   allowed to use it?
+6. **Migration and update plan** — how do existing call sites move, and how does
+   the new code stay current?
+7. **Rollback or replacement criteria** — what would make us go back, and to
+   what?
+
+The only way out is an **explicit non-material justification** written into the
+work unit — one reviewable sentence saying why this dependency's failure or
+disappearance breaks nothing a user can see and costs no real time to replace.
+Silence is not a justification.
+
+**Do not over-apply the kit.** A routine version bump of a trusted dependency
+**within its existing trust class** does not move ownership, so it does not
+inherit the kit — its bar is that trust class's own detection evidence and
+cadence. The same is true of swapping one third-party dependency for another,
+which moves trust to a different upstream rather than in-house. Add the kit only
+when ownership moves in-house; the exception is a bump taken *as* a fork or
+declined *in favor of* owning the code, which is an internalization regardless of
+how the ticket is titled.
+
+### 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: [[repo-name] imperative description]
+- **Repository:** [single repo name, or N/A for Epic/Story/Spike]
+- **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: [[repo-name] imperative description]
+- **Repository:** [single repo name, or N/A for Epic/Story/Spike]
+- **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
+- Every Task / Bug / Sub-task / Improvement is scoped to exactly one repo -- if the work spans repos, split into per-repo work units under a shared parent Story (see step 1.5)
+- Any task proposing a new material dependency names its trust class, states that class's required evidence and whether human ratification is needed, and updates `.lisa/DEPENDENCY_DECISIONS.md` in the same change (see step 4.5) -- a proposed material dependency with no named class is not ready to build
+- Any task removing, replacing, or internalizing a material dependency carries all seven confidence-rebuild kit criteria -- corpus, conformance, negative fixtures, coverage-as-gap-detector, provenance/license, migration/update plan, and rollback criteria (see step 4.6) -- unless it explicitly justifies why the dependency is non-material; a within-trust-class version bump does not carry the kit
+- 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/lisa-devin/skills/lisa-task-triage/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: lisa-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/lisa-devin/skills/lisa-tdd-implementation/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: lisa-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": "ui-recording|api-test|cli-test|database-check|manual-check|documentation",
+    "command": "the proof command — must run the actual system (NOT test/typecheck/lint, those are quality gates)",
+    "expected": "what success looks like — observable system behavior"
+  }
+}
+```
+
+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
+- For a Fix task, or a Build task that changes user-visible behavior, include a regression test at the highest practical observation level for the reported surface. If the project has a browser, device, or end-to-end harness for that platform (for example Playwright, Maestro, Detox, Cypress, or an equivalent runtime), the RED test plan must include a deterministic spec against the reported surface, using mocked or seeded data where needed.
+- The team lead may not waive, defer, or mark that user-visible regression spec as optional, "if cheap", or equivalent. The only exits are a recorded absence of an end-to-end harness for the affected platform, or a genuine technical blocker with a linked build-ready follow-up ticket created before merge and referenced from the PR and source work item.
+- For frontend work, the `bdd-e2e-coverage` rule governs what that spec is sealing: before writing it, add or update the Gherkin scenario with its stable ID in the project's behavior contract, then write aligned automation in the project's configured runner for each platform the scenario requires. The scenario is the specification the RED test encodes — write the scenario first, in the same PR.
+- A regression spec is not complete merely because it exists. Completion evidence must prove the spec actually ran and passed in PR CI with a named log line, reporter output, or equivalent execution record. Guard against `test.skip`, suite-level environment gates, shard filters, and "0 tests" passes.
+- When the work item **prescribes an existing test as the control** — "that test must go red; if it still passes the fix did nothing" — the `control-reachability` rule governs what a green control means. It is two facts, not one: the change had no effect (revisit the change), or the fixture never reached the changed path (fix or extend the control — do **not** revert). They demand opposite actions, and the cheaper reading wins by default when nothing forces the distinction. **Establish which holds before acting on the stopping rule, and prove reachability by execution, never by reading the fixture** — a temporary `throw` at the top of the changed block run under that one test, or coverage scoped to that test alone. Never revert on an unexplained green; an unexplained control is a blocked observation, not a verdict. If the item carries a `[CONTROL: <test> | reaches: <input>]` marker, that marker is the claim you are checking.
+
+### GREEN Phase
+
+- Write the minimum production code to make the test pass
+- Do not optimize, do not add features beyond what the test requires
+- Read `designSource.enabled` in `.lisa.config.json` before preparing design-source instructions. Only boolean `false` opts out: omit the design-source step and do not request DESIGN-SOURCE markers, Figma nodes, or Figma access for this obligation. Absent, true, or invalid values keep enforcement enabled.
+- When enabled, for any UI surface the implementation adds or changes, the `design-source-of-truth` rule requires its design-source declaration to land in the same commit as the surface it describes — `DESIGN-SOURCE: <figma-url>` when the surface is backed by a Figma node (sync it back first if Figma access exists), or the exception marker `DESIGN-SOURCE: none — not in Figma` when it genuinely is not captured at the source. `scripts/design-source-gate.mjs` fails closed on an undeclared surface. Cite the rule; do not restate its marker grammar here.
+- Separately, the `design-value-binding` rule governs where each *value* on that surface came from: in an axis with a published variable collection, bind the variable and use a screenshot only to verify; in an axis with none, measure and record what you derived. A literal in a typed axis is a block, not a TODO. Cite the rule; do not restate its conditions here.
+- 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/lisa-devin/skills/lisa-tear-down-automations/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: lisa-tear-down-automations
+description: "Remove recurring Lisa automations that /setup-automations registered for this project — either the whole lisa-auto-<project>-* fleet by default, or one named loop registration when approving a policy-obsolete proposal — using the CURRENT runtime's native scheduler — Codex automations or, on Claude, /schedule. This skill is a declarative specification: it identifies WHICH automations to remove; it does not run teardown scripts. Carries no fixed list of loops for fleet teardown: the registration set is the roster. Removes only this project's Lisa automations — never other projects' automations or non-Lisa ones. Leaves checked-in runbook files on disk. The inverse of /setup-automations."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Tear down Lisa automations: $ARGUMENTS
+
+This skill is a **specification, not a script.** It tells the current runtime which recurring Lisa
+automations to remove — the ones `/setup-automations` created for THIS project — and the runtime
+removes them with its **native** scheduling mechanism. With no loop argument it removes the whole
+project fleet. With a loop id argument (for example `monitor` or `learnings-audit`) it removes only
+that one registered loop.
+
+## Runtime scheduler (branch on the current runtime)
+
+- **Codex** → list Codex automations and delete the `lisa-auto-<project>-*` set via the native
+  automations mechanism (prefer the native delete over hand-removing
+  `~/.codex/automations/<id>/`, which is only the backing store).
+- **Claude** → use **`/schedule`** to list and remove the matching recurring routines.
+- **Other runtimes** → use the runtime's native recurring-task mechanism. If it has none, state that
+  and stop.
+
+## Scope (remove only what setup created)
+
+- By default, remove **every** automation `/setup-automations` registered for the current project — the whole
+  set found under the stable `lisa-auto-<project>-` name prefix, whatever it currently contains.
+  **Membership is registration, not a roster** (`automation-runbook-contract`): sweep the prefix and
+  remove what is there. Do **not** work from a fixed list of loop names — a list drifts the moment a
+  loop is added, which is exactly how the opt-in gardener came to be orphaned.
+- When `$ARGUMENTS` names a loop id from a `policy-obsolete` teardown proposal, remove only that
+  loop's registration under the same prefix, e.g. `lisa-auto-<project>-monitor`. Report every other
+  project automation left in place. If the named loop is absent, that single-loop teardown is a clean
+  no-op; do not widen it into a fleet teardown.
+- This explicitly includes the opt-in **`learnings-audit`** gardener when it is registered:
+  `/setup-automations learnings-audit=true` registers it under the same prefix, so teardown removes
+  it with the rest. A conditionally-skipped loop (e.g. `exploratory-bugs` on a stack without
+  `exploratory-qa`) simply is not in the sweep.
+- **Never** remove automations for a different project, or any non-Lisa automation (e.g. unrelated
+  crawlers/ingestors). Match strictly on the `lisa-auto-<project>-` prefix for THIS project; when in
+  doubt about an automation's ownership, leave it and report it rather than deleting it.
+- **Idempotent** — an automation that is already absent is a no-op, not an error. Re-running when
+  the prefix sweep finds nothing is a clean, successful no-op.
+- **Leave the runbooks alone.** The checked-in `.lisa/automations/<loop-id>.runbook.md` files that
+  `/setup-automations` scaffolded are project knowledge and the historical record of what these
+  loops did. Teardown removes scheduler registrations only; it never deletes, edits, or moves a
+  runbook file. An operator who wants them gone removes them deliberately, in git.
+
+## Answering a `policy-obsolete` teardown proposal
+
+Running this skill with the proposing loop id is the **approve** answer to a loop's own retirement
+proposal. When a registered loop's runbook **Retirement condition** trips, that loop records the
+`policy-obsolete` run outcome and files exactly one ticket recommending its own teardown
+(`automation-runbook-contract`) — and then keeps running at its normal cadence, because a loop never
+removes its own registration.
+Teardown is **always human-invoked**: it is never
+triggered by a loop, on any schedule, for any outcome. The operator has three answers, and only the
+first brings you here. The proposal authorizes only that loop's registration unless the human
+explicitly asks for fleet teardown.
+
+1. **Approve** — run this skill with the proposal's loop id, e.g.
+   `/lisa:tear-down-automations monitor`. When it has run, close the proposal as **Completed**: the
+   loop-scoped teardown it asked for actually happened, and Completed is the close reason that says
+   so.
+2. **Decline** — close the proposal as **Not planned** (that close reason is what stops the loop
+   re-raising it; **Completed** would leave a later re-file open). The loop simply continues at its
+   normal cadence, and nothing is removed.
+3. **Re-cadence** — you pick the longer cadence and re-register the loop with
+   `/lisa:setup-automations`; the loop never adjusts its own schedule. The proposal's evidence
+   carries the loop's **current cadence** as the baseline to choose against, plus a one-line summary
+   of its recent runs. Then close the proposal as **Completed** — the schedule change is the action
+   it asked for.
+
+## Report
+
+List each automation removed by name. For "already absent", compare against the one source of truth
+— the fleet `scripts/automation-status-expected-fleet.mjs` (`resolveExpectedAutomationFleet`)
+resolves for this project — and name anything it expects that the sweep did not find; that is a
+no-op, not an error. Do not invent an expected set of your own.
+
+Then state, in the operator's words, that the runbook files under `.lisa/automations/` were left on
+disk **and why**: they are the written record of what those jobs did, kept on purpose, and if you
+do not want them you delete them yourself in git. Finally, confirm that nothing outside this
+project's `lisa-auto-<project>-` prefix was touched. Write it so a non-technical operator can
+confirm what happened without reading code.

package/plugins/lisa-devin/skills/lisa-test-strategy/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: lisa-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. **For frontend scope, start from the behavior contract** -- read the project's Gherkin scenarios and coverage map, identify which scenario IDs this work adds or changes, and treat each required scenario-platform obligation as a strategy line item per the `bdd-e2e-coverage` rule
+5. **Check coverage gaps** -- run existing tests to understand current coverage of affected files
+6. **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
+- For frontend work, the strategy is not complete until every required scenario-platform obligation has aligned e2e automation in the project's configured runner for that platform, or a dated waiver naming the runner limitation (`bdd-e2e-coverage`). A unit test, a route boot, or a passing test on a different platform never seals an obligation
+- For work that adds or changes persistent state, the strategy is not complete until each new entity is classified in the project's state contract and anything `fixture-owned` has a sweep, per the `reset-seed-coverage` rule. Per-flow self-cleanup is not a strategy: a flow that deletes what it created only on its happy path leaks on every failure in between, which is how state pollution becomes an unreproducible flake months later
+- 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