sesh-mode

Enforces a verification-first development workflow using TLA+ specs, DST, and formal methods.

11.6k|585|Updated Apr 13, 2021
One-click install
npx skills add https://github.com/quickwit-oss/quickwit --skill sesh-mode
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: sesh-mode
Source: https://github.com/quickwit-oss/quickwit/tree/main/.claude/skills/sesh-mode
Command: npx skills add https://github.com/quickwit-oss/quickwit --skill sesh-mode

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

When working on state machines, protocols, or critical data paths in Quickwit, ad-hoc coding can silently weaken safety invariants and user requirements. This Skill enforces a rigorous plan→spec→test→implement sequence so correctness properties are never silently dropped.

Core Features & Use Cases

  • Verification-First Sequence: Requires defining the plan and invariants, checking ADRs, reading TLA+ specs, and writing DST tests before any implementation code.
  • Spec Protection Protocol: Forbids silently weakening TLA+ invariants, Stateright properties, DST assertions, or English-language user requirements; mandates diagnosis and explicit user approval instead.
  • Production-Path Testing: Requires validating features through the actual HTTP/gRPC stack (quickwit server, OTLP ingestion, REST API queries) rather than bypassed unit-level tests.
  • Use Case: When implementing a new distributed protocol change in Quickwit, activate this mode to ensure the change is checked against existing TLA+ specs, covered by DST tests, and verified end-to-end through the real network stack.

Quick Start

Activate sesh mode and help me implement a new state machine change in Quickwit following the plan, spec, test, implement sequence.

Frequently Asked Questions about sesh-mode

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I use formal verification when developing Quickwit features?▼

Follow the plan→spec→test→implement sequence: define invariants, check the ADR index, read relevant TLA+ specs in docs/internals/specs/tla, write DST tests first, then implement. All verification layers share the same invariants as a single source of truth.

What should I do when a TLA+ invariant or DST assertion fails?▼

Read the failing trace and determine whether the implementation has a real bug or the property is over-strong. Never silently delete or weaken the property; if weakening seems right, present the replacement and the original safety claim to the user for explicit approval first.

How do I test Quickwit features through the production path?▼

Start the server with cargo run -p quickwit-cli -- run --config ../config/quickwit.yaml, ingest data via OTLP on localhost:4317, then query through the REST API on port 7280. Avoid bypassing the HTTP/gRPC server layers when validating indexing or search.

When should I not use a verification-first workflow?▼

This workflow targets changes touching state machines, protocols, or critical data paths. For trivial changes with no correctness invariants at stake, the full TLA+ and DST ceremony may be unnecessary overhead.

What is deterministic simulation testing in Quickwit development?▼

DST tests define correctness for stateful components and must be written before implementing new state machines. They sit alongside TLA+ specs and Stateright exhaustive checks in the verification pyramid, all sharing the same invariants.