Stelow

The problem

Software factories ship fast. They still skip the product work.

Watching tokens stream became the new doomscroll. You stare at every line even when no decision needs you — afraid to miss a detail, burning attention waiting for output you only needed to judge when ready. The press now calls the role "AI babysitter"; surveyed developers describe it as a dozen browser tabs open in the head. Continuous chat made sense when models couldn't sustain long runs. Now it's a residual habit — with honest exceptions. Tight chat still earns its place: debugging a hairy failure, pairing through genuine ambiguity, talking something through to learn it. But as the default operating system for continuous product work, it taxes more than it helps.

At the other extreme, the autonomous factory has the opposite problem: throughput without judgment. Issue-to-PR pipelines ship code nobody shaped, questioned, or scoped. The 2026 evidence is consistent — agent adoption raises complexity and static-analysis warnings while velocity gains fade, and most agent PRs merge unmodified. Speed stays, understanding doesn't.

Two failures, one missing layer: product discipline between intent and code. Stelow is that layer — shaped bets with IN/OUT boundaries, adversarial critique, interface before code, typed scopes under acceptance contracts, and an audit that closes the loop. You stay in zoom-out — context, boundaries, choices, quality — while agents run an opinionated workflow: board, quiet inbox, structured questions only when a decision actually needs you.

The 2024–2026 default

Factory pipeline

prompt
code
done

Fast. One role. No memory of why a decision was made.

The deliberate alternative

shape
critique
approve
interface
scope
build
audit

Slower at the start. Fewer rewrites at the end.

How it works

Shape, argue, then build.

17 stages under the hood, grouped in 4 board phases: Analysis, Planning, Execution, Review. You set Planning depth + review gates once, approve at the gates, and let workers run — no babysitting the stream.

1 · Analysis

Write down the bet

Triage to shape: IN/OUT boundaries, appetite, risks. A codebase preview reads what exists so the proposal fits before anything is planned. No code yet.

2 · Planning

Argue before building

Critique to tech plan: fresh-context reviewers pick the proposal apart, interface directions get explored before code locks them in. You approve spec, interface, and plan in visual gates, with receipts on disk.

3 · Execution

Hand off typed scopes

Feature, spike, optimize, and test scopes run in dependency order under acceptance contracts. Progress lands on the board, questions land in a quiet inbox.

4 · Review

Close the loop

Diff review plus audit: gaps sort into fixed, documented, or new scopes instead of fading. The run ends with an audit trail.

Two dials steer the whole run — Lean / Core / Complete for depth, Auto / Spec gate / Full for how much waits for you. Set once at the start; the workflow follows them. See them as board controls.

What changes

The parts factories leave out.

Each one maps to a role on a product team. Together they keep small decisions from becoming rewrites.

Shaped bets, not wishlists

Every proposal states what is in and what is out, the appetite it must fit, and the risks. A fit check runs before planning continues. If it does not fit, the scope gets cut. The budget never grows to fit the scope.

Reviewers with fresh eyes

Plans go to parallel reviewers who never see each other's notes. They check flows, states, data, feasibility, and assumptions. The author cannot review its own work and pass.

Gates with receipts

Spec, interface, tech plan, and diff each get a visual approval, and each approval writes a receipt under .stelow/approvals/. No receipt, no advance. Oversight is a dial, not a lottery: Auto runs untouched, Full gates everything.

Typed scopes under contract

Work breaks into feature, spike, optimize, and test scopes with dependencies, acceptance criteria, verify commands, and stop rules. Spikes come first when the unknown is large. A scope closes only when its criteria pass.

Audit that closes the loop

After execution, gaps sort into fixed, documented, or escalated. Escalated gaps become new scopes instead of fading. The run ends with a SHA-256 audit trail, and strict mode refuses to seal it while registered output is missing.

Tech talks back early

Before shaping, a preview reads the codebase for constraints. Before planning, recon maps what the change touches. An alignment check compares the tech plan against the spec while edits are still cheap.

For the curious

This page is the tour. The README is the machine.

All 17 stages, the transition table, the CLI reference, and the host contract, written down. If that is your idea of fun, it is all there.

Read the README

Strategy library

Coding is one skill. Product takes the rest.

Each strategy is a callable playbook the workflow consults during research, shaping, and audit. Pick one for a single study, or let a build card pull in what it needs.

Jobs to be done

What people hire the product to do, mapped step by step.

Opportunity mapping

Ranked options for one problem, from openings to bets.

Product discovery

Short learning cycles: test the idea before building it.

Market analysis

PESTLE, foresight, Delphi, and Wardley maps on a niche.

Evolutionary strategy

Optionality and small tests instead of fixed roadmaps.

Pricing

How to charge, package, limit, and frame value.

Business models

Cost and revenue triggers worth trying.

Trust building

Perception pillars and guarantees that make trust concrete.

Product ads

Message by awareness stage, not one ad for everyone.

Launch promotions

MAGIC offers: loss leader, gift cards, freebies that pull.

Paywall & onboarding

Consumer funnel from paywall to trial policy.

Marketplace playbook

Supply and demand moves that start the flywheel.

Open source strategy

When giving up control creates the moat.

Product health

Success signals held against counter-signals, so growth does not rot the product.

Two ways to run it

Host-agnostic at the core. Visual in bb.

