Templates
Forkable starter packages — `helpdesk`, `hr` and `project`.
Templates are forkable starter packages. Each one is a real, shaped app that you can install from the marketplace in one click, or clone with the CLI to get a TypeScript codebase to extend.
Templates exist for two reasons:
- Show, don't tell — a working multi-object app reads faster than docs.
- Give engineering teams a starting point — when you want code under source control, not just AI-generated metadata in your DB.
What ships in the default catalog
| Template | Domain | Forkable starter for… |
|---|---|---|
helpdesk | AI-first customer support | Tickets + SLAs + AI co-pilot |
hr | Directory, org chart, time-off | People-centric apps |
project | Project / task / milestone tracking | PM tools |
Source: github.com/objectstack-ai/templates. Apache-2.0. Fork without asking.
Install in 30 seconds (zero code)
In ObjectOS:
- Open Marketplace → search for the template.
- Click Install.
- Refresh — the new app shows up in your nav.
Done. Records, views, flows, permissions — all live.
Fork as a codebase (for engineers)
npm create objectstack@latest my-app
cd my-app
pnpm install
pnpm devThe scaffolder starts every project from its blank template. It no
longer fetches the content templates by name: on ObjectStack 17.7,
--template todo is refused as retired.
The project is a self-contained pnpm package — *.object.ts,
*.view.ts, *.flow.ts files you can edit, lint, test, commit. When
you're happy:
pnpm build
os package publish # → your marketplaceCustomers installing your fork get your brand and your modifications.
Template charter (the social contract)
Every template ships a CHARTER.md declaring its scope and hard
limits — typically: ≤ 6 business objects, ≤ 2,500 LOC under src/,
one app, one default locale. The charter exists so templates stay
templates, not half-finished products. If a fork grows past these
limits, ship it as a new template, don't bloat an existing one.
See the upstream TEMPLATE_GUIDE.md
for the file-suffix protocol (*.object.ts, *.state.ts, *.hook.ts, …),
the authoring sequence (objects → state → hooks → views → flows → …),
and the polymorphic platform services (sys_comment, sys_attachment,
sys_audit_log) that you should reuse instead of reinventing.
Pick a starting point
| If you're building… | Fork this | Why |
|---|---|---|
| Anything customer-facing with AI | helpdesk | Agent + ticket co-pilot pattern |
| A people / org-chart app | hr | Directory + reporting structure |
AI Builder + templates together
You can fork a template and still use the AI Builder on top of it.
Install helpdesk, then say:
"Add a
csat_scoreinteger field tohd_ticket, range 1–5, ask for it on close."
The AI extends the installed package in place. The change is live metadata in your deployment, approved like any other AI Builder change; it does not travel back to the template's source repository on its own.
Where to go next
- AI Builder — extend any template by chat
- Packages — what a template actually is
- Marketplace — distribute your fork
- Run ObjectOS Community locally — full end-to-end of the developer path