ATS
Run recruiting on the same base with role application forms, candidate workflows, interview kits, and careers-site publishing.
Extension model
Start with the core. Add focused depth as extensions.
Move Big Rocks is not trying to cram every product category into core. The core gives you the shared operational primitives. Extensions add ATS, web analytics, error tracking, enterprise access, and private team-specific workflows on the same substrate.
Available today
The first-party packs show how focused products can live on one operational base.
These are not disconnected apps bolted onto the side. They are examples of how deeper products can reuse the same teams, queues, knowledge, forms, and extension substrate.
Web analytics
Capture site and product analytics without pushing the surrounding operating context into another silo first.
Error tracking
Bring runtime issues into the same queues, cases, knowledge, and follow-through loops as the rest of the work.
Enterprise access
Add stronger identity and access patterns without forking the operating model away from core.
Private team packs
Build internal workflow packs, microsites, request forms, or capability slices that are specific to your organisation.
How the runtime works
Extensions should feel powerful without being chaotic.
Extensions can own structured state, publish artifact-backed content, declare endpoints, register concept specs and skills, and use shared primitives without bypassing core trust boundaries.
Own schema
Workflow state lives in an extension-local PostgreSQL schema.
Use artifacts
Websites, templates, prompts, and docs can live in Git-backed artifact surfaces.
Publish safely
Endpoints are routed through core with declared mounts, auth, and audit.
Register skills and concepts
Extensions can ship agent skill Markdown and concept specs so people and agents can discover how the pack works.
Author privately
Teams can build private extensions without forking the core product.
Lifecycle
The extension lifecycle should be easy to understand and safe to automate.
A good pack can be built locally, deployed to a sandbox, configured, validated, activated, monitored, and promoted to production through one predictable sequence.
Package
Bundle the manifest, schema, assets, concepts, and skills into one explicit extension package.
Deploy to sandbox
Use `mbr extensions deploy` so a human or agent can install, configure, validate, and activate the pack in one flow.
Monitor and iterate
Use `mbr extensions monitor`, runtime health, and sandbox feedback before you touch production.
Promote deliberately
Carry the proven pack into a real self-hosted instance instead of editing live production state in place.
Humans and agents
A good extension story should be equally legible to a builder and to Claude Code or Codex.
The point is not just that agents can write code. The point is that they can understand the runtime model, the lifecycle, the concept system, and the deployment path well enough to help safely.
Scaffold and edit with an agent
Use Claude Code or Codex to create the pack, author assets, define concept specs, and wire the lifecycle.
Inspect through one contract
Agents can inspect available extension skills, commands, events, and surfaces through `mbr` and GraphQL.
Avoid side-channel deploys
Use the declared extension lifecycle instead of ad hoc scripts and unpublished runbooks.
Move Big Rocks
Use the same deliberate system in evaluation, delivery, and real operations.
The point of the site is to make the next step obvious. The point of the product is to keep your work, knowledge, and agent operating model coherent after the site is out of the picture.