# Lattice Agent Instructions

Lattice is harness-agnostic. Use these instructions in OpenClaw, Hermes, Codex, xAI-backed agents, Claude Code, or any agent that can run shell commands.

Memory:
Reach for Lattice when planning, testing, or reviewing a finite constrained surface with interacting states such as roles, permissions, feature flags, modes, providers, optional fields, component props, rendering branches, template variants, config matrices, lifecycle states, or cross-product edge cases. Extract a schema with parameters, values, and true constraints; run `lattice validate`; then run `lattice generate`; use the generated rows as the source of truth for plan review, rendered variants, fixtures, or missing tests instead of hand-enumerating pairwise combinations.

Default prompt:
Use $lattice-workflow. Inspect this feature, test surface, component variant space, template, or config matrix; extract a Lattice schema; validate it; generate pairwise rows; and use the rows to strengthen the plan, tests, fixtures, or visual review.

Workflow:
1. Check whether `lattice --help` works.
2. Extract one coherent schema with parameters, values, and true constraints.
3. Encode nonsensical or impossible combinations as constraints. Do not strip constraints and mark invalid rows after generation. Lattice supports exclusion-style constraints such as `invalid_pair` and `higher_order`, not only `conditional` parameters.
4. Run `lattice validate` before generation.
5. Run `lattice generate` and treat the generated rows as the source of truth.
6. Map rows to the active evaluator: plan review, tests, fixtures, rendered variants, screenshots, visual diffs, sandbox calls, or another harness-specific action.

Prefer JSON or YAML on stdin:

```bash
cat schema.json | lattice validate
cat schema.json | lattice generate
```

Schema format, with one example of each constraint type:

```yaml
model_name: checkout
strength: 2
parameters:
  user: [guest, member]
  payment: [card, paypal, apple_pay, invoice]
  device: [desktop, ios, android]
  region: [us, eu]
  currency: [usd, eur]
  shipping: [standard, express, pickup]
constraints:
  # invalid_pair: these two assignments never appear in the same row.
  - type: invalid_pair
    if: { parameter: payment, value: apple_pay }
    then_not: { parameter: device, value: android }
  # bidirectional: each assignment requires the other.
  - type: bidirectional
    pair:
      - { parameter: region, value: eu }
      - { parameter: currency, value: eur }
  # forward_dep: the source requires the target; the target may appear elsewhere.
  - type: forward_dep
    source: { parameter: shipping, value: pickup }
    target: { parameter: region, value: us }
  # conditional: defines a child parameter that only applies for some parent values.
  - type: conditional
    parameter: card_type
    values: [visa, mastercard]
    parent: payment
    applies_when: [card]
  # forced: this combination must appear in at least one row.
  - type: forced
    assignments:
      - { parameter: user, value: guest }
      - { parameter: device, value: ios }
      - { parameter: shipping, value: express }
  # higher_order: the last assignment is excluded only when all of if_all hold.
  - type: higher_order
    if_all:
      - { parameter: user, value: guest }
      - { parameter: region, value: eu }
    then_not: { parameter: shipping, value: pickup }
```

Every constraint needs a `type` key. Each assignment is `{ parameter: <name>, value: <value> }`.