Prompt service
The prompts that drive PETROVA’s control loop are a service, not a file you carry around. One repo authors them, one server hands them out, and consumer repos call out for whichever one they need at the moment they need it. This page is the surface map.
The three surfaces
Section titled “The three surfaces”| Surface | Role | What lives here |
|---|---|---|
eva-hq/prompts/{slug}/ | AUTHOR — sole source-of-truth | meta.yml (metadata) + prompt.xml (eva wrapper) + body.md (canonical markdown body) + optional guard.sh / verify.sh. ~58 prompts. |
petrova.host/console/prompts (dashboard) and eva.re/catalog | SERVE — live views | Both pages read eva-hq through the Fleet MCP petrova.prompts.list / petrova.prompts.get calls (via EvaSource in host/src/sources/eva.ts). Nothing is duplicated; the catalog is rendered, not copied. |
consumer .petrova/playbook/ | BOOT KIT | META-RULES.md, 00-bootstrap.md, partials/*.xml, schemas/*.json — the minimum a consumer agent needs to operate before it can call out. Installed by petrova_install_playbook. |
A subset of the catalog is also mirrored in-tree at
petrova-codes/core/playbook/prompts/ and rendered as the prompt
library on this site. That mirror is machinery, not a
parallel authoring surface — it exists so the install verb works
without a network round-trip, and it is refreshed every six hours
from eva-hq by sync-playbook-from-eva.yml.
The consumer contract
Section titled “The consumer contract”A consumer agent operating inside a .petrova/playbook/-installed
repo follows this rule:
The
.petrova/playbook/directory is the runtime boot kit only. It is not the prompt catalog. For every other PETROVA verb or prompt —petrova-onboard,petrova-phase-open, the wire prompts, any new prompt that ships after install time — call the Fleet MCP server (petrova.prompts.list/petrova.prompts.get). Do not search for a localprompts/directory. If Fleet MCP is unreachable, surface that as a blocker; never improvise prompt bodies.
This is what makes the system one-author-many-readers. Every consumer
sees the same prompts at the same versions because they read from the
same live source, and a single edit in eva-hq/prompts/{slug}/body.md
propagates to every consumer within one mirror cycle plus one verb
re-install.
Why this shape
Section titled “Why this shape”Putting the full catalog into every consumer repo would have given us three problems at once:
- Drift. A prompt edited in one repo to fit a local quirk would silently fork the catalog. Catching that requires diffing dozens of repos.
- Update cost. A typo fix in a prompt would touch every consumer’s history as a sync commit. Reviewers stop reading sync commits, which is exactly the wrong incentive.
- Mental-model bleed. Agents would treat the local
prompts/directory as authoritative and fall through to it even when the remote moved on. The asgard-style “no prompts/ directory exists” error is the symptom of an agent that hasn’t internalised this split.
Centralising authoring and serving the catalog over MCP solves all three: drift is impossible because there is no fork point, update cost is one commit in eva-hq, and the consumer contract is a single sentence (“call MCP, don’t look local”) that an agent either follows or visibly fails.
What this means in practice
Section titled “What this means in practice”Operating against a consumer repo:
- You need a prompt → check the prompt library for
the slug, then have the agent call
petrova.prompts.get { id }against Fleet MCP. Do not paste the markdown from this site into the consumer repo; that creates a stale local copy. - You want to add a prompt → open a PR against
eva-hq/prompts/{new-slug}/. The mirror cycle picks it up within six hours; the dashboard renders it immediately on the next page load. - You want to change a prompt → edit in
eva-hq/prompts/{slug}/body.md. Same propagation rules. - Fleet MCP is down → consumers can still bootstrap (the boot kit is local) but anything beyond Day-1 onboarding stalls until MCP is reachable. This is intentional: a degraded fleet must surface, not silently fall back to stale local prompts.
See also
Section titled “See also”- Verbs — the mechanical pipeline that invokes prompts.
- Control plane vs source-of-truth — the same split applied to methodology vs project truth.
petrova_install_playbook— the verb that deposits the boot kit.- Prompt library — the in-tree mirror, rendered.