You Can Have OwlMeans Today — One Command, Any Agent

Published on  · Igor Tkachenko

A founder at a glowing desk beside a great-horned owl; a single terminal line reads create @owlmeans/app, and from it three connected panels light up labeled COMMON, API, WEB, with small tags reading ENTRYPOINTS, SHADCN UI, RESOURCES, SKILLS

People keep asking me when they can use OwlMeans. The honest answer used to be: when the Platform ships. Now there is a better one — you can use the part that matters most today, with the agent you already trust.

OwlMeans is an AI development pipeline. You describe what you want as user stories, and a team of specialized AI roles turns them into full-stack TypeScript apps you actually own. Underneath every one of those apps sits a single library — OwlMeans Common — the thing all our projects are built from. This week it got a create-app package. One command scaffolds a complete fullstack project that Claude Code or GitHub Copilot can develop end-to-end, with all the agent guidance already in the box.

I want to walk you through what that command gives you, why it is built the way it is, and how to go from an empty folder to a real database-backed feature without writing a single line of harness yourself.

The one command

Pick your package manager:

bun create @owlmeans/app my-app
# or
npm create @owlmeans/app@latest my-app
# or
npx @owlmeans/create-app my-app

Then:

cd my-app
bun run dev          # API on :3000, web on :3001

Open the web app, go to the Session screen, add and remove a few items. That is a working fullstack app: a typed shared contract, a backend, and a shadcn UI frontend, talking to each other. No database to provision, no auth to configure, no boilerplate you had to copy from a tutorial.

What you get is a small monorepo with three workspaces:

  • common — the shared contract: route entrypoints, validation schemas, and types used by both sides.
  • api — the backend, on @owlmeans/server-app, keeping demo data in an in-memory resource.
  • web — the frontend, on @owlmeans/web-panel, with shadcn navigation, a layout, and screens.

That structure is not a toy. It is the same shape our real apps use, stripped to the essentials. When you outgrow the in-memory store, you swap one package — I will show you exactly that below.

Why it is built to keep agents from getting lost

Here is the uncomfortable truth about coding agents in 2026. They have no tenure. Every session starts from a blank slate, and every invocation pays the full cost of whatever your codebase failed to make explicit. The numbers are brutal: on a medium codebase the exploration phase — the agent reading files just to figure out where things are — can eat “60–70% of total input tokens”, and a single task can push hundreds of thousands to millions of cumulative tokens through the model. The agent is smart. The agent also “starts from a blank slate except for what you explicitly feed into its context window”.

So the question that shaped OwlMeans Common was simple: what does a codebase look like if it is designed to be read by something that forgets everything between sessions?

The answer turned out to be the same thing senior engineers have always wanted. The industry arrived at it independently this year — “code should be simple, explicit, and boring … so there are no decisions for the AI to make,” and agents “struggle with implicit behaviors and clever abstractions.” That is exactly the constraint we built under:

  • No complex DI schemas. Services are plain TypeScript factory functions registered by a string alias and fetched with context.service('alias'). No decorators, no metadata, no container magic to reverse-engineer.
  • No generated code. No OpenAPI-to-client step, no schema codegen, no build artifact you have to keep in sync with reality. What you read is what runs.
  • No YAML, no config sprawl. Configuration is TypeScript. Routes and config are plain objects.
  • Everything explicit and traceable. Every service, every route, every resource can be found by searching for it. A human can follow it. So can an agent — without burning a thousand tokens guessing.

That last point is the whole game. Explicit, boring code is cheaper for an agent to work in, and it is the difference between an assistant that confidently edits the right file and one that flails across forty.

A split illustration: on the left a tangled dark maze of decorators, YAML files and generated code with a small confused owl; on the right a clean indigo grid of labeled plain-TypeScript blocks the owl walks straight through

The four ideas that make the agent’s job easy

Four design choices do most of the work. You do not need to memorize them — but they are worth seeing once, because they are why a feature request to Claude Code lands cleanly instead of sprawling.

Context injection. The app context holds your services and resources and is passed top-down. You register a service as a factory closure and resolve it by alias. There is nothing hidden: the entire wiring is ordinary code an agent can read in one pass.

Entrypoints as a universal fullstack protocol. This is the keystone. An entrypoint is a URL unit — an alias, a path, a method, and an inline validation schema — declared once in common:

entrypoint(
  route(session.add, '/:sid/items', { parent: session.base, method: RouteMethod.POST }),
  filter(params(SessionParamsSchema), body(AddItemSchema)),
)

The backend elevates that same entrypoint with a handler. The frontend elevates it with a screen and calls it with ctx.entrypoint(session.add).call({ params, body }). One declaration is the single source of truth for the route, the validation, and the types on both sides. Change it once and the whole stack stays in sync. There is no separate API spec, no generated client to drift out of date. For an agent, this means a new feature has an obvious, repeatable shape: declare, implement, call.

