Boundaries
Product boundary
What lives in OpenPress, where it stops, and which tools to reach for instead. A short reference so adoption decisions don't take a week.
The one-line definition
OpenPress is the fixed-layout application layer that creative skills target. Inline editing, dev server, comment markers, source-backed workspaces, fixed page geometry, and PDF / web export live here — so skills don't have to reimplement any of it.
A skill brings the creative decisions: intake, story plan, visual taste, layout recipe, image strategy, validation gates. OpenPress brings the substrate the skill operates on. This split is what lets a social-card skill or a research-report skill stay short and focused while the output still behaves like a real, editable workspace instead of a one-shot screenshot.
It exists for documents and visual outputs that need to live — get reviewed, re-rendered, re-deployed — not for one-shot drafts that ship once and never iterate.
Two layers: Skill vs OpenPress
OpenPress assumes a two-layer product model. Every feature, primitive, and skill in the ecosystem sits on exactly one side of this line:
| Layer | Owns | Examples |
|---|---|---|
| External skill creative decision layer | Intake, story plan, visual stance, layout selection, image and source strategy, taste calls, per-domain validation rules. Cannot edit framework code; consumes OpenPress as substrate. | Social-card generation, research-report packaging, static presentation-page packing — any skill that uses OpenPress to ship a creative output without re-implementing the workbench. |
| OpenPress + built-in skills fixed-layout application layer | Fixed page geometry, Press Tree runtime, dev server, inspector / inline edit, comment markers, source-backed MDX/TSX workspace, PDF / web reader export, validation primitives. Plus the agent-facing surface to all of it. | apply-comment, create-document, create-theme,
openpress-init, openpress-deploy — these are OpenPress's own
skills, not separate creative skills. They expose the substrate to agents.
|
Practical test for where something belongs: if it requires new rendering, new workspace geometry, new editing surface, or a new agent-facing primitive — it belongs in OpenPress or one of its built-in skills. If it's about what to make rather than how to render it — it belongs in an external skill.
What lives inside OpenPress
- Long-form documents with maintainable structure: reports, white papers, academic papers, monographs, technical manuals, course notes, contributor handbooks.
- Fixed-format single-page outputs from the same source pipeline when paired with an external creative skill: social cards, static presentation pages, cover and back-cover surfaces.
- AI-driven iteration loops. An agent reads
@openpress-commentmarkers, applies the requested source edit, removes the resolved marker, and re-exports. - Reproducible export. The same source tree produces
document.json, the web reader, PDF, and the public deploy artifact deterministically. - Local-first authoring. Source files live on disk, version control via git is a first-class assumption, no editor lock-in.
What explicitly doesn't live here
| You want… | Reach for… | Why not OpenPress |
|---|---|---|
| WYSIWYG document editing on shared cloud | Notion, Google Docs, Microsoft Word | OpenPress source is a code repo, not a cloud doc. Concurrent in-doc editing isn't the workflow. |
| Free-form visual design with hand-positioned objects | Figma, Canva, Adobe InDesign | Layout is derived from source structure, not painted on a canvas. Constraint by design. |
| Slide decks animated, recorded, presented live | Keynote, PowerPoint, Beamer | OpenPress is a fixed-page export substrate. Static presentation pages can be generated by a skill, but animations and presenter mode belong to presentation software. |
| A headless CMS with editor UI for non-technical authors | Sanity, Contentful, Strapi | Source is filesystem MDX/TSX, not a database. There's no editor-shaped content model. |
| A blogging engine with SEO routing and per-post pages | Astro, Next.js, Hugo, Eleventy | OpenPress produces one fixed-paginated document, not a multi-page site. The landing site you're reading is a separate Astro app, not OpenPress output. |
| Real-time collaborative cursors on the same paragraph | Notion, Google Docs, Figma | Collaboration is async via git + comment markers. Two humans editing the same MDX file at once is a merge conflict, not a feature. |
Three load-bearing boundaries
1. Source vs generated
The press/ directory is yours — you edit it, agents edit it, git tracks it. The
public/openpress/ directory is engine output — never hand-edit. If a render looks wrong,
fix source and re-export; don't patch generated HTML.
| Layer | Paths | Edit? |
|---|---|---|
| Workspace source | package.json's "openpress" field,
press/index.tsx, press/<slug>/chapters/**,
press/theme/**, press/<slug>/components/**,
press/media/** | Yes |
| Package-owned runtime | node_modules/@open-press/core/, node_modules/@open-press/cli/ | Read-only during document work. Fix upstream and upgrade the package. |
| Generated | public/openpress/, dist-react/, .deploy/, .openpress/, .turbo/cache/ | Never hand-edit. |
2. Framework vs starter-bearing skill
The framework (@open-press/core) is the runtime, allocator, measurement,
inspector, and the public primitives Press / Frame / MdxArea.
A starter-bearing skill (skills/<skill>/starter/) is a runnable example showing
one way to compose those primitives into a real document — a theme, a Press Tree, sample source, a
SKILL.md that names the use case.
Starter-bearing skills don't change framework behavior. If a starter needs new rendering,
the right path is to add a small public primitive in @open-press/core first, then have
the starter consume it. These skills are installed through the skills tool and interpreted by the
agent; OpenPress does not keep a starter registry or fetch starters through CLI flags.
3. Human vs agent
OpenPress assumes a writer (you) and one or more AI agents collaborate on the same source tree. The contract:
- Writers own intent. The agent never invents material facts, business numbers, legal claims, or public commitments without explicit user direction.
-
Comments are the inbox. You leave
@openpress-commentmarkers via the inspector;openpress-apply-commentsreads them, applies the smallest source change that satisfies the comment, and removes the resolved marker. -
Deploy is gated. No agent publishes to a public URL without confirmation that names the target
project —
openpress-deployowns that flow.
How to know OpenPress is the wrong fit
If two or more of these are true, look elsewhere:
- You need real-time co-editing of the same paragraph.
- Your authors will refuse to touch a git repo, even via an AI agent.
- The document is a one-shot deliverable that won't be revised after shipping.
- Layout precision matters more than content reproducibility — you want to drag boxes, not declare structure.
- You need a database-backed content model with editorial workflows and roles.
If exactly one is true and the rest of the workflow fits, OpenPress can still cover the case — just expect that one to be friction. Otherwise, pick the tool that owns that constraint as its primary problem.