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.