TL;DR
Ideas hardened on GitHub: Solo OS turns intake into repeatable, production-grade Build Loops
Solo OS
keeps durable workflow objects in Issues and Projects and exposes thin CLI primitives.
The chief-of-staff agent fronts intake so AI-native loops stay coherent and human-in-the-loop checkpoints stick instead of dissolving into tabs and folklore.
Solo OS started as thin CLI glue; it grew into the Git-backed execution model the TL;DR summarizes. Companion reads include How I Work with AI, Context Engineering in Practice, and—for shaping model-facing context systematically— Anthropic's prompt-engineering overview.
Implementation and canonical documentation live in rohitnandwate/solo-os: start from the README, then the documentation hub.
The problem: AI makes coding faster, not coordination easier
When one person stretches across repos, failure almost never reads as "I can't write code." Failure looks like coordination debt: loosely scoped ideas, soft roadmap bets, Build Loops that start before scope is real, and release calls pulled from chat memory instead of evidence.
AI can accelerate implementation on its own; it does not buy coherence. If you accelerate output, you'd better tighten what you intend to ship, why today, what stays intentionally out of scope, how you probe release risk, and what informs the next lap.
Coding without durable workflow leaks context into scattershot branches. Solo OS keeps authoritative state on GitHub and feeds learning visibly instead of reinventing folklore every sprint.
The design principle: GitHub is the database
Solo OS never attempted to swallow GitHub Projects. Issues and Projects V2 remain the substrate: humans skim the boards, bash scripts poke the API, agents read the same fields without guessing.
Solo OS expects Issues to inherit the structured fields your Project defines; the bundled workflow spec spells out how Kind, Status, and Stage behave. A tiny workspace file points the CLI at the right owner, Project, and repos, and commands read/write in that groove.
The CLI stays deliberately thin overhead: bootstrap the workspace, verify fields, mint structured Issues, read boards, poke Build Loop readiness checks. Memorizing verbs was never the UX; repeatable primitives agents could trust drove the CLI shape instead.
The workflow taxonomy
Every piece of work should be one of three things:
- Idea: an uncommitted hypothesis. It might become useful, but it has not earned execution yet.
- Roadmap: a committed strategic bet. It represents something worth tracking because it matters to the direction of the product or studio.
- Build Loop: a bounded execution unit with one goal, explicit non-goals, a risk tier, a validation plan, and a learning question.
That separation anchors the discipline: messy Ideas survive; roadmap entries read like bets worth tracking; Build Loops stay executable envelopes. Fuse them without intent and plausible output piles up faster than anyone can scrutinize honestly.
The AI-first surface
Solo OS trims the CLI surface deliberately. Prompt chief-of-staff
for the next moves instead of memorizing verbs: capture an Idea, elevate one that deserves it,
spin up a Build Loop, or recap what deserves attention tomorrow.
Specialist agents remain on standby: product-manager, software-engineer,
quality-engineer, security-engineer, design-lead,
research-analyst, big-thinker, whenever ambiguity demands depth beyond GitHub bookkeeping.
Role intents and routing expectations are documented beside the bundles in agents.
The routing figure below emphasizes the quartet tied to everyday ship risk; the same pattern holds when design, research, or strategy needs the mic.
Concrete roles with explicit inputs and outputs still beat vibes-only collaboration; it is the line I keep pulling in those AI essays. Solo OS stores that contract in GitHub instead of burying it in chat exhaust.
Concrete setup and examples
Bootstrapping stays intentionally boring: install the package, wire the workspace to your project, then hydrate agents and skills. Treat the README quick start as the authoritative install sequence before you copy snippets below.
pipx install git+https://github.com/rohitnandwate/solo-os.git
cd ~/my-workspace
solo-os init
solo-os verify
solo-os install-agents
solo-os install-skills
solo-os install-commands
After install I still tell people to skip command flashcards. Ask chief-of-staff what comes next;
when it reaches for metal, the stack looks like this:
# Capture a new idea on the GitHub Project
solo-os gh-create \
--repo rohitnandwate/solo-os \
--title "[Idea] Visual technical deep dive for Solo OS" \
--from-template idea \
--kind Idea \
--status Todo \
--stage Inbox
# See next actionable work grouped by Kind
solo-os gh-next
# Review Build Loop intake before implementation starts
solo-os bl-review --repo rohitnandwate/solo-os --issue <build-loop-issue-number>Those commands still matter; they are escape hatches and automation handles, not homework for first-time pilots.
What Build Loop discipline adds
Checkpoint semantics and rhythms are written down in build loop and release rhythm for anyone who wants the long form before reading the abbreviated tour here. A Build Loop earns that label once you stop treating it like a vague ticket sketch. Checkpoint A forces legibility before code starts: goal, why now, scope, exclusions, risk tier, validation plan, and the learning question you still owe after the lap ends.
Checkpoint B is the release gate. Low-risk doc edits should not demand the same ceremony as auth, payments, privacy, or production-data changes. Checkpoint C logs what landed, what did not ship, which lessons linger, and which assumption needs rewriting before the loop reboots.
The public Solo OS surface spends effort where repeatable automation buys slack early: bootstrap, GitHub Issues
and Projects operations, Checkpoint A prompts, nightly triage. The bundled
CLI reference
lists every verb if you need the full matrix. When isolation matters more than scripted glue,
normal git ergonomics (git worktree included) still beat bespoke runners until the OSS surface earns trust.
Why this matters for building in public
I already argued publishing the workflow keeps teams honest in Why We Build in Public. Solo OS extends that loop: hypotheses stay tagged as Ideas until they deserve Roadmap stature, roadmap bets advertise whether execution happened, Build Loops show whether intake hardened before merges.
Clear rails reshape how assisted work behaves. Roles stay explicit, loops remain scoped, checkpoints refuse fake-green releases, durable GitHub state beats polished summaries nobody could replay tomorrow.
What Solo OS is not
It is still no substitute for judgment on what market matters now, whether a pain screams urgent enough to reorder the stack, or which strategic trade deserves the burn. It should not masquerade as a heavyweight PM suite drowning teams in bureaucracy.
Solo OS stays operational scaffolding. It absorbs coordination tax so sharper attention fights for what earns build time: slicing the smallest useful increment, respecting release posture, and extracting learning whenever a loop closes.
Where it goes next
The playbook still sounds familiar: memorize fewer brittle one-off verbs;
orchestrate deliberately instead of improvised prompts; trade vague backlog stubs for executable objects you can audit;
keep durable repository state beside chat. Solo OS mirrors that direction: the chief-of-staff agent fronts routine workflow,
specialists deepen only when the situation warrants, and the CLI stays deliberately small so it remains dependable under exploratory surfaces.
That tension sits at Solo OS's core: assistants earn their place only when scaffolding, quality gates, and retros get stronger whenever velocity makes it tempting to slip past them.