Unified resources. Every data store — in-memory, MongoDB, Redis, object storage — implements the same Resource<T> interface: get, list, create, update, delete, and a few siblings. Your handler code does not change when the storage does. Swapping the demo’s in-memory store for a real database is, almost literally, a one-package change.

shadcn UI you own. The web layer is built on shadcn and Tailwind v4, and the components live in your source tree — not behind a dependency. That is deliberate. shadcn is “not a library you install — it’s a code generator … you own it,” and it has become the component library every AI coding tool reaches for. The agent reads your UI as real, editable React — the same code it already knows — instead of poking at an opaque package.

Fully skilled on day one

Here is the part I am most proud of. The project arrives already knowing how to be developed.

Every @owlmeans/* package ships its own agent guidance — Claude Code skills and GitHub Copilot instructions, version-matched to the package. When create-app finishes scaffolding, it deploys that guidance into the project: skills land in .claude/skills/, instructions in .github/instructions/. It also writes a CLAUDE.md and a .github/copilot-instructions.md with memory directives, plus starter memory indexes both agents read at the top of every session.

So when you open the project and ask Claude Code to touch the resource layer, it does not have to go discover how OwlMeans resources work — the mongo-resource skill is right there. When it adds a route, the entrypoint skill is right there. There is even a reuse-code rule baked into CLAUDE.md that tells the agent to look for an existing @owlmeans/* package before inventing a custom solution. The first time you open the project, the agent will ask you what it is for and write your answer into both context files so it never asks again.

You did not write any of that. You did not wire a harness. The skills and the memory and the conventions came with the command. That is what “self-sustaining, fully-skilled” actually means in practice — and it is the same machinery our Platform leans on, handed to you directly.

An open project folder rendered as glowing labeled cards — CLAUDE.md, .claude/skills, .github/instructions, MEMORY.md — with thin light-threads connecting them to a Claude Code and a Copilot mark, the owl watching approvingly

How-to: from scaffold to a real feature

Let me make this concrete. Say you want to turn the demo’s in-memory store into a real, persistent feature backed by MongoDB. You do not open the docs and start wiring drivers. You scaffold, then you ask.

First, scaffold and run it (either manager works):

bun create @owlmeans/app my-app     # or: npm create @owlmeans/app@latest my-app
cd my-app
bun run dev

Then, in Claude Code (or Copilot), start from a prompt like this:

Add a persistent notes feature backed by MongoDB. Use @owlmeans/mongo and @owlmeans/mongo-resource instead of the in-memory static resource. Declare the entrypoints and the schema in sources/common, register the resource and implement the handlers in sources/api, and add a screen in sources/web. Reuse existing @owlmeans/* packages — follow the reuse-code skill.

That prompt works without hand-holding, and it is worth understanding why. The project already carries the skills for exactly this. The agent knows the resource swap is one-for-one, because every resource implements the same interface — the handler that did context.getStaticResource(...) becomes context.resource(...) over a Mongo collection, and the create/list/delete calls are identical:

const notes = context.resource<NotesResource>(RES_NOTES)
await notes.create({ id, text, createdAt })
const { items } = await notes.list({ criteria: { ... } })

It knows the entrypoint pattern stays the same — declare in common, elevate with a handler in api, elevate with a screen in web. And it knows your UI is shadcn it can edit directly. Because the structure is explicit and the guidance ships with the repo, the agent spends its tokens building your feature instead of re-learning the framework every session. When you upgrade your @owlmeans/* packages later, you re-run npx @owlmeans/agent-skills and the guidance refreshes with them.

Why this is the beginning, not the whole thing

I will be straight about what this is and is not.

create-app is the library and the agent guidance, handed to you to drive yourself with Claude Code or Copilot. It is genuinely powerful, and for a lot of projects it is all you need. The OwlMeans Platform — the full pipeline of specialized AI roles that turns user stories into finished, owned software — is the layer on top, and it is built around this exact library. That is precisely why it can do what it does at a fraction of the cost: it is not exploring a strange codebase every session and paying the exploration tax, it is operating on a framework designed from the ground up to be explicit, repeatable, and cheap to reason about. Our aim is for the Platform to build these projects at roughly ten times fewer tokens than an ungoverned coding agent grinding through an unfamiliar repo.

But you do not have to wait for that. The foundation the Platform stands on is shippable today, in one command, on the agent you already pay for. Run create-app, point Claude Code at it, and you get a real taste of the OwlMeans way of building: typed, explicit, fully-skilled, and yours to keep.

That is the team-around-the-agent idea, made small enough to fit in your terminal right now.