Stelow runs as a visual plugin inside bb: board, inbox, and workers in one place. Underneath, the same 25+ skills and the scripts/stelow helper stay portable to any agent that reads skills. No lock-in either way.

Recommended

bb desktop + Stelow plugin

One board for the whole loop. Cards move, questions arrive, approvals happen, workers run. All skills bundled and kept current automatically.

Get bb, free — and open it.
Run bb plugin install stelow. Or grab it from the marketplace listing.
Open Stelow and create a card.

Check the repo

Advanced · without the app

Skills straight into your agent

Same workflow, no board. Install once, then drive it from chat with /sw-start, /sw-status, and /sw-next aliases backed by the helper script.

npx skills add calionauta/stelow -g

git clone https://github.com/calionauta/stelow.git && ./install.sh

Optional helpers with fallbacks: cymbal for codebase recon, ctx7 for fresh docs, plannotator for visual gates, sem for structural diffs.

Check the repo

In the bb plugin

The board is the interface.

Configure once per card, watch position instead of status, tune the brains per phase. Same workflow underneath — this is what it looks like with a surface.

Planning depth: how deep to prepare

Lean: one idea, 1–2 scopes, one interface suggestion.
Core: a normal feature, 3–5 scopes, 3 directions plus a hybrid.
Complete: risky work, 8–15 scopes, 5 directions plus a hybrid.

Called Appetite in skills-only setups. In bb you pick it on card creation or save it as a board default.

Your review gates: how much you check

Auto: no gates. For throwaway spikes.
Spec gate: one approval before tech planning.
Full: spec, interface, scopes, and tech plan all gated, plus an optional code-diff review.

Ticked per card in bb, remembered as board default. Skills-only: /sw-start "what you want" asks the same two things in chat.

Beyond status: position.

Cards and List track status — which column, which state. The Hill adds position: left side still figuring out, right side executing. One glance tells whether the team is discovering or delivering, and amber dots float whatever needs you.

Hill view · position from scopes, stages, and attention — no extra tracking. Cards, List, and Hill share one toggle on the Build board.

Your models, your rules.

Stelow lets you decide which brain does which job — cheap models for drafting, strong ones for review, a second opinion wherever a call is fuzzy. Four dials, all under Agent Presets.

Cheap drafting, strong review

Each workflow phase runs on the preset you pick: draft on something fast and cheap, build and review on the strongest model you trust.

Worker preset per track · phase routing · reliable override — e.g. quick triage on a cheap tier, final review on your best model.

Small jobs get small brains

Throwaway drafts and bursts run on a cheap tier with a short leash: text in, text out, judged before anything uses it.

Delegated work · subagent tiers — e.g. a one-paragraph draft for cents, never a full worker turn.

A second opinion with a floor

Fuzzy calls — intent, severity, criteria — can go to a decision endpoint with a confidence floor. Below it, built-in rules stand; a weak opinion never decides.

Decision API (Jev-compatible) · confidence thresholds — e.g. inbox items auto-promote only above 0.7 confidence.

You pick what decides what

Each judgment chooses its mode: built-in rules, the shared endpoint, or any provider preset — even one no workflow stage uses.

Decision routers · per-judgment modes · preset judge — e.g. criteria judged by your own preset, triage by the shared endpoint.

Configured in the plugin under Agent Presets → Decision routers. Skills-only setups have no presets — this whole panel is a bb-plugin thing.

For teams · experimental

Small teams, shared specialists.

Most teams won't staff every specialty — sometimes the team is one person, sometimes one specialist supports five teams. And plainly: bb and the Stelow plugin were not built for conventional teams. Single user, single board — a technical limitation of an early tool, still pre-1.0. But AI is already reshaping product teams into lean, hybrid units, and that opens room to experiment with team workflows before the tooling catches up.

In this proposal, the GitHub repository is the hub. Everything the team shares lives there, on the issue itself: the owner's labels — tier, specialty, assignee — and the specialists' verdicts. Everything a member executes lives in their own bb+Stelow. Coordination in GitHub, execution in bb.

Owner sets the bar

Each issue gets a tier, a specialty, and an assignee. Without an owner, labels rot and gates lose their teeth.

Run alone

Low risk — take it and own the outcome.

Consult to advance

Medium risk — the owner marks which gates pause for advice; at each marked gate you consult the specialist for knowledge and experience, then you advance. Advice in, decision stays with the operator.

Approve to advance

High risk — the owner marks which gates need a sign-off; at each marked gate the specialist of that stage gives the verdict outside Stelow — e.g. a comment on the issue — and the operator files it by approving the gate. You cannot advance alone, and the chain stays traceable.

Each member in their own bb+Stelow · GitHub issues as the team room · verdicts filed as receipts. An experimental proposal, not a rigid process — background reading. Try it, break it, tell me.

Still early

Built in public, pre-1.0.

Found a rough edge? Open an issue: plugin repo for anything practical, stelow repo for methodology.

Try it today

One command, then one sentence.

Run the install command at the top of this page. No bb yet? Get it free first, open it, then re-run.
Open Stelow, set Planning depth, tick where it should pause for your review, and describe what you want to build.
Review the shaped spec, pick an interface, approve the plan, watch scopes run.

calionauta/stelow calionauta/bb-plugin-stelow