What is Stella Loop

Stella Loop is an agent-native project management tool for loop-based, iterative software development — an alternative to traditional trackers, built for teams whose development work is increasingly carried out by and alongside coding agents.

The name describes the model. Every project declares a North Star constellation — a set of documents and tenets describing what the product should become — and the tool’s job is to continuously pull the product toward that aim. Work is not a one-way flow of hand-written tickets; it is a repeating loop of analysis, proposal, planning, implementation, and review, with 0–100 scores that make progress measurable rather than anecdotal.

The problem it solves

Traditional trackers assume humans invent the work: someone notices a problem, writes a ticket, and the tool manages the ticket’s states. That model breaks down in two ways:

1. Discovery is unmanaged. Where work comes from — noticing gaps, assessing quality, deciding what matters next — happens outside the tool, so priorities are anecdotal and unrepeatable. Stella Loop makes discovery a first-class, tool-managed half of the lifecycle: signals capture what the world tells you, intents drive analyzer runs over the actual codebase, analyzers produce scored reports, and reports yield proposals that compete in a pool before anything is committed.
2. Agents are bolted on. Coding agents can execute tickets, but most tools give them no native way to discover work, read context, or report results. In Stella Loop, agents are first-class users: every capability a human has in the UI is available through the stella CLI, the public API, and a generated MCP server — and that parity is checked in CI, not promised.

Who it is for

• Product managers and developers get a dense, keyboard-first, command-palette-driven interface with realtime liveness — running loops, working agents, and moving scores are always visible.
• Coding and analysis agents drive the identical model through the stella CLI (self-discoverable from --help alone), the /api/v1 HTTP API beneath it, and an MCP server generated from the same capability map.

How it differs from an issue tracker

• Work has provenance, not just a reporter. Every epic traces back through proposal → report → intent — and, through signals, onward to the external message that motivated it.
• Commitment is a modeled moment. Epics are born only by promotion out of the proposal pool. There is no direct “create epic” path in the UI, the API, or the CLI.
• Quality is a number. Analyzers score the codebase 0–100 overall and per area, with versioned rubrics so runs stay comparable.
• Loop-backs are modeled, not improvised. Review can send work back to implementation (fix) or back to planning (re-spec), and learnings from finished work seed the next intent.
• Alternatives can race. Competing proposals can be promoted as a tournament: one epic, one candidate per approach, each on its own branch, with review selecting the winner.
• The pipeline is opinionated; the tooling is pluggable. The loop shape is the product’s opinion. Spec tools (OpenSpec is the default), analyzers, and version control (git by default, Jujutsu supported) sit behind adapter interfaces.

Product surfaces

One backend, one interface model, several clients:

Where to go next

Start with Getting started to run your first loop, or read The loop to understand the model end to end. Setting up a coding agent? Go straight to Agents.