Skip to main content

AI rules

AI rules are standing guidance a connected assistant reads before it writes anything. They are how you make an assistant write test cases the way your team writes them, without repeating yourself in every prompt.

Where they live​

Settings → AI Rules. Each rule has a name, a body, an enabled switch, and optionally a project — a rule with no project applies across the organization.

The default rule​

Every new organization is given one, called Test Case Guidelines:

- Include both positive and negative test scenarios
- Consider edge cases and boundary conditions
- When creating a test from a requirement, link the requirement to it

Three lines somebody would otherwise have to think to write down, and the ones most worth having. An assistant left to itself writes the happy path, stops, and leaves the test unattached to whatever asked for it.

The third line is the one that pays for the rest. Coverage is derived from links, so a test written for PROJ-142 and never linked to it leaves that requirement reading as uncovered — the traceability page's whole point, reported wrong, by the tool that was supposed to fill it in.

The default is seeded as an ordinary rule, not hardcoded, so you can edit it, switch it off, or delete it. A default the customer cannot change is not a default; it is our rule wearing yours.

:::note If your organization has no rules at all Organizations created before AI rules existed never got the starter one. The empty state on Settings → AI Rules has an Add the default rule button that gives it to you. It refuses once the organization has any rule, so it cannot re-add one you deliberately deleted. :::

Writing good rules​

Rules are instructions to a model, so the usual things apply:

  • Be specific about the output, not the attitude. "Write thorough tests" does nothing. "Every case must have at least one negative scenario" does.
  • Say what to link. Assistants forget relationships far more often than they forget content.
  • Encode your conventions. Naming, where cases go, which tags you use, what a step's "additional data" is for.
  • Keep them short. Rules are prepended to real work; a page of them crowds out the task.

A reasonable set for a team might add:

- Name cases as "<action> <expected outcome>", e.g. "Reject an expired card at payment"
- Put new cases in the folder matching the feature area, never at the root
- Tag anything touching money with "payments"
- One assertion per step; if a step needs "and", it is two steps

Scoping to a project​

A rule with a project set applies only to work in that project. Use this for conventions that genuinely differ — a mobile project's steps look different from an API project's — rather than for splitting one set of conventions across several rows.

Turning one off​

The enabled switch leaves the rule in place but stops it being sent. That is usually better than deleting, because a rule that was turned off for a reason is a rule somebody can turn back on when the reason expires.