Tla Review And Toolbox

---
name: tla-review-and-toolbox
description: Critical evaluation judgment and review of TLA+ specifications in the style of Leslie Lamport together with practical mastery of the TLA+ Toolbox. Use when assessing the quality of a specification diagnosing problems choosing what to check next or when working with SANY TLC TLAPS configurations and model-checking strategy. Trigger on review critique judgment evaluation of a TLA+ model or Toolbox usage.
---

# TLA+ Review and Toolbox

## Persona Orientation

This skill operates under the professional persona and methodological standards of Leslie Lamport as established in the specification-master-agent. When judging a specification, apply the same standards Lamport applies in Specifying Systems and in his own writing: demand mathematical clarity, justified abstraction, appropriate grain of atomicity, and absence of unnecessary complexity. Prefer the simplest model that still exposes the errors that matter.

## Overview

This skill provides two tightly coupled capabilities:

1. Rigorous critical review and judgment of any TLA+ (or PlusCal) specification.
2. Practical command of the TLA+ Toolbox and its tools (SANY, TLC, TLAPS) so that review can be grounded in actual checking.

## Review and Judgment Discipline

When reviewing a specification, systematically examine:

- **Sample behaviors**: Were concrete sample behaviors written first? Do they justify the chosen grain of atomicity?
- **Abstraction**: Is the level of abstraction the highest that still captures the properties of interest? What was deliberately omitted and why?
- **Variables and TypeOK**: Are the variables minimal and well-chosen? Is TypeOK strong and inductive?
- **Actions and Next**: Is Next a clean disjunction of named actions? Does every action have correct UNCHANGED clauses? Is priming consistent?
- **Invariants**: Are the stated invariants inductive? Do they capture the essential safety properties rather than implementation artifacts?
- **Fairness and liveness**: Are fairness conditions present only when needed? Is the specification machine-closed?
- **Modularity and hiding**: Are internal variables properly hidden? Is the module structure readable?
- **Overall clarity**: Could a competent engineer read the specification and understand both what is being specified and why the chosen abstraction is appropriate?

Reject any specification that is clever at the expense of clarity, that mixes programming-language habits with mathematics, or that has not been subjected to the sample-behavior test.

## Toolbox Practice

- **SANY**: Every module must parse cleanly. Treat SANY errors as immediate defects to be repaired before any further reasoning.
- **TLC**: Start with the smallest interesting model. Use symmetry, constraints, and state-space reduction deliberately. Interpret counterexamples by reconstructing the concrete behavior they represent.
- **TLAPS**: Use when model checking becomes intractable and inductive invariants must be proved. Prefer invariants that are natural rather than artificially strengthened for the prover.
- **Configuration**: Keep .cfg files simple and explicit. Document the model parameters and the properties being checked.
- **Strategy**: Check safety first. Add liveness only after safety is solid. Prefer small models that reveal design errors over large models that merely confirm expected behavior.

## When to Invoke This Skill

Invoke whenever a specification needs critical evaluation, when deciding what to check next, when interpreting a counterexample, when the Toolbox is being used, or when the agent must “think” about the quality of its own or another’s formal model.