Manifest
Declares the pack identity, runtime class, routes, skills, concept specs, and lifecycle metadata.
Build extensions
Build extensions with humans and agents, then deploy them safely.
A Move Big Rocks extension should be understandable. It owns explicit structured state, uses managed artifacts when needed, declares its routes and skills, and moves through a clean sandbox-to-production lifecycle. That makes it possible for humans, Claude Code, Codex, and other capable agents to build real operational software without inventing a different deployment model every time.
What an extension can contain
An extension is a bounded product slice, not an unstructured plugin.
The pack should be explicit enough that a human or agent can understand what it owns and how it behaves without reading tribal knowledge first.
Structured state
Own workflow state in an `ext_*` PostgreSQL schema instead of polluting the core schema.
Artifacts
Store websites, templates, prompts, docs, and publishable content in managed Git-backed artifact surfaces.
Endpoints and pages
Publish declared pages and service endpoints through core routing rather than raw sidecar exposure.
Concepts and skills
Register concept specs and bundled skill Markdown so agents and operators can discover the pack intentionally.
What to build
Extensions are for the product depth that should not bloat the core.
You do not need to wait for the vendor to imagine your internal tool. If it belongs on the same operational base, it is a candidate extension.
Internal operational apps
Create service portals, request workflows, internal dashboards, or approval systems.
Public microsites
Publish a careers site, a support surface, or another public capability on artifact-backed routes.
Team capability packs
Ship marketing campaign tooling, platform incident helpers, or recruiting workflows as private packs.
Agent-specific helpers
Bundle skill Markdown, templates, and runtime metadata so agents can act predictably.
Suggested build flow
The workflow should be understandable enough that an agent can help with almost all of it.
The builder should be able to say what they want, let Claude Code or Codex scaffold and implement it, then use the platform lifecycle to validate and deploy deliberately.
1. Define the slice
Describe the operational problem, the teams involved, the routes, the concept specs, and the state the extension should own.
2. Implement the pack
Let the agent create the manifest, assets, schema, concept specs, and any runtime integration needed.
3. Deploy to sandbox
Use `mbr extensions deploy` to install, configure, validate, and activate in a sandbox.
4. Verify behavior
Review the UI, routes, artifacts, skills, health, and runtime state through the same contract.
5. Promote to production
Deploy the proven pack into a self-hosted instance with the same lifecycle rather than inventing a second path.
Safety
The goal is not friction. The goal is predictable leverage.
Move fast, but use a runtime that stays legible enough to trust. That matters even more when agents are helping with build and deployment.
Declared routes
Public and admin paths are declared and checked rather than claimed implicitly.
Validation before activation
A pack should prove enough about itself before it becomes live.
Sandbox over hope
Use a disposable sandbox to shake out config, artifacts, and routes before production.
Audit and health
Keep lifecycle state, health, and operator actions visible instead of hiding them in local scripts.
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.