Tessl — Summary

Tessl is a "steering tile" and agent enablement platform that gives coding agents structured, versioned skills, rules, and evaluation scenarios for spec-driven development — teaching agents to gather requirements, write .spec.md files, and get explicit approval before writing any code.

Problem it solves: Vibecoding produces apps that hallucinate APIs, have useless error handling, lack tests, and can't be verified against intent; Tessl's spec-before-code rule enforces that agents never begin implementation without an approved spec, and its one-question-at-a-time rule prevents requirement-gathering from being rushed.

Distinctive trait: Tessl ships a custom tile format (tile.json) deployed via tessl install, a commercial registry at tessl.io, and an evaluation harness (tessl eval run) for verifying that skills behave correctly — making it the only framework in the corpus with a first-party evaluation/grading system for its own skills.

Target audience: Development teams using MCP-compatible agents (Claude Code, Cursor, etc.) who want a methodology tile that installs once and consistently enforces spec-driven development across all developers without any per-developer configuration.

Production-readiness: v2.0.1; actively maintained with 38 stars and 2 contributors; published on the Tessl registry at tessl.io/registry/tessl-labs/spec-driven-development. Founded by Guy Podjarny (founder of Snyk).

Differs from seeds: Closest to spec-kit in structure (4 skills + 3 rules mapping to spec-kit's 9 commands + 9 skills), but Tessl introduces a proprietary tile distribution format with versioned registry hosting, a tessl eval run evaluation harness (9 evaluation scenarios graded by the framework), and a commercial platform layer. Unlike spec-kit which requires a Python CLI, Tessl installs via npx @tessl/cli install and drops files into .tessl/ for any MCP-compatible agent to read without framework coupling.

Tessl — Origin and Philosophy

Origin

Tessl was founded in 2024 by Guy Podjarny (LinkedIn: guypod), founder and former CEO of Snyk. The company (tesslio on LinkedIn, @tesslhq on X) builds the "agent enablement platform" — a layer between agent CLIs and developer workflows that provides structured skills, evaluations, and a tile registry.

The spec-driven-development tile (tesslio/spec-driven-development-tile) is one published tile on the Tessl registry.

Philosophy (from website schema)

"Tessl is the agent enablement platform that gives coding agents structured, versioned context, such as skills and their performance evaluations, to build reliable AI-powered software."

On the problem:

"Vibecoding (prompting without structure) produces apps that: hallucinate APIs from stale training data, have useless error handling ('Something went wrong, try again'), lack tests, can't be verified against intent."

On the solution:

"Spec-driven development produces apps where: requirements are explicit and reviewable, implementation can be verified against specs, tests trace back to documented requirements, you maintain control over what gets built."

On the tile model:

"This is a steering tile — it provides guidance that becomes part of the agent's context. When you install it: Tessl adds the tile's files to your project's .tessl/ directory; your MCP-compatible agent reads this context; the agent follows the methodology described in the tile's skills and rules. No special commands. No annotations. No framework."

The Tile format

A Tessl tile is a versioned bundle of:

• Skills — what the agent should do (structured workflows)
• Rules (alwaysApply: true/false) — what the agent must never do
• Docs — reference material the agent reads
• Scripts — shell validators the human runs
• Evals — graded scenarios that verify skill behavior

Tiles are published to the Tessl registry and installed into .tessl/ directories. Versioning, publishing, and evaluation are all managed by the tessl CLI.

Tessl — Architecture

Distribution

• Type: tile via Tessl CLI + registry
• CLI binary: tessl (via npx @tessl/cli or global install)
• Source: https://github.com/tesslio/spec-driven-development-tile
• Version analyzed: v2.0.1
• License: MIT (tile source); commercial platform (tessl.io)

Install

# Via Tessl CLI
tessl init
tessl install tessl-labs/spec-driven-development

# Via npx (no global install required)
npx @tessl/cli install tessl-labs/spec-driven-development

Required runtime

• Node.js (for tessl CLI)
• Any MCP-compatible agent (Claude Code, Cursor, etc.)

Target AI tools

Any MCP-compatible agent that reads files from .tessl/ directory. Explicitly supported: Claude Code, Cursor.

Directory structure (after install)

your-project/
└── .tessl/
    ├── skills/
    │   ├── requirement-gathering/SKILL.md
    │   ├── spec-writer/SKILL.md
    │   ├── spec-verification/SKILL.md
    │   └── work-review/SKILL.md
    ├── steering/
    │   ├── spec-before-code.md     (alwaysApply: true)
    │   ├── one-question-at-a-time.md (alwaysApply: true)
    │   └── spec-format-compliance.md
    ├── docs/
    │   ├── spec-format.md
    │   └── spec-styleguide.md
    └── scripts/
        ├── validate-specs.sh
        └── check-spec-links.sh

Tile manifest (tile.json)

{
  "name": "tessl-labs/spec-driven-development",
  "version": "2.0.1",
  "skills": {
    "requirement-gathering": { "path": "skills/requirement-gathering/SKILL.md" },
    "spec-writer": { "path": "skills/spec-writer/SKILL.md" },
    "spec-verification": { "path": "skills/spec-verification/SKILL.md" },
    "work-review": { "path": "skills/work-review/SKILL.md" }
  },
  "steering": {
    "spec-before-code": { "rules": "rules/spec-before-code.md" },
    "one-question-at-a-time": { "rules": "rules/one-question-at-a-time.md" },
    "spec-format-compliance": { "rules": "rules/spec-format-compliance.md" }
  }
}

Spec format (.spec.md)

---
name: User Authentication
description: Login and session management
targets:
  - ../src/auth/*.py
---

# User Authentication

Users can log in with email and password.

[@test] ../tests/auth/test_login.py

## Error Handling
- Invalid credentials return 401
  [@test] ../tests/auth/test_invalid_credentials.py

Key elements:

• targets: files/globs the spec describes
• [@test]: inline references to tests verifying each requirement

Tessl — Components

Skills (4)

Rules (3)

Docs (2)

Scripts (2 — run by human/CI)

Evals (9 scenarios)

Evaluation scenarios for verifying skill behavior (tessl eval run .):

1. Spec authoring from confirmed requirements
2. Requirements gap analysis against existing specs
3. Work review catching implementation drift
4. Spec drift detection after file refactoring
5. Extending an existing spec with new requirements
6. Decomposing a vague request into concrete gaps
7. Interview question preparation (one-question-at-a-time)
8. Handling code written without a spec
9. Trivial changes that should bypass the full workflow

CI workflows (GitHub Actions)

Tessl — Uniqueness and Positioning

Differs from seeds

Tessl is closest to spec-kit structurally (4 skills enforcing a requirement → spec → implement → verify cycle), but introduces three genuinely novel dimensions: (1) a proprietary tile distribution format with a commercial versioned registry and CI-enforced publishing workflow; (2) a first-party evaluation harness (tessl eval run) with 9 graded scenarios that verify skills behave correctly — no other framework in the seed corpus or this batch ships its own skill grading system; (3) alwaysApply: true rules that fire on every interaction without requiring user invocation, closer to superpowers' Iron Laws than to spec-kit's per-command hooks. Unlike kiro (closed IDE with proprietary primitives), Tessl's tile model works with any MCP-compatible agent. Unlike openspec (npm package generating spec files), Tessl is a methodology container with versioning, evaluation, and CI — not just a file generator.

Positioning

Tessl is founded by Guy Podjarny (Snyk founder), targeting enterprise teams who want methodology-as-a-versioned-package: install once, enforce consistently, update centrally, measure with evals. The registry model suggests a future where teams share and version their custom methodology tiles the way they share npm packages.

Observable failure modes

1. Platform dependency — the tile format and registry are commercial; if Tessl the company changes pricing or access, tile distribution breaks
2. Passive enforcement — alwaysApply rules rely on the agent's attention to .tessl/ files; unlike hook-enforced constraints (WORCA's pre_tool_use.py), a model may ignore them under context pressure
3. No autonomous execution — skills provide structured workflows but don't auto-execute; still requires human to type the triggering prompt
4. Spec drift — spec-verification must be invoked; no hook-based auto-verification after file changes

Explicit antipatterns

• Implementing without an approved spec (enforced by spec-before-code rule)
• Asking multiple questions at once during requirement gathering (one-question-at-a-time)
• Treating silence as approval for a spec
• Emergency hotfixes without retroactive spec writing