Skip to main content

Why Keel

Keel is a turn-based board engine for human/AI delivery teams. It is designed for teams that want planning, execution, and verification to live on one visible operating surface instead of being split across chat, tickets, scratchpads, and private memory.

This documentation starts in plain language on purpose. You do not need to know Keel's native vocabulary before you can understand what the system is trying to accomplish.

Turn-Based

Work advances through explicit moves

Instead of throwing tasks into a general pile, Keel expects each move to change the board in a visible way.

Human And AI

The operating surface is shared

People and agents read the same planning artifacts, work the same states, and close the same acceptance criteria.

Evidence-Backed

Completion requires proof

Stories close with recorded evidence, not just confidence. Keel treats missing proof as drift, not style.

What "turn-based" means in practice​

Most tools assume that more activity means more progress. Keel assumes the opposite: when the board is blurry, the team slows down even if everyone is busy.

A turn is a bounded move. It begins with orientation, advances one scoped slice, and ends with proof. That rhythm is what keeps human and AI collaboration legible.

01

Orient

keel health --scene

Read the board before acting. Check for drift, blocked work, and missing integrity.

02

Inspect

keel mission next --status

Understand what the system thinks matters now at the strategic and tactical level.

03

Pull

keel next --role operator

Take one role-scoped move from the delivery lane instead of browsing an unbounded backlog.

04

Ship

keel story submit STORY-ID

Move the slice into review only when the implementation and its evidence are ready together.

05

Close

keel story accept --role manager STORY-ID

Accept the slice with an explicit role, then let the next turn begin from a clean board state.

Translate first, then learn the board terms​

Keel uses a native vocabulary because it wants different types of work to mean different things. A mission is not just a bigger story, and a routine is not just a repeating ticket.

The docs will translate from familiar concepts into Keel terms as you go.

Everyday language

Objective

Keel term

Mission

The long-running outcome you are trying to achieve across multiple efforts.

Everyday language

Strategic track

Keel term

Epic

A major problem or opportunity inside the mission that deserves its own planning surface.

Everyday language

Tactical campaign

Keel term

Voyage

A planned delivery arc with SRS and SDD constraints before execution begins.

Everyday language

Executable slice

Keel term

Story

The smallest tracked unit that can be started, submitted, accepted, and evidenced.

Everyday language

Research vector

Keel term

Bearing

A discovery move used to reduce fog before you freeze requirements or architecture.

Everyday language

Scheduled contract

Keel term

Routine

Recurring work that pulse can materialize into the board without inventing new scope.

What Keel does and does not own​

Keel owns the board contract:

  • what work exists
  • what state each unit is in
  • what constraints were planned up front
  • what proof is attached before closure
  • what recurring work may be materialized automatically

Keel does not try to replace the rest of your toolchain:

  • your editor or IDE
  • your preferred AI harness or model vendor
  • design tools
  • source control hosting
  • deployment runtime

That boundary is deliberate. Keel is the operating layer, not the entire stack.

That rule still holds when Keel is embedded inside a larger runtime. Keel continues to own planning truth. A runtime such as Keeper can own provider ingress, routing, execution, and replay, but it should lower external work through a formal mission-request boundary instead of inventing board state out-of-band.

If you are integrating Keel with GitHub issues or a multiplayer runtime, read Keeper Boundary And Mission Requests.

Read the docs in this order​

  1. Install the CLI and verify your local path.
  2. Scaffold a project and take the first turn.
  3. Learn the CLI interface, pacemaker contract, and scene surfaces.
  4. Learn the board model, Keeper boundary, lanes, and verification loop.
  5. Move into the persona track that matches your job.

Start Here

Install Keel

Pick a local install path, verify the CLI, and prepare a repo for its first Keel scaffold.

Go to installation

First Turn

Scaffold a project and make the first move

Create a new project scaffold, read the initial signals, and stand up the first mission, epic, voyage, and story.

Take the first turn

CLI Interface

Read the operating surface directly

Learn the command families, pacemaker contract, and scene surfaces that make Keel readable in a terminal.

Browse the CLI