Showcase
Teams shipping real software with stella, and stella-examples, an open library with a working example for every setting you can configure.
Real teams ship real software with stella in the loop. Each entry below names who they are, what they build, and how stella fits into their work.
Oxagen
oxagen.sh builds Oxagen using the stella CLI as its code agent. Day-to-day feature work, refactors, and fixes all run through stella sessions: the Command Deck for interactive work, goal mode when there's a clear definition of done to work toward, and fleets when a batch of tasks can run in parallel across isolated worktrees. Every run's cost and outcome is tracked in the workspace's local telemetry.
Oxagen also hosts this documentation site. stella.oxagen.sh runs on
their infrastructure.
stella is bring-your-own-key and local-first for every team shown here, not
just Oxagen. By default, sessions use your own provider keys and send
telemetry nowhere, until you set up a path for it yourself. There are
exactly two such paths: the Enterprise mode an
organization can choose to enroll in, which sends only a documented,
content-free usage summary, and a drain block in ~/.stella/cloud.json,
which stella cloud sync uses to send staged rows to an intake you name.
Either way, the full local record always stays on your machine.
stella-examples
github.com/macanderson/stella-examples is an open library of working examples for stella: one for every configurable part of the CLI. Each file matches the format stella actually reads, and each directory's README says exactly where the file goes on disk. Clone it, copy a file into place, and it works.
minimal,
balanced,
max-quality,
dirt-cheap,
local-ollama,
and team
settings.json profiles, plus the
credentials.toml
shape. These are the model lineups from the docs, ready to copy.
A SessionStart context injector,
a PreToolUse bash guard
that blocks destructive commands, and a
PostToolUse JSONL audit log,
all wired together in one
hooks block.
/fix-issue
(with $ARGUMENTS),
/changelog,
and /pr-description.
code-reviewer
(read-only toolbelt),
test-writer
(witness tests), and
docs-writer
(no shell).
Hard guards:
no-force-push,
protect-migrations,
and no-shell.
Plus a soft
code-conventions
rule.
todo_scan
(input schema + STELLA_INPUT_* env) and
loc_report
(minimal manifest).
An mcp.toml
with both stdio and HTTP transports.
A hand-tuned
domains.toml,
and the lesson-to-skill-to-rule promotion loop.
ci-autofix.sh
(budget-capped, with a verification check armed) and
nightly-goal.sh
(goal runs you can schedule with cron).
Clone it once, and the whole library is a single cp away:
git clone https://github.com/macanderson/stella-examples.git
cd your-project
# A settings profile — user scope, so every project inherits it.
mkdir -p ~/.stella && cp ../stella-examples/settings/balanced.settings.json ~/.stella/settings.json
# A guard rule and a custom tool — project scope, committed with the repo.
mkdir -p .stella/rules .stella/tools
cp ../stella-examples/rules/no-force-push.md .stella/rules/
cp ../stella-examples/tools/todo-scan.toml .stella/tools/
# Validate the manifest before a session ever loads it.
stella tools --validateEverything in stella-examples respects the trust boundary: project-scope
hooks, MCP servers, and credential-routing fields stay inactive in a
cloned repository until you opt in with STELLA_TRUST_PROJECT=1.
Add your project
Shipping with stella? Open a pull request against
macanderson/stella that adds an
entry to website/content/docs/showcase.mdx: who you are, a link, and a
few sentences on how stella fits your workflow. Entries should be real,
shipped projects — a hello-world example fits better in the
examples page. If you have a hook, agent, profile, or
plan worth sharing instead, send it to
stella-examples.