We don't have a platform team. We have a TUI and 22 markdown files.

A new engineer's first day here looks like this: clone two repos, run one command, and a terminal UI starts the API, the web app, the insights service, and Postgres - in dependency order, with live logs and per-process CPU/memory in a 2×2 grid. Their second day looks like typing /dev-setup and /trace and having the monorepo explain itself.

We're six builders running about 15 deployable services. By any conventional playbook we should have a platform engineer - someone who owns local environments, runbooks, migrations tooling, release mechanics. We don't. We have one small TUI we built for ourselves, and twenty-two markdown files that an agent executes. This post is about why that's not a compromise.

The cold-start problem

A monorepo this shape has a cold-start problem: to work on almost anything you need three or four services running locally, in the right order, with the right environment, against the right git worktree. The traditional answers are a wiki page that rots, a docker-compose file that drifts from how services actually run, or a platform team we cannot afford. Meanwhile the operational knowledge - how to cut a release, how to trace a bad number from the UI back to the pipeline that produced it, how to flip a migration flag safely - lived in two people's heads. Every "how do I…?" question was a context-switch tax on exactly the people with the least spare context.

What we built: the TUI

aithon-devctl is a Textual-based terminal UI that manages the local stack. It's unglamorous and it removed a whole category of friction:

1. Dependency-aware startup. Services declare what they need (depends_on); starting the API transitively starts Postgres first. No more "why is it 500ing - oh, the database."
2. A quad view: four services' logs streaming side by side, with per-process CPU and memory - measured by walking the whole process tree, because modern dev servers fork children that top-level stats never see.
3. A worktree picker. One keystroke re-points the entire running stack at a different git worktree and restarts what's affected. Reviewing a colleague's branch stops being a 20-minute teardown ritual.
4. Paper cuts, encoded. It checks for stale port-forwarding rules that silently squat your dev ports (the classic "login redirects to the wrong place" mystery), and re-runs dependency installs when a lockfile is newer than the last install - the "Cannot find module" trap that eats a morning, retired permanently. Inline AWS SSO login and rotating per-service log files round it out.

None of it is rocket science, and that's the point - it's an inventory of every recurring local-dev failure we ever hit, turned into code once.

What we built: the skills

The second half is the one that raises eyebrows. The monorepo carries twenty-two skills - markdown procedures that Claude Code executes. Among them: dev-setup, feature, scaffold, trace, impact, secrets, rds-query, plan-review-panel, aithon-release, code-review, sre-ops, and four ctx360-* skills for our data-platform cutover.

A skill is a runbook with hands. /trace doesn't describe how to chase a wrong number from the UI through the API into the data pipeline - it does the chase, and shows its work. /impact analyzes whether a schema change breaks any consumer before you ship it. /plan-review-panel critiques an implementation plan from several engineering personas before a line is written. /aithon-release runs the entire release train from the last post - assembling the preview, checking the gates - and structurally refuses to merge the release PR, because that decision is ours.

Three properties make skills better than the wiki they replaced:

1. They're executable, so they can't rot silently. A stale runbook fails visibly the next time someone runs it - and then gets fixed, because it's the tool, not the documentation about the tool.
2. They're PR-reviewed. Our platform layer has diffs, history, and review comments. When the release process changes, the change is a reviewable artifact, not an edit nobody notices.
3. They're the onboarding. New engineer, new agent - same interface. The knowledge that used to live in two heads now lives where every head (and every model) can run it.

Real numbers

1. 22 skills operating one monorepo of ~15 services - eight more than when we first wrote this down, which is the point: the folder grows as the questions do.
2. 4 services in the quad view - the whole product, running locally, one command.
3. Onboarding to a running full stack: minutes, not the day-and-a-half of environment archaeology it used to be.
4. Zero platform engineers. Not as a boast - as a budget line we got to spend on product instead.

Where the humans sit

Skills encode procedure; they deliberately do not encode judgment. /aithon-release prepares everything and stops at the merge. The migration-ops skills refuse to flip a production flag unless their readiness gates pass, and then still ask for a typed confirmation. Humans also sit at the review gate for the skills themselves - a change to "how we do releases" gets the same scrutiny as a change to the code it ships. The pattern from the whole series again: automate the toil to zero, then shape the remaining decisions so they can only be made on purpose.

Steal this

The next time you write a runbook, write it as a skill instead - a markdown file with explicit steps, checks, and stop-points that an agent can execute. Start with your single most-asked "how do I…?" question. You'll get the wiki page for free (it's readable), the automation for free (it's runnable), and the maintenance for free (it breaks loudly). The TUI took us longer and paid off too, but the skills are the 80/20 - a folder of markdown files is not a platform team, and at our size it doesn't need to be.

So far this idea has pointed inward, at our own dev loop. Next week we point it at the organization itself: how a complaint in a retro becomes a triaged issue, a human-approved spec, and shipped code. On Thursday, the product track puts the context graph on trial.

---

This post is part of How a Tiny Team Ships Like a Big One, a series on how six builders run a production AI company. Building at Aithon - if this is how you want to work, talk to us.