SpecDeck logo

SpecDeck

Spec-first coordination for async coding agents.

Control deck

Every card is one Spec moving through human gates.

SpecDeck borrows the recognizability of a board, but the columns represent where a human decision is needed, not every internal agent state.

localhost:3000/board
Backlog01
SPEC-101

Clarify a product idea before any agent starts changing code.

Plan02
SPEC-102

Review Goal, Acceptance, and Checks before the Builder begins.

Review03
SPEC-103You review here

Inspect Checks and Evidence from the completed agent run.

Done04
SPEC-104

Freeze the Spec as the contract for what shipped.

Problem

Async agents move the bottleneck from typing code to reviewing work.

When several agents run in parallel, terminal output and PR diffs are too low-level for the human coordination layer.

Terminal agents are hard to see

They can execute, but they do not give a clear control surface for watching many parallel workstreams.

IDE agents stay synchronous

They work well at file level, but still assume one developer steering one active editing session.

Kanban tracks status, not trust

A board can show where work is, but it does not explain whether the result is proven enough to approve.

Evidence

Read the Checks, not the code.

Each Spec carries its Checks and the Evidence behind them. A passing Check with no Evidence never counts as green.

  • Evidence is required: tests, logs, screenshots, or video.
  • An independent Checker verifies the work, never the Builder.
  • Deterministic checks run first; model judging happens last.
SPEC-104Review

Shopping cart calculation

The user reviews the outcome at the Check and Evidence layer.

Tax is applied based on region

Evidence: unit tests passed, 12 of 12.

Discount codes are validated

Missing Evidence: no end-to-end trace attached.

The deck

Four columns, left to right.

Backlog and Plan shape intent before code. Review is where finished work waits for approval. Done freezes the Spec as the contract.

  1. Backlog01

    Ideas wait here before Planner turns them into a Spec.

  2. Plan02

    Review what is about to be built: Goal, Acceptance, and Checks.

  3. Review03

    Approve completed work at the Check and Evidence layer.

    You review here
  4. Done04

    The accepted Spec is frozen as the shipped contract.

The pipeline

Planner, Builder, Checker.

The agent relay separates intent creation, code execution, and verification so the same actor does not grade its own work.

  1. Planner

    Turns intent into a Spec: Goal, Acceptance, and Checks.

  2. Builder

    Executes one Spec in isolation. One agent per unit of work.

  3. Checker

    An independent model verifies the Evidence. It never grades its own work.

Architecture

A three-tier topology keeps agents behind a gateway.

The web app speaks to a FastAPI gateway over REST and SSE. The gateway coordinates a separate LangGraph Agent Server and owns secrets, persistence, and realtime fan-out.

01

Web deck

Next.js renders board, project context, Spec detail, Checks, Evidence, and diff views.

Next.jsshadcn/ui
02

FastAPI gateway

REST commands and SSE streams pass through the gateway so clients never talk directly to the agent server.

FastAPIRESTSSE
03

Agent server

Planner, Builder, and Checker run as LangGraph workflows behind a structured event contract.

LangGraphPlannerBuilderChecker

Persistence and realtime

Postgres stores app state while Redis pub/sub fans Builder and Checker events back to the board.

Postgres
Redis pub/sub
Tradeoffs

The design makes review cheap by narrowing what it tries to solve.

SpecDeck is not an IDE replacement. It is a coordination layer for deciding what agents should do and whether their output is proven.

Review gateSPEC / REVIEW / MERGE
  1. 01

    Review at intent level

    Control kept

    Optimized for approving Goals, Acceptance, Checks, and Evidence quickly.

    Cost accepted

    Developers still need a diff escape hatch for risky changes and final spot checks.

  2. 02

    Independent Checker

    Control kept

    Optimized for avoiding the Builder validating its own blind spots.

    Cost accepted

    Adds latency, model cost, and another event stream to operate.

  3. 03

    Single-user coordination first

    Control kept

    Optimized for one operator running many agents without collaboration overhead.

    Cost accepted

    Multi-user review, canvas workflows, and full IDE replacement are deliberate non-goals for this stage.

OutcomeCurrent proof

Concept validated through a scaffolded, mock-driven deck.

The repo has architecture decisions, a self-host skeleton, and a product-shaped frontend. Real Planner, Builder, and Checker logic is still the next milestone.

01

Product UI is tangible

Landing, workspace, board/list views, grouped swimlanes, filters, project context, Spec detail, Checks, Evidence, and Diff are present as mock-driven flows.

Evidence
02

Stack skeleton runs locally

The repo includes web, gateway, agent package boundaries, Postgres, Redis, and docker-compose wiring.

Evidence
03

Next milestone is real orchestration

The open work is wiring Planner, Builder, and Checker execution to live workspace state and evidence capture.

Next
Open source

Self-host the whole deck.

SpecDeck is designed to run in the owner's environment, with model keys and project workspaces kept behind the backend boundary.

  • Postgres, Redis, gateway, agents, and web are composed together.
  • Model keys stay server-side; the frontend gets events, not secrets.
  • The repository remains the system of record for Specs, context, and implementation.
~git clone https://github.com/timezlab/specdeck.git
~cd specdeck
~cp .env.example .env
~docker compose up -d
Network specdeck_default created
Container specdeck-db started
Container specdeck-web started
TimezLab

Solutions Design Lab. We architect scalable systems and pragmatic solutions that map directly to business intent.

Systems & Solutions

© 2026 TimezLab. All rights reserved.

Design with intent. Build to scale.