Skip to content

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.

SurfaceRoleWhat lives here
eva-hq/prompts/{slug}/AUTHOR — sole source-of-truthmeta.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/catalogSERVE — live viewsBoth 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 KITMETA-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.

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 local prompts/ 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.

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.

